-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Key rotation on secretbox #56
Comments
I still don't know that this makes sense, but it was fun to code up: https://github.com/emilbayes/crypto-secretbox-rekey |
A scenario where this might be helpful could be an embedded device with some integrated ("trustworthy") memory (ARM MCUs have many different kinds of memory with different capabilities) and some external memory. If your ciphertext is in that external memory and wouldn't fit into internal memory, then this could be useful to avoid revealing the plaintext to an attacker probing the external memory bus.The catch is of course twofold: (1) an attacker probing the external memory bus is most likely able to write to external memory, and since we just said that we can't put the message into internal memory, we'll verify the auth tag and then do something with the ciphertext. Thus, the construction is malleable in this model (fails to provide integrity), while retaining confidentiality. (2) if the plaintext doesn't fit into any trustworthy memory (per the threat model outlined), what is the device going to do with it anyway? So I guess this is a neat demonstration of stream enciphering, but probably isn't very useful in practice :D |
Would anyone not knowing the real keys but knowing the old and new sub keys be able to decrypt the ciphertext? If that is not possible, than this could be used to re-key encrypted data stored on a remote server. Which would be neat. |
You can decrypt to plaintext by decrypting with the old subkey first. |
Hi! I have been looking at how to do key rotation on PRF based symmetric constructs like the
secretbox
, without revealing the plaintext.You would verify the auth tag, use a new key and nonce to calculate a new subkey, encrypt the old ciphertext with the new subkey and then decrypt the new ciphertext with the old subkey (due to XOR being associative), and have the resulting ciphertext be encrypted with the new subkey. After the message has been "rekeyed" a new auth tag can be calculated.
One thing I'm unsure of is if there are some subtle issues with the above and what merits never revealing the plaintext has, if any? Is there a threat model where it is okay to have the keys in memory, but not the plaintext (even
mprotect
ed memory)The text was updated successfully, but these errors were encountered: