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

131–140 of 243 posts

Re: Cryptographic Right Answers

#131

Post by bsder »

brohee wrote: post #69

A bit tired with "Just use HMAC". HMAC makes you pull a hash dependency, which is not much if you do software, but can be a waste of silicon if all you want is a MAC. If you already spent real estate on AES, then CMAC becomes a lot more attractive... This is the reasons it's at the core of SCP03, the smartcard world is very sensitive to transistor count...

> This is the reasons it's at the core of SCP03, the smartcard world is very sensitive to transistor count...

The reason it's at the core of SCP03 is because SCP03 is ancient (2006?) and once things get affixed intro a "standard" things now move at a glacial pace.

And, nowadays, fixed logic transistor count is almost irrelevant.

RAM transistor count, however, is expensive and getting moreso.

Re: Cryptographic Right Answers

#132

Post by cperciva »

cperciva wrote: post #127
tptacek wrote: post #120

Earlier quoted context omitted.

Quick update though: for client-server security, I copy-paste misquoted Colin and just now noticed it (because Colin noticed it for me). The 2015 document correctly says Colin's client-server recommendation is "custom RSA protocol", but when I formatted this document I managed to accidentally make it say the same as his recommendation for "website security". I regret the error (but not the recommendation; don't make…

I regret the error (but not the recommendation; don't make your own custom RSA-based transport protocol). I think this is our largest point of divergence. If the world had sane TLS libraries, I would absolutely say "run TLS with all the backwards compatibility crap turned off" -- but we don't have sane TLS libraries. I am not confident in my ability to turn off all the unwanted "features" of SSL/TLS stacks, and I'm n…

I think this is our largest point of divergence.

While I'm on the topic:

Password handling: I skip bcrypt because the only reason to not use scrypt is if you need a US Government endorsed scheme. But yeah, it's (slightly) better than PBKDF2.

Cryptographic primitives: I think "use NaCl" is cheating a bit as far as answers go; that may be reasonable advice to implementors but it's not a protocol specification. So I'm reading those as "use foo, via the NaCl library".

As for what the foo in question should be: I'm gradually becoming more comfortable with curves, and 25519 in particular; similarly with sbox-free symmetric crypto (e.g., djb's dances and Keccak). At this point I'd say it comes down to how conservative you are; I wouldn't say that someone using XSalsa20+Poly1305 is wrong to do so.

Re: Cryptographic Right Answers

#133

Post by lvh »

bsder wrote: post #121
lvh wrote: post #104

Earlier quoted context omitted.

I think STROBE is quite a bit smaller than TweetNaCl once deployed, in gates or bytes, both ROM and RAM. More generally, there are lots of off-list recommendations that are still fine. The list doesn’t have AESCBCHMAC anymore but I’m unlikely to tell you Fernet is busted. We could do an elaborate embedded post but the answers diverge a lot more because constraints are tighter. If you’re doing embedded you need a secu…

The real question is which of these have actually been vetted . I trust NaCl and, specifically, DJB-associated implementations thereunto. Lots of people have looked at it. I trust DJB and his cohorts to think about and mitigate footguns as much as practical. STROBE is right about a year old. Maybe it's awesome, but it almost certainly hasn't been vetted sufficiently. I seem to recall that most PAKE's relied on one of…

My argument was specific to embedded crypto. If I don’t have to care about size constraints then yes, I’m going to make a better-understood recommendation than STROBE. Re “I trust DJB”: if you’re going to trust individual implentors, I suggest that the median cryptographer is going to suggest you can do a lot worse than “literally Mike Hamburg” here. I certainly will.

Re: PAKEs: yes, some PAKEs and related protocols are hard to port to ECC. For example, SRP doesn’t port cleanly from FF to an elliptic curve group because it actually needs a field. But I called out SPAKE2 for a reason: porting SPAKE2 to ECC is easy.

Re: Cryptographic Right Answers

#134

Post by lvh »

Cyph0n wrote: post #115
lvh wrote: post #68

Earlier quoted context omitted.

If it's on the raspi side of powerful, just use OpenSSL, or maybe Go's TLS stack, again, assuming you can get away with it. On smaller systems, things get weird. If you can't afford go/openssl, there aren't a lot of things I'm very confident in. BearSSL near the top of the list. That's still double-digits kilobytes of RAM though, so maybe I just ate all your budget. You might be in one of the cases where a NOISE prot…

What's wrong with PolarSSL/Mbed TLS? It is designed for low-end ARM processors and is directly backed by ARM.

Their history of implementation issues leads me to believe that the general upside of TLS doesn’t necessarily weigh up to the upside (and cost!) of a light bespoke implementation. That’s contingent on having someone around who won’t mess this up; failing that, an embedded TLS stack is still a good idea.

I would have told you something differently before NOISE and NaCl, particularly Curve25519. We could have done AESCTRHMACSHA256 a long time ago and be basically a good as XSalsa20-Poly1305, but Curve25519 was a huge leap compared to the DH2048 you were likely to do before.

Re: Cryptographic Right Answers

#135

Post by posterboy »

loup-vaillant wrote: post #81
vardump wrote: post #67

Earlier quoted context omitted.

What could be used with a small/medium sized microcontroller, something like 64 kB total flash budget and 4-20 kB RAM? IOW, Cortex M0 territory. Small IoT is about this size, so I think many will be interested in some answers... any answers. Say, for securely transmitting sensor data to an x86 server (or similar) without hardcoding symmetric keys on the devices.

Take Monocypher or TweetNaCL, and rip off any primitive you don't need. This may be enough. Even when you take the whole thing, Monocypher only needs 30kb of x86-64 machine code when compiled with -Os. If you only keep authenticated encryption and x25519, which are enough for many uses, I think you should be able to halve that down to 15kb or less. If speed doesn't matter, TweetNaCl is even smaller. If those aren't e…

avr has aes extensions, surely arm cortex-m has similar. are those any good, are they used by the libs you mention?

Re: Cryptographic Right Answers

#136

Post by ac29 »

jlgaddis wrote: post #114
piracykills wrote: post #95

Curious - why is argon2 still second to scrypt on this list? I'd also question the backup solution, I think Restic is a better option due to its flexibility, I can do cheap backups to B2 and fairly reputable people seem to be approving of its cryptography: https://blog.filippo.io/restic-cryptography/ If anyone sees a reason why Tarsnap would be better (other than Percival's brand), I'd be quite interested.

Thanks for the pointer to restic. I like and use tarsnap (and have for years) but the lack of choice of backends is a downside. I've been waiting for something I can use to backup my workstation and laptops to a server at home as well as a server I have at $work (ISP). I've tried out all the usual applications but have yet to find something I'm happy with. restic looks like it may fit the bill perfectly.

+1 for restic. I've been using it for work-related backups for a while and it works quite well. rclone support has recently been added [0], expanding the number of storage backends available by quite a bit.

[0] https://restic.net/blog/2018-04-01/rclone-backend

Re: Cryptographic Right Answers

#138

Post by dward »

throwaway1619 wrote: post #107
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…

Can you elaborate a bit on the recommendation of KMS (Amazon or Google's key management service)? It seems to me that bringing in a new external service as a dependency, and trusting that external dependency with your encryption keys, adds a risk that isn't necessary or present with NaCL or other well-reviewed cryptography libraries. How can you independently audit the correctness of KMS? What if Google or Amazon bec…

These services offer hardware bound keys, are maintained by O(hundreds) person security orgs (read managed auth[n/z], audit, intrusion/tamper detection, backup, etc...), stored in data centers with strict physical security. For the majority of private sector, the benefits of these services outweigh the cost of trusting the key holders.

Re: Cryptographic Right Answers

#139

Post by pbsd »

cperciva wrote: post #132
cperciva wrote: post #127

Earlier quoted context omitted.

I regret the error (but not the recommendation; don't make your own custom RSA-based transport protocol). I think this is our largest point of divergence. If the world had sane TLS libraries, I would absolutely say "run TLS with all the backwards compatibility crap turned off" -- but we don't have sane TLS libraries. I am not confident in my ability to turn off all the unwanted "features" of SSL/TLS stacks, and I'm n…

I think this is our largest point of divergence. While I'm on the topic: Password handling: I skip bcrypt because the only reason to not use scrypt is if you need a US Government endorsed scheme. But yeah, it's (slightly) better than PBKDF2. Cryptographic primitives: I think "use NaCl" is cheating a bit as far as answers go; that may be reasonable advice to implementors but it's not a protocol specification. So I'm r…

To be pedantic, Keccak does have a 5 to 5 bit S-box. But like 3-Way, NOEKEON, Serpent, etc, it's disguised---bitsliced---as a short sequence of boolean operations.

Re: Cryptographic Right Answers

#140

Post by geofft »

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.

Percival 2009 is http://www.daemonology.net/blog/2009-06-11-cryptographic-rig... - the actual summary recommendation is "Use RSAES-OAEP with SHA256 as the hash function, MGF1+SHA256 as the mask generation function, and a public exponent of 65537. Make sure that you follow the decryption algorithm to the letter in order to avoid side channel attacks."

I assume the misquote is making fun of how long that description is compared to, like, "Use 256-bit AES keys." or "Use OpenSSL." (What specific thing in the decryption algorithm should I be making sure I don't misread in order to avoid side channel attacks?)

Post reply on HN