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

51–60 of 243 posts

Re: Cryptographic Right Answers

#51

Post by arghwhat »

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

(For the curious, the third footnote refers to Diffie-Hellman "p" and "g" parameters specified in section 3 of rfc3526 as "group 14")

Re: Cryptographic Right Answers

#52

Post by arkadiyt »

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…

Are these going to be published to the cryptopals website as well?

Re: Cryptographic Right Answers

#53

Post by norrius »

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

Indeed. What on Earth is “bzzrt pop ffssssssst”? Am I missing something? Google does not help at all.

Re: Cryptographic Right Answers

#54

Post by iamwil »

lvh wrote: post #46
iamwil wrote: post #39

Earlier quoted context omitted.

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

It's not always a foregone conclusion that it scales better. I've seen people argue that when using ECDSA verification that's 4x longer than an in-DC RTT. Usually: DB kv lookups aren't even close to the most expensive thing your app does. Generally: don't do encrypted tokens. If you must: don't do JWT for this. Just secretbox a thing and be done with it, or use PASETO[0]. [0]: https://github.com/paragonie/paseto

By secretbox, I assume you mean NaCl's secretbox. Cool, thanks for the tips, and helping make the web a more cryptographically secure place.

Re: Cryptographic Right Answers

#55

Post by suf »

lvh wrote: post #42
suf wrote: post #17

Earlier quoted context omitted.

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.

Disclaimer: I'm not 'tptacek but I'm one of the Latacora principals and co-edited this document. Embedded crypto gets weird fast. General recommendations are a little tricky, but: is that device talking to the internet directly or some kind of IoT hub or whatever?

Let's say talking directly to the internet.

Re: Cryptographic Right Answers

#56

Post by dchest »

Xeoncross wrote: post #49
dchest wrote: post #44

Earlier quoted context omitted.

It's not recommended not because it's insecure, but because it's easy to get wrong. XSalsa20Poly1305 can also be implemented in a streaming/buffered fashion, it's just that most libraries implement the easier to use interface. If you're encrypting objects that won't fit in RAM, it's worth considering encrypting separate chunks, making sure that the order cannot be changed (e.g. by incrementing a part of nonce for eac…

Can you explain what is easy to get wrong? You want a CSPRNG to generate the IV, HMAC key, and AES key (which Go and node both have). Are their other implementation details that are complex?

I think the most common mistake I've seen is that people forget to use constant-time comparison function to verify MAC. AE/AEAD interfaces just have an open() function which returns NULL instead of the decrypted message if MACs don't match.

Also, AES-CTR has only space for 128-bit "IV" (counter that is encrypted), which is sometimes split into 96-bit nonce and 32-bit block counter, sometimes into 64-bit nonce and 64-bit block counter, sometimes IV is used directly and then incremented for each block. 96-bit is on the edge of collisions for randomly generated numbers, 64-bit random nonce is not safe, with 128-bit you're also limited with how much data you can encrypt without collisions... meh. XSalsaPoly accepts 24-byte nonce (can be random) and is good for 2^72 - 32 bytes (practically unlimited).

You also mention having separate keys for HMAC and AES, which is good, but you have to care about it (theoretically). With AE/AEAD you don't have to care about it.

That is, it seems like you can implement the system you described properly, but many people can't.

Re: Cryptographic Right Answers

#57

Post by lvh »

norrius wrote: post #53
tptacek wrote: post #33

Earlier quoted context omitted.

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

Indeed. What on Earth is “bzzrt pop ffssssssst”? Am I missing something? Google does not help at all.

It's a joke. The joke is that RSA seems familiar, comfortable. Except actually there's a bunch of super subtle ways to mess it up, like padding, or primegen bugs. The bzzrt pop is just a reference to all of the exceptions and caveats, which all sound like arcane incantations instead of straightforward recommendations and are therefore no longer in this document.

Re: Cryptographic Right Answers

#58

Post by ryan-c »

loeg wrote: post #18

Two nits: > Don’t built elaborate password-hash-agility schemes. build* And what's the asterisk on > Avoid: … IPSEC.* ?

IPSec has a boatload of possible configurations, many of which are not secure. It's kind of a tire fire.

Re: Cryptographic Right Answers

#59

Post by tptacek »

MrBuddyCasino wrote: post #50
loup-vaillant wrote: post #32

Earlier quoted context omitted.

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

Got an opinion on BearSSL?

I can't be sure, but I think he thinks you should use his thing.

Re: Cryptographic Right Answers

#60

Post by lvh »

Xeoncross wrote: post #49
dchest wrote: post #44

Earlier quoted context omitted.

It's not recommended not because it's insecure, but because it's easy to get wrong. XSalsa20Poly1305 can also be implemented in a streaming/buffered fashion, it's just that most libraries implement the easier to use interface. If you're encrypting objects that won't fit in RAM, it's worth considering encrypting separate chunks, making sure that the order cannot be changed (e.g. by incrementing a part of nonce for eac…

Can you explain what is easy to get wrong? You want a CSPRNG to generate the IV, HMAC key, and AES key (which Go and node both have). Are their other implementation details that are complex?

Example: if you don't specify that something is the last token, an attacker can trivially truncate.
Post reply on HN