Skip to content

Fur-ther cryptographic weaknesses #7

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

Open
nbraud opened this issue Mar 13, 2025 · 0 comments
Open

Fur-ther cryptographic weaknesses #7

nbraud opened this issue Mar 13, 2025 · 0 comments

Comments

@nbraud
Copy link

nbraud commented Mar 13, 2025

From my o.g. comment on #2 :

  • Generally, using higher-level harder-to-misuse constructions (and APIs) is a lot safer than building one's own clawptography: since the necessary changes would break compatibility anymeow, it would be straightfurward to switch to libsodium's “sealed box”, or equivalently from HACL* (which is provably-correct) or dryoc (pure Rust, but hasn't been audited)

  • this exposes a compression oracle (for doing gay CRIMEs) which is exploitable if a user interactively encrypts a mix of secrets and attacker-controlled data; there are two main solutions there, best implemented in tandem:

    • make compression opt-in, so the user can enable it only when it's safe to do so: this relies on the user understanding a pretty-subtle cryptographic concern, so it's not sufficient on its own;
    • be a good boi and use padding to limit the information leakage via ciphertext size.
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

1 participant