-
Notifications
You must be signed in to change notification settings - Fork 79
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
Return plaintext even if Poly1305 fails #210
Comments
Hi, As you have guessed, I haven't implemented in the high level interfaces because it would run awful of the Cryptographic Doom Principle. You would change that over my dead body. 🗡️ By the way, For your use case (valuable data), you should consider error correction codes. First you compress the data (optional, and depends on the data). Then you encrypt it (with authenticated encryption). Then you add error correction codes on top. If you have some random corruption, ECC will fix it, and Poly1305 will work. Perhaps there's an ECC library you could use? That said, what you ask for is possible. Naughty, but possible. Such heresy requires you to use the low level interfaces (Chacha20 and Poly1305). Basically, you want a modified version of Hope that helps, |
Thanks for your detailed explanation. I love how you use the word naughty, I can't think of a better word ;). Thanks for letting me know. I give users the option to encode the output with Reed-Solomon, which prevents most errors, but you know, someone might drop their hard drive (🤦) and try to recover as much as possible. Looking at |
Yup, that's it. Just don't forget not to wipe
Not many to be honest. Cryptographic Doom notwithstanding, nothing bad can happen at the library level: even with corrupted data under attacker control, we'll just get a corrupted buffer. Can't have like a buffer overflow if the rest of the program is written correctly. Also, to ease review, do make sure to clearly mark the modification as a departure from the original library. Or better yet, write your own modified version, which can then separate from Monocypher (easier updates, though you should never need them). Last: we still have a Cryptographic Doom problem at the user level, so do make sure to warn your users about corrupted files:
|
Nice, thank you for letting me know. I won't make any changes to the Go bindings that you've linked to on Monocypher's homepage, and I'll just create a separate repo with a notice that it is for a specific use case and point users to the unmodified Go bindings for general use. I'll definitely warn users about corruption and intentional modification, although I think most of then are smart enough not to encrypt an executable and then run it. Thanks again for helping me with this issue, I'll close it as it is completed. |
Hey LoupVaillant. Is there a way to return the plaintext, regardless of whether Poly1305 passes or not (
crypto_unlock
)? In my file encryption tool, I have an option that lets the user keep a corrupted or modified file after decryption, but it seems Monocypher returns an empty array of 0's if the Poly1305 is not correct. I understand that this is to prevent any security issues, but it would be nice if there was a way to keep the output, because sometimes, my tool is used by people to encrypt valuable photos, and if a byte in the Poly1305 corrupts, then there's no way that Monocypher lets me retrieve the original data.The text was updated successfully, but these errors were encountered: