tbuktu / libntru

C Implementation of NTRUEncrypt
Other
202 stars 59 forks source link

Padding and CCA concerns [question] #31

Closed DamienGrand closed 8 years ago

DamienGrand commented 8 years ago

Hello! Please pardon if stupid/naive question, but

1)
should I be concerned with padding for non-hybrid encryption of (<200 bytes) plaintexts, or is the padding as implemented in this library "good enough" to take care of it ?

Plaintexts are low entropy, and distinguish-ability is a concern.

2)

Do I understand correctly that if malleability/CCA/etc is a concern, a MAC should be used (ideally in Encrypt-then-MAC manner) in order to avoid trouble ?

Ivoz commented 8 years ago

1) You can always fall back the normal "extremely hard to get wrong" strategy, which is first randomly generate a symmetric cipher key; encrypt plaintext with that key; only encrypt the key with NTRU. This way what NTRU is encrypting has nothing to do with the content of the plaintext, which obviously alleviates a whole lot of concerns.

2) Always use an authenticated encryption mode of your symmetric cipher. This achieves the same thing as a MAC in a way where it's again almost impossible for you as a "mere crypto library user" to get wrong. AES-GCM or ChaCha20-Poly1305 are both implementations of this. The libsodium library handily lets you choose either of these modern options.

DamienGrand commented 8 years ago

@Ivoz Hi! Thanks for response!

Let's say that for the purpose of this particular affair I'd like to avoid using hybrid encryption. Would the "IEEE standard" NTRUEncrypt be "good enough" ?

tbuktu commented 8 years ago

Yes, it is good enough. If low-entropy plaintexts were a security problem, NTRUEncrypt would be considered broken.