token 证书部分使用 url 编码的 base64

[ustc-zzzz]

已经有不止一个参赛选手表示他们被「直接粘贴 token 进 url 不行」坑过了（我之前验题的时候也被坑过其实）。虽然这不是啥大问题，但是「可以直接粘贴进 url 的 token」想必能提升用户体验，实现起来（应该？）也不难。

[SmartHypercube]

相关： USTC-Hackergame/hackergame-challenge-docker#1

这里提议使用 hex 也不够好。好的 token 设计应该：

• 能一眼看出来是 hackergame token，比如有前缀
• 唯一，不能通过改变大小写、改变前缀、加空格等方法做出都能验证通过但不同的 token（hex 不满足此要求）
• 各种编程语言中都容易正确实现解析和验证逻辑（一些太冷门的方案，比如 base58，可能有点问题）
• 只包含比较安全的字符

[SmartHypercube]

base64 在一些语言中也不唯一，去掉 padding 的等号也能解析成功。

[ustc-zzzz]

确实，但是我记得 url 编码的 base64 是没有结尾的等号的，所以应该可以视为唯一的（不过唯一真的这么重要吗……同一个证书对同一个输入的签名真的是唯一的吗……）

[SmartHypercube]

但是我记得 url 编码的 base64 是没有结尾的等号的

至少 Python 的 base64.urlsafe_b64encode 是有等号的。

不过唯一真的这么重要吗

最主要的问题是我们的动态 flag 都是用 token 的哈希算出来的。如果一个非正规的 token 能通过验证，最终给出的 flag 却是错误的，就会很坑。

同一个证书对同一个输入的签名真的是唯一的吗

参见上面发的那个 pull request，我正在尝试换成 libsodium 生成的签名（其实是 ed25519），它不仅是确定性的（同一个私钥对同一个消息只会生成一个固定的签名），而且是没有 malleability 的问题的（不知道私钥的人没法从一个签名经过某种变换，制造出另一个不同但也能通过验证的签名）。所以至少签名这一块如果改了的话，是有唯一性的。