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

Cryptographic Right Answers

latacora.singles

Post reply on HN
Print view View original

31–40 of 243 posts

Re: Cryptographic Right Answers

#31

Post by jstanley »

lvh wrote: post #28
jstanley wrote: post #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. 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 :-))

I admit that I wrote that before I read the rest of the article. The rest of the article is great :).

I don't know why that one paragraph stuck out at me so much, but it triggered the "screw you, don't tell me what to do" reflex.

Re: Cryptographic Right Answers

#32

Post by loup-vaillant »

suf wrote: post #17
tptacek wrote: 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.

Use Monocypher, TweetNaCl, or Libsodium.

Monocypher is portable (C99/C++), pretty fast, and has low memory footprint (generated binary between 30kB and 60kB). Problem: it isn't trusted yet. (I'd like to run a bug bounty, but I'm not sure how I should go about it.)

TweetNaCl is portable (C89), has low memory footprint, and is made by trustworthy professional cryptographers. Problem: it is slow.

Libsodium is blazing fast on modern processors, has portable implementations, and is trusted. Problem: it is pretty big, and I hate the auto tools.

Edit: of course, those recommendations only hold if you have a trustworthy RNG.

Re: Cryptographic Right Answers

#33

Post by tptacek »

weinzierl wrote: post #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 Op…

This is awesome.

I love that I can't instantly tell which of those three footnotes is a real thing.

Re: Cryptographic Right Answers

#34

Post by lvh »

iamwil wrote: post #22
lvh wrote: post #14

Earlier quoted context omitted.

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…

1) Yes, use SHA512/256 (truncated SHA512). I don't think I'd default to SHA3 anywhere.

2) Are you entirely convinced you actually need client tokens? In particular, can you get away with a 256-bit random token and store the session in a database?

3) Re: HMAC input malleability: yep, concat and HMAC is fine. Serializing JSON or whatever is also fine. You're usually providing the tag (that's what the output of HMAC is called) verbatim next to the message, so you generally don't care about e.g. canonical serialization.

Re: Cryptographic Right Answers

#35

Post by gue5t »

tptacek wrote: 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…

The document misspells "haveged" as "havaged". :)

Re: Cryptographic Right Answers

#36

Post by laurentl »

lvh wrote: post #7
pvg wrote: post #3

Earlier quoted context omitted.

Do you lot have some special insight into the security of ELB, since you are so bullish on it? It's a sweet service but it's one of the more black-boxy, voodoo-ish things AWS offers and always gives me mild, irrational pangs of paranoia as a termination point.

(Hi I'm not tptacek but I am also a Latacora principal and I co-edited this new version of the document) When you're setting up ELB today you're probably getting ELBv2, specifically an ALB (since we're discussing TLS termination here). There are a few things I like a lot about the way you do TLS configuration for an ALB, but notably: * Instead of giving you the ability to configure literally everything, they have a h…

Does this hold for other AWS services that manage https endpoints? Especially Cloudfront which seems to be the de facto solution for anything serverless. Integration with ACM obviously also comes out of the box, but I haven’t looked under the hood at the implementation (besides IIRC a « you can have any color provided it’s black » approach to security options)

Re: Cryptographic Right Answers

#37

Post by masklinn »

keithwinstein wrote: post #13

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…

> It would be nice if Linux had a file-based /dev/uxrandom that waited for the CSPRNG to be properly initialized and then behaved like /dev/urandom, but, it doesn't.

It could even do that for urandom already. IIRC that's what BSDs do.

Re: Cryptographic Right Answers

#38

Post by justincormack »

loup-vaillant wrote: post #23
keithwinstein wrote: post #13

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.

It is getrandom(2) on Linux, similar to getentropy(2) on OpenBSD. It should be in 16.04, it is kernel 3.17+ although it was not added to glibc until recenrtly so you might have to use the syscall directly.

Re: Cryptographic Right Answers

#39

Post by iamwil »

lvh wrote: post #34
iamwil wrote: post #22

Earlier quoted context omitted.

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…

1) Yes, use SHA512/256 (truncated SHA512). I don't think I'd default to SHA3 anywhere. 2) Are you entirely convinced you actually need client tokens? In particular, can you get away with a 256-bit random token and store the session in a database? 3) Re: HMAC input malleability: yep, concat and HMAC is fine. Serializing JSON or whatever is also fine. You're usually providing the tag (that's what the output of HMAC is…

1) Huh. Weird it exists at all then.

2) Hrm. I guess maybe? As I understand it, the reason for a client token is to have stateless servers, so the server doesn't need to look up a valid token upon every request--which scales better. In my case, the API endpoint is for something that doesn't (and won't) get a lot of traffic, so I can probably get away with a 256-bit random token over TLS? Since it's over TLS, there probably aren't MITM attacks to sniff the token and replaying it--so it's probably ok? Are there other considerations I'm not aware of?

Re: Cryptographic Right Answers

#40

Post by asd2r23dasd »

tptacek wrote: 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…

I think the most useful parts of the document are the 'really try hard to use TLS for any comms problem' or 'try to use Amazon's key management for encryption' answers, and pointers to good libraries.

Beyond that: developers aren't normally tasked with building systems out of cryptographic primitives. Those that do are typically (hopefully!) experienced enough to pick a solid primitive.

Those who need to look-up which primitive to use need to know that the security of the final system is primarily going to pass or fail on the _composition_ of those primitives rather than the particular choices.

What would be really cool would be a document that takes common use cases and describes how best to build in the cryptographic aspects of the security. Edit: e.g. a good list of OpenSSL ciphersuites and SSL_CTX_config() blah calls for server auth and mutual auth is probably the biggest bang for buck you can get.

I don't want to come across as critical of the effort or correctness --- but I do I think people really need to hear the danger klaxon when they're doing more than just editing a TLS configuration file. Composition of primitives is really hard.

Post reply on HN