41–50 of 53 posts
Also: don't take your crypto advice from random gists.
Which better source of crypto advice would you recommend?
(Or are you going to tell me not to take advice on crypto advice from random HN commenters?)
I applaud the person who put this together but my humble opinion is that there are a lot of assumptions here. There are many situations (few I habe encountered first hand) where you need to break the rules and how you break the rules also have best practices that should be mentioned. Some items that stood out for me after a skim: - AES-CBC is not unusable, from what I understand with random IV and a good HMAC it is u…
The main issue with AES-CBC+HMAC (besides speed), is that unless you're using a library that offers a complete primitive that combines these algorithms[1], you will have to combine the encryption and MAC yourself. In this case, you will have to know, that the only safe way to do this with is Encrypt-then-MAC, and you'll also have to remember to do (and in some languages know how to implement!) a constant-time compari…
Oh come on! It's not rocket science, just encrypt and hmac. My point was mentioning that best practicr tip for example will help. People still use aes-ecb because they don't know failing with aes-cbc is better.
> When you need to roll your own crypto (custom transports, RSA combos for compatibility reasons) you'll just have to get an expert to do that
If someone is in a position where they're choosing ciphers and they're not an expert, chances are they won't get funds to hire an expert and they can't tell their boss or customer they can't do it. Help people not shoot their own foot off is all I am saying.
I agree with the audience part. The average dev also does not work in silicon valley or in a FAANG. They work in bigcorp,consulting or government where you do your best with unreasonable requirements and little cash to spare for third party experts.
I applaud the person who put this together but my humble opinion is that there are a lot of assumptions here. There are many situations (few I habe encountered first hand) where you need to break the rules and how you break the rules also have best practices that should be mentioned. Some items that stood out for me after a skim: - AES-CBC is not unusable, from what I understand with random IV and a good HMAC it is u…
AES-CBC with a random IV and solid HMAC should be fine, but the point is that, for a non-cryptographer, putting together an authenticated encryption construction yourself has potential footguns. Using a pre-made authenticated encryption construction like AES-GCM or Salsa20-Poly1305 avoids this. Any platform with hardware acceleration for AES should hopefully have a carryless multiplication instruction anyway, so GCM…
> When using bcrypt, make sure to use the following algorithm to prevent the leading NULL byte problem. and the 72-character password limit: > bcrypt(base64(sha-512(password))) Pre-hashing the password, in this context, without a salt, is susceptible to hash shucking: https://security.stackexchange.com/questions/234794/is-bcryp... Instead, use: bcrypt(base64(sha-512(password + global_salt)))
> When using bcrypt, make sure to use the following algorithm to prevent the leading NULL byte problem. and the 72-character password limit: > bcrypt(base64(sha-512(password))) Pre-hashing the password, in this context, without a salt, is susceptible to hash shucking: https://security.stackexchange.com/questions/234794/is-bcryp... Instead, use: bcrypt(base64(sha-512(password + global_salt)))
The stack exchange article seems to ascribe the risk to using MD5. While adding a (global or appended data) hash as you suggest cannot hurt, I wonder if the suggested weakness exist for sha-512.
There are both MD5 hashes and SHA-512 hashes lying around, which makes "hash shucking" possible for both of them.
KMS makes sense for encryption of data in cloud, since the companies already have access to data. It’s usually an additional layer of access control, monitoring and compliance.
But it seems a bad practice to have an external company create and manage cryptographic keys, and/or manage encryption of on-premise or personal data (like encrypting your backups with an AWS KMS key, client side, and uploading to S3).
Apart from that, KMS is a solution for key management. The users can use keys with any algorithm.
Also, I am not sure if AWS encryption SDK is particularly of high quality. Anyone knows?
Earlier quoted context omitted.
Let's just put it like this: Most "simple" explanations of RSA are wrong. The "advantage" of ECC is that there are no "simple" explanations of ECC, because there's no comic version of ECC that is insecure and easy to explain. For RSA, such an insecure comic version exists. However, I never found that a very convincing argument against RSA.
The Discrete Log Problem is relatively simple to explain in the context of a generic group. It's sort of intuitive that elliptic curve groups are a pretty good instance of a generic group. So I don't think it is simpler to explain the security of RSA than the security of ECC. Additionally, the best attack on ECDLP (Pollard's rho) is much easier to understand than the best attack on RSA (the number field sieve).
Only if RSA is implemented properly. Naive textbook RSA implementations are very vulnerable[1]
[1]: https://sci-hub.st/https://link.springer.com/chapter/10.1007...
I’m not crazy about this guide to be honest. For symmetric encryption, if you’re recommending Salsa20/ChaCha20, it is absolutely necessary to discuss nonce management, since this is a major footgun people coming from AES may not be familiar with. You should always use the extended nonce variants of these algorithms (XSalsa20/XChaCha20) if possible, with a random nonce for every message. If not, you will have to be ce…
The most popular AES mode here is AES-GCM, where nonce reuse is even more catastrophic than it is with ChaPoly. People coming from AES thus are familiar with nonce-reuse problems, unless they’re (i) incompetent or (ii) only ever used a nonce-misuse resistant construction, and those are still pretty niche.
Agreed that extended nonces are the safest default.
> “Use ECC” is too generic as advice for asymmetric encryption.
Which is why that’s not the actual advice? There’s a discussion about why ECC is better, but when it comes to the actual recommendations, I read:
Asymmetric Encryption
Use: NaCL, libsodium, or monocypher
Asymmetric Signatures
Use, in order of preference:
1. NaCL, libsodium, or monocypher
2. Ed25519
3. RFC6979 (deterministic DSA/ECDSA)
As the author of Monocypher I can answer that one: though I did independently implement it, my choice of primitives puts its squarely in the NaCl family, and closest to libsodium. I even use libsodium to generate most of my test vectors. And with the exception of Elligator and streaming encryption we use compatible wire formats. And finally I did shamelessly stole some code from the Ref10 implementation of Curve25519, and the bignum arithmetic is still there.
Under my definition of a fork (clone repo then branch off), it’s not. But under a looser definition… I’m not too mad about it.
(Now I’m wondering how much of a fork of NaCl libsodium actually is…)
Do people realize that Keccak replaces a lot of complexity and offers powerful composable primitive already? Instead of saying "blake is faster, but sha3 is standard", pick SHAKE-128 and build everything with it: hash, MAC, symmetric encryption, fiat-shamir transcripts etc.
It’s a bit more complicated than that. If you look at the various constructions proposed by the Keccak team, most notably Farfalle and Kangaroo12 I believe, you’ll notice they adjust the number of rounds given the use case. That is, they’re not just proposing a secure permutation that let us compose any construction for which we could devise a security reduction. I mean you could do that, but the results would likely be slower than ideal. https://eprint.iacr.org/2019/1492.pdf
Instead they are tailoring their constructions to lower the requirements on the underlying permutation, in some cases allowing reduced rounds. The price they pay for that is re-doing the entire cryptanalysis: their constructions are effectively new primitives.
The actual simplification is more for implementers: with one permutation to rule them all our source code becomes quite a bit smaller.
According to one of the experts on the panel of the Password Hashing Competition, Argon2 is actually weaker than bcrypt https://twitter.com/TerahashCorp/status/1155129705034653698 I'm not an expert, but I'm really curious to hear more. It's especially weird given I've heard nothing but good things about Argon2 otherwise.
I’m also sceptical about the timing based threshold (one second). Computers are a bit faster now than they were in 2015, so there’s a chance that threshold now lowered. I understand why they used that easy to understand shorthand, but it’s unlikely to age well.
One thing everyone do seem to agree on though: Argon2 is stronger with long enough run times, if you can tolerate them. Maybe you don’t if you’re running a server under fairly high login load, but maybe you do if you use some augmented PAKE (say OPAQUE) to offload the expensive computation to the client.