This guide seems to be full of close enough but not quite right recommendations which in this specific field can be very dangerous especially as it seems to be recommending specific implementations rather than just giving some generic advice on what to look for.
Cryptographic Best Practices
31–40 of 53 posts
Re: Cryptographic Best Practices
#32Earlier quoted context omitted.
I hadn't heard about OBC being unpatented, but then the Wikipedia pointed me to this email to the ietf cryptography forum: https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3... So... yes... it looks like OCB is no longer encumbered. I am curious why GCM was hard. Hard to do without side-channel leaks I can understand, but 800-38D seemed straight-forward.
A GCM software implementation can be simple, fast, or secure against side-channel attacks: you can only pick two. OCB (RFC7253) is indeed much simpler and it really deserves more popularity.
I think it would have been far more popular if Rogaway hadn't kept it patented well beyond the point where it was clear patented crypto had no future. It's a pretty neat solution to the problem and the continued insistence on restricting its usage with a patent is one of the more baffling things I've seen in the crypto world.
Re: Cryptographic Best Practices
#33This gist is from 2018, last updated 2019. I wonder if there have been any recent relevant developments to warrant an update to these recommendations, as some comments from the comment section indicate.
Re: Cryptographic Best Practices
#34According 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.
Re: Cryptographic Best Practices
#35I noticed there's no mention of quantum-resistant crypto. Looking around, it looks like this is the rational [1]. This sort of feels like a hand-wave. > Quantum computing does give us some far more efficient algorithms that classical computing cannot achieve, but even then, 256-bits still remains outside of the practical realm of mythical quantum computing when brute force searching. [1] https://pthree.org/2016/06/19…
For symmetric encryption, there is no point looking at "quantum resistance" because even if somebody has a non-toy quantum computer they get a speed-up equivalent to halving key length, so, just use longer (256 bit) keys and stop worrying about it. For asymmetric encryption, nobody knows for sure, and the best available guesses are expensive with as-yet unknown reward, if you are vulnerable it's likely to be because…
You ruined his attempt to appear knowledgeable, brutal.
Re: Cryptographic Best Practices
#36The recommended libraries are still too low-level for me, for supported languages, I myself prefer using Google's Tink: * Sane defaults and API * Built-in integration with external KMS service * Excellent documentation
> * Built-in integration with external KMS service
The first thing I notice is that Tink doesn't support Azure Key Vault.
Re: Cryptographic Best Practices
#37Earlier quoted context omitted.
> For people familiar with RSA, in which the asymmetric construction is actually used to encrypt messages, this is unfamiliar, so explanation is necessary. Are there really people using RSA for message encryption? That sounds very wasteful as it's going to spend a huge amount of CPU cycles for no good reason.
I probably should have said “can be”. The way RSA is often explained just details the mathematics, and explains how a message could be encrypted directly using RSA. It’s then not an unreasonable assumption for a complete beginner that this is how RSA works in practice, even though this is not the case.
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.
Re: Cryptographic Best Practices
#38Earlier quoted context omitted.
I probably should have said “can be”. The way RSA is often explained just details the mathematics, and explains how a message could be encrypted directly using RSA. It’s then not an unreasonable assumption for a complete beginner that this is how RSA works in practice, even though this is not the case.
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).
Re: Cryptographic Best Practices
#39Can someone help me understand this recommendation: Under symmetric encryption, the authors write: > If you are in a position to use a key management system (KMS), then you should use KMS. If you are not in a position to use KMS, then you should use authenticated encryption with associated data (AEAD). These seem orthogonal to me. KMS := how keys are generated and distributed to communication partners. AEAD := how da…
I think this was copied from Latacora’s cryptographic right answers without some of the necessary context. It’s specifically talking about the KMS offerings from AWS/Google Cloud, which provide trusted hardware implementations of not just key management, but also symmetric/asymmetric encryption, HMAC, etc. All the symmetric constructions provided by these platforms are AEADs, so the point is, if you’re using AWS’s KM…
It also goes on to say not to use Amazon or Google in the last section.
Fortunately there are good FOSS KMSes out there. I like Cloudflare's Red October: https://github.com/cloudflare/redoctober
Re: Cryptographic Best Practices
#40Also: don't take your crypto advice from random gists.