Skip to content

Fur-ther cryptographic weaknesses #7

Description

@nicoonoclaste

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions