Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cryptographic Best Practices

gist.github.com

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Cryptographic Best Practices

#11

Post by _8j50 »

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 usable?

- "Really, anything RSA", there are protocols that encrypt the key with RSA for key transport and use AES or some other block cipher for the data. As far as I am aware this is safe given the key is derived properly and is not reused. If you have to encrypt using their public key and you are restricted from using EC anything your choices are few.

- Custom transport protocols are sometimes needed. TLS is general purpose which means there are corner cases it can't support once in a whole and you can't always use noise. What are best practices to implement key exchange, manage keys and authentication+integrity?

My feed back is that often people are lazy enough to use a pre-made library but when they can't telling them there is no alternative does not help. But otoh, I get that perhaps going into such detail would make the content of the gist too long.

Re: Cryptographic Best Practices

#12

Post by tialaramex »

8organicbits wrote: post #10

I 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 ignored the advice this gave you and insisted on Rolling Your Own. Too bad.

My guess is that in five years we'll be in the same situation. Like Fusion power generation, Quantum Computers might work "soon" or they might not and that'll remain true until they actually do work, which might never happen. They'll make great MacGuffins for Hollywood meanwhile and shouldn't affect what you, a non-expert, do all day.

Re: Cryptographic Best Practices

#13

Post by iofiiiiiiiii »

What is the state of the art for doing encryption with ECC? The author just says "use NaCl" here but what should I do if I am not in a position to do that but can still use ECC?

My understanding of ECC is that it is not really suitable for encryption as-is, as RSA was, rather it is used for key agreement (somehow through a multi-step process that I do not understand). But it is unclear how much of this is just rumor and implementation limitations.

Re: Cryptographic Best Practices

#14

Post by oleganza »

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.

Re: Cryptographic Best Practices

#16

Post by opheliate »

_8j50 wrote: post #11

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 will be fast. And if not, Poly1305 is so fast that another HMAC construction will perform worse. So there’s really no reason not to just use one of these two in 99% of cases.

Re: Cryptographic Best Practices

#17

Post by red_admiral »

iofiiiiiiiii wrote: post #13

What is the state of the art for doing encryption with ECC? The author just says "use NaCl" here but what should I do if I am not in a position to do that but can still use ECC? My understanding of ECC is that it is not really suitable for encryption as-is, as RSA was, rather it is used for key agreement (somehow through a multi-step process that I do not understand). But it is unclear how much of this is just rumor…

If you can't use NaCl directly you may still be able to use the underlying "25519" Edwards curve. The point is that it was designed in such a way to make implementation bugs ("bad" points, separate addition/doubling formulas, and other edge cases) either non-existent or at least easy to deal with.

In contrast, ECDSA seems like it was almost designed by the NSA to make it as easy as possible to accidentally introduce an exploitable implementation bug.

You are right that ECC is mainly a key agreement/transport and signing tool, not to be used directly for encryption except in very special cases (e.g. modified ElGamal for verifiable voting schemes).

Re: Cryptographic Best Practices

#18

Post by opheliate »

andiw wrote: post #7

Can 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 KMS, don’t think about it, just use the default. Which is fairly sensible advice.

Re: Cryptographic Best Practices

#19

Post by opheliate »

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 certain that nonces are never reused with the same key, possibly through some counter construction. The real solution to symmetric encryption for most people is to use something like Sodium‘s `crypto_secretstream`, which smooths out all the rough edges.

“Use ECC” is too generic as advice for asymmetric encryption. Use Elliptic-Curve Diffie-Hellman for key exchange (X25519 ideally), and then use a symmetric AEAD construction (XChaCha20-Poly1305 or AES-GCM) to actually encrypt messages. For people familiar with RSA, in which the asymmetric construction is actually used to encrypt messages, this is unfamiliar, so explanation is necessary.

I would not recommend just “SHA-2” as the first choice for generic hash algorithms anymore, due to length extension attacks. Use BLAKE2b, SHA-3, or one of the well-studied truncated variants of SHA-2.

Also, I think monocypher was written independently of NaCl, it’s not a fork.

Re: Cryptographic Best Practices

#20

Post by opheliate »

iofiiiiiiiii wrote: post #13

What is the state of the art for doing encryption with ECC? The author just says "use NaCl" here but what should I do if I am not in a position to do that but can still use ECC? My understanding of ECC is that it is not really suitable for encryption as-is, as RSA was, rather it is used for key agreement (somehow through a multi-step process that I do not understand). But it is unclear how much of this is just rumor…

The author definitely should have clarified this. The standard is to use ECC for key exchange only. This can be done entirely offline - each party chooses a random secret scalar, and multiplies the base point of the curve by that scalar to produce a public point. You publish your public point in advance of communication. When you want to send a message, you multiply the other party’s public point by your secret scalar to obtain a shared key. Then, just use a well-studied symmetric AEAD construction to encrypt messages.

Of course, this doesn’t incorporate any forward secrecy, which is a key benefit of using something like TLS or Noise rather than rolling your own custom protocol.

Post reply on HN