Skip to content
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

Closed
emilbayes opened this issue Feb 26, 2018 · 4 comments
Closed

Key rotation on secretbox #56

emilbayes opened this issue Feb 26, 2018 · 4 comments

Comments

@emilbayes
Copy link
Contributor

Hi! I have been looking at how to do key rotation on PRF based symmetric constructs like thesecretbox, 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 mprotected memory)

@emilbayes
Copy link
Contributor Author

I still don't know that this makes sense, but it was fun to code up: https://github.com/emilbayes/crypto-secretbox-rekey

@enkore
Copy link
Collaborator

enkore commented Feb 27, 2018

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

@blochberger
Copy link

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.

@enkore
Copy link
Collaborator

enkore commented Mar 5, 2018

You can decrypt to plaintext by decrypting with the old subkey first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants