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

21–30 of 53 posts

Re: Cryptographic Best Practices

#21

Post by zimmerfrei »

retrocryptid wrote: post #4
bjoli wrote: post #3

I laughed when I read that GCM is hard for library authors. I remember trying to implement GCM but failing, so I decided to transcribe a "simple implementation" but failed at that also. Then I decided to try OCB mode and it worked on the first try. By the way, isn't OCB unpatented as of recently?

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.

Re: Cryptographic Best Practices

#23

Post by timo_h »

> 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)))

Re: Cryptographic Best Practices

#24

Post by unscaled »

opheliate wrote: post #19

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…

This is a fork of tptacek's 2015's Cryptographic Right Answers Gist [1]. I think the original 2015 file is somewhat better than this fork. The fork is more up-to-date, but just offers too many options and is probably to confusing for a beginner. As far as I know, the latest "official" update to Cryptographic Right Answers is the Latacora blog post from 2018 [2].

Both the the 2015 version of Right Answers and the OP best practice guide mention (non-extended) ChaCha20-Poly1305, but if you look at their order of priorities, using NaCl/libsodium/monocypher is always mentioned first. That gives you XSalsa20-Poly1305 (NaCl, libsodium default) or XChaCha20-Poly1305 (monocypher, optional for libsodium). the non-extended ChaPoly20 is mentioned as lower priority than the extended versions, but higher priority than AES-GCM, which also features short nonces.

The same argument goes for ECC. The actual "Use" line in the document mentions NaCl, libsodium and monocypher, all of them use X25519 by default, although monocypher does not seem to offer an asymmetric encryption primitive. The main issue is the confusing language talking about ECC, when we know than some ECC (yes, I'm looking at you ECDSA) is not strictly better than RSA [3].

None of the answers in the OP guide seems wrong per se (I didn't review this thoroughly FWIW and I'm not an expert). But I'm still recommending this one, since it's simpler, and "simpler" is the entire point of this kind of guide. You want to avoid programmers shooting themselves in the foot - and shooting yourself in the foot is really easy when you're implementing cryptography.

[1] https://gist.github.com/tqbf/be58d2d39690c3b366ad

[2] https://latacora.micro.blog/2018/04/03/cryptographic-right-a...

[3] Except when you define "better" as "Lets you jailbreak your PlayStation 3".

Re: Cryptographic Best Practices

#25

Post by dikei »

opheliate wrote: post #18
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 KM…

KMS is often used to store KEKs only, you'd still have to create and manage DEKs and use AEAD for actual data encryption.

Re: Cryptographic Best Practices

#26

Post by dikei »

The 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

Re: Cryptographic Best Practices

#27

Post by littlestymaar »

opheliate wrote: post #19

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…

> 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.

Re: Cryptographic Best Practices

#28

Post by unscaled »

_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…

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 comparison for the HMAC value.

Since it's highly unlikely than an untrained developer will do all of these correctly, the authors are right, IMHO, to avoid mentioning AES-CBC+HMAC. Yes, it can be implemented safely. So does RSA for that matter. But is it likely that most developers (or let's be generous - even more than 10% of them) will implement this correctly? No.

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. WireGuard implements its own transport and TarSnap implements its own crypto (on top of RSA, no less!) and you don't see the authors of these documents criticizing them. In fact, TarSnap is consistently recommended in this guide.

But the audience for these best practices is not Colin Percival[2]. It's the average developer who usually has an "Intro to Cryptography" background from their CS Major at the best of times.

[1] I am not aware of any audited library that does this, but Google's Tink offers AES-CTR+HMAC: https://developers.google.com/tink

[2] https://en.wikipedia.org/wiki/Colin_Percival

Re: Cryptographic Best Practices

#29

Post by opheliate »

littlestymaar wrote: post #27
opheliate wrote: post #19

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…

> 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.

Re: Cryptographic Best Practices

#30

Post by dogma1138 »

dikei wrote: post #25
opheliate wrote: post #18

Earlier quoted context omitted.

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…

KMS is often used to store KEKs only, you'd still have to create and manage DEKs and use AEAD for actual data encryption.

Depends these days KMS also extends to solutions that provide full on encryption as a service such as Vault. If your design allows for a trusted and well vetted EAAS solution to be used that should be the first you go for.
Post reply on HN