Uncategorized
Snippet 0x0A: Cryptography DOs and DON’Ts
This tiny post is meant as a loose collection of DOs and DON’Ts I’ve come across when I implemented the cryptography concept for Syncany, my open source file sync software. I’m not a cryptography expert, so take my advice with caution — and correct me if you know more than I do.
Cryptography DOs and DON’Ts
- Most importantly: Don’t believe you know things better. You don’t. Don’t invent stuff. Ask people for help!
- Don’t use ECB mode
- Don’t re-use your IVs
- Don’t encrypt your IVs (IVs are meant to be public)
- Authenticate cipher configuration (algorithm, salts and IVs)
- Use authenticated/AEAD ciphers where possible (GCM, EAX)
- Don’t use unauthenticated data (e.g don’t use IVs before authenticating it)
- Never ever re-use a nonce
- Don’t use fixed IVs in CBC (never, ever!)
- Always choose your IVs at random
- Don’t invent your own encryption
- Don’t use any data before the verifying it
- Don’t use password based encryption unless you have to
- If you must use a password, use password-based key derivation functions such as PBKDF2
- PBKDF2 with SHA1 is okay, even though SHA1 is not
- Don’t store passwords in plaintext, store them as a salted hash
- If your passwords are short (e.g. PINs), don’t hash them; encrypt them instead
- Use a key derivation function to derive keys from keys (such as HKDF)
- Don’t use DES, or 3DES; use AES
- Don’t use MD5 or SHA1; use SHA2 (e.g. SHA256)
- Don’t abstract your crypto code: Keep it simple!
- Don’t blindly trust the defaults (Java uses ECB mode as default!)
- Specify the ciphers, key lengths and crypto providers in detail
- Do not use OpenJDK’s GCM before Java 8, see here
- Using /dev/urandom is as secure as /dev/random, because they are seeded by the same PRNG
A. About this post
I’m trying a new section for my blog. I call it Code Snippets. It’ll be very short, code-focused posts of things I recently discovered or find fascinating or helpful. I hope this helps.
Recent Comments