Key material should have a consistent and safe format #100
Milestone
Comments
|
I'd have been great if a) we could've used Tink and b) Tink had a storage format for these kinds of keys. But it's not like that would be in distributions either. https://crypto.stackexchange.com/questions/61777/distinguishing-x25519-public-keys-from-random also does not help us much here. ;-) I guess I'd personally prefer the PEM encoding, which presumably should not be hard given that we already require OpenSSL? |
|
Having an external PEM file might be easier for key rotation. Also we can use standard openssl tools like: |
|
2024 update:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The private keys produced by
glome genkey(and the corresponding public keys fromglome pubkey) are x25519 keys, i.e. 32 raw octets.Key Exchange
Dealing with GLOME keys is inconvenient: transferring a public key to another system requires either a direct file transfer (e.g.
scp) or an intermediate encoding into the printable range (e.g.base64). SSH keys, for comparison, are PEM encoded and can be easily copied or included in an email. Furthermore, given only the key file it is impossible to determine its nature, which could lead to accidental confusion of private and public keys. In the best case, you just cannot determine whether the 32B file in your home directory created two years ago is a GLOME key or something else.Encoding Logic
All keys in the spec are hex-encoded, as are the keys in tests and for
glome-login. The lack of encoding in the GLOME library causes a proliferation of encoding logic elsewhere, as can be seen by the definition of adecode_hexinglome_test.c,cli/commands.candlogin/ui.c. Since parsing and deserialization logic is a common source of security vulnerabilities, it would be better to have one central piece of logic for dealing with encoding that is well tested.Protocol Variants
The keys do not specify which protocol variant they are to be used with. If the two parties disagree on the variant to be used we would at least expect mismatching tags, while a deliberately introduced confusion by a person-in-the-middle could ostensibly lead to more severe outcomes.
The text was updated successfully, but these errors were encountered: