paragonie-scott
commented
6 years ago Key-ID is actually why the footer (which is never encrypted but is authenticated) exists at all.
I could provide a "peek at the footer" function that just base64 decodes the last segment, but I don't want people using the data in the footer unauthenticated.
It's safe to provide this feature. If you're providing an identifier that points to the key, the most an attacker can influence is a shot-in-the-dark search query (so, please used prepared statements if appropriate). As long as the key-id points to a real key, if it's not the correct key, decryption will fail.
This is similar to using the TCP sequence ID as part of an TLS nonce. Letting an attacker influence the nonce doesn't let you do chosen-ciphertext attacks, even if you can read it before verifying the authentication tag.
rlittlefield
I'm trying to figure out if I should support key identifiers in pypaseto. I'm inclined to just say no, but I noticed a reference in this repo to what appears to be key ids:
https://github.com/paragonie/paseto/blob/ac3c4cc661cede52fcdb28f4e25169d6ff88e282/tests/JsonTokenTest.php#L47
But I also found this closed issue about it:
1
As far as I can tell, there is no built-in way to parse a footer in advance of decoding. I could provide a "peek at the footer" function that just base64 decodes the last segment, but I don't want people using the data in the footer unauthenticated. They could be required to write their own "peek" function, but I don't want to encourage that either (as they might be tempted to use it for things apart from key-selection).
I almost wonder if there is a benefit to telling people it is unsupported. For users who insist, they can reference their alternative keys out-of-band (query string, post parameter, extra junk they add to the end of the token, etc.). They could then load the key based on what was provided out-of-band, which is unauthenticated (as they can't authenticate without the key anyhow).
Any suggestions?