Live data from Hacker News

Cryptographic Right Answers

latacora.singles

21–30 of 243 posts

Re: Cryptographic Right Answers

#22
post #14
post #12

Earlier quoted context omitted.

Do you also agree with the recommendations given in the article in 2018?

I might be misunderstanding you, but... 'tptacek and I worked on the 2018 recommendations in the article, and I think we still agree with what we said last week when we edited it :-)

Ah, didn't know he also worked on it. It wasn't obvious in the article.

Then I have two basic questions (for either you and tptacek):

1) Given I just need to hash the contents of a file for content-addressed data (like in git), it seemed like sha2-256 would be sufficient. However, it seemed like on 64-bit machines, sha2-512 is faster, and I can just lop off the first 256 bits. Is that correct? And in what cases would you use sha3-256/sha3-512?

2) Given I need to build an API that authenticates through client tokens, I was thinking of using JWT (json web tokens) with HMAC256, and a payload with a randomly generated token for the at_hash claim, and send it over TLS. Do I need to include a nonce in the payload? If not, it's the same JWT on every client request. If so, how would you recommend generating a nonce?

In the article, under symmetric signatures, you talk about not doing anything complicated with the data you feed into the HMAC. But I'm not sure what the simple construction of this data is. Is it where you say "just concatenate the key and data and hash them and be secure"?

Re: Cryptographic Right Answers

#23

Would propose one amendment to "Random IDs": if you can rely on it being available, getentropy() is preferable to /dev/urandom. (1) It blocks if the system has just booted and the kernel has not yet collected enough entropy to initialize the entropy pool. (Good on VMs, embedded systems, etc., where there's a risk that the initial state might be identical.) It would be nice if Linux had a file-based /dev/uxrandom that…

I may have to update my manual, which currently recommends getrandom() on Linux, and arc4random_buf() on BSD. https://monocypher.org/manual/#Random_number_generation

On which systems is getentropy() available? My Ubuntu 16.04 doesn't seem to have it.

Re: Cryptographic Right Answers

#24
Here is a summary, roughly ordered from constant to changed the most.

	    			Percival 	Ptacek			Latacora
				2009		2015			2018

	Online backups		tarsnap		tarsnap			tarsnap

	Symmetric key length	256-bit		256-bit			256 bit

	Symmetric “Signatures”	HMAC		HMAC			HMAC

	Random IDs		256-bit		256-bit			256-bit
				
	Hashing algorithm	SHA256 (SHA-2)	SHA-2			SHA-2


	Password handling	scrypt		scrypt			scrypt	
				PBKDF2		bcrypt			argon2
						PBKDF2			bcrypt
									PBKDF2

	Website security	OpenSSL		OpenSSL			AWS ALB/ELB
						BoringSSL		OpenSSL
						AWS ELBs		LetsEncrypt

	Client-server		OpenSSL		OpenSSL			AWS ALB/ELB
	app security				BoringSSL		OpenSSL
						AWS ELBs		LetsEncrypt


	Asymmetric encryption	[1]		NaCl/libsodium 		NaCl/libsodium
		

	Asymmetric signatures	[2]		NaCl			NaCl
						Ed25519			Ed25519
						RFC6979

	Diffie-Hellman		[3]		DH-2048			Nothing
						NaCl			Curve25519


	Encrypting Data:	AES-CTR HMAC	NaCl/libsodium default	KMS
						ChaCha20-Poly1305	XSalsa20+Poly1305
						AES-GCM



[1] RSAES-OAEP with SHA256 and MGF1+ SHA256 bart pop fssssssst exponent 65537

[2] RSASSA-PSS with SHA25 or MGF1+SHA256 in tricolor systemic silicate orientation

[3] 2048-bit Group #14 with a generator or 2

Re: Cryptographic Right Answers

#26
This article was worth writing, and I'm glad you wrote it. It is helpful. You might not realise it but:

> If you could use KMS but encrypting is just a fun weekend project and you might be able to save some money by minimizing your KMS usage, use KMS. If you’re just encrypting secrets like API tokens for your application at startup, use SSM Parameter Store, which is KMS. You don’t have to understand how KMS works.

Paragraphs like this come across quite condescending, and the tone might have more to do with the lack of adoption of the ideas herein than the content does.

Security Professionals seem to have an unfortunate habit of talking down to everybody else.

Re: Cryptographic Right Answers

#27
post #17
post #2

Fight me. I mean, happy to answer any questions. By the way: if you're interested in this, you might also be interested in the set of 9 (count them: 9) new cryptopals challenges we sold off to raise money for rural congressional races on Twitter: https://twitter.com/search?f=tweets&q=set%208%20from%3Atqbf&... This is Cryptopals Set 8, before this weekend available only on request and after swearing a solemn oath not…

Hey, can you share some crypto advice for limited embedded systems (let's say minimum being 32bit cortex-M0). Say for firmware updates, user data uploading, etc.

Advice for that kind of problem typically requires a lot more context, e.g.: * You need to do symmetric crypto between two MCUs, where only one has an RNG; * You need to do symmetric crypto with no RNG; * You can't rely on your MCU safely storing state / unreliable transports.

Cryptography and libraries/standards are gradually building towards a world in which higher-and-higher level abstractions let inexperienced web/high-level application developers build safe systems. The same isn't really true for the lower-end of the embedded space, and consequently you can't really produce an equivalent set of (reasonable) guidelines like the ones linked.

Re: Cryptographic Right Answers

#28

This article was worth writing, and I'm glad you wrote it. It is helpful. You might not realise it but: > If you could use KMS but encrypting is just a fun weekend project and you might be able to save some money by minimizing your KMS usage, use KMS. If you’re just encrypting secrets like API tokens for your application at startup, use SSM Parameter Store, which is KMS. You don’t have to understand how KMS works. Pa…

Did you feel that entire graf was condescending or just parts of it? The "you don't have to understand how KMS works" perhaps? (It's definitely not meant that way :-))

Re: Cryptographic Right Answers

#29
post #25

Why is it better to use 256-bit IDs vs 128-bit IDs? I thought UUIDs were fine?

There are lots of things that are outside of the set of recommendations that are still fine. If you use UUIDs I won't tell you you're wrong and you need to rip it out :-)

Re: Cryptographic Right Answers

#30

Would propose one amendment to "Random IDs": if you can rely on it being available, getentropy() is preferable to /dev/urandom. (1) It blocks if the system has just booted and the kernel has not yet collected enough entropy to initialize the entropy pool. (Good on VMs, embedded systems, etc., where there's a risk that the initial state might be identical.) It would be nice if Linux had a file-based /dev/uxrandom that…

I may have to update my manual, which currently recommends getrandom() on Linux, and arc4random_buf() on BSD. https://monocypher.org/manual/#Random_number_generation On which systems is getentropy() available? My Ubuntu 16.04 doesn't seem to have it.

[deleted]
Post reply on HN