Live data from Hacker News

Cryptographic Right Answers

latacora.singles

171–180 of 243 posts

Re: Cryptographic Right Answers

#171
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…

happy to answer any questions. I'm working on some open source hardware, and I'm considering embedding the SSL keys into a cheap hardware crypto element[1]. The element I'm considering [2] only offers ECDH and ECDSA with the NIST P256 curve. However, this article says "Don’t do ECDH with the NIST curves" and "really, especially avoid conventional DSA and ECDSA". How bad is it really? I mean, the article's pretty uneq…

> How bad is it really?

Really bad.

Invalid curve attacks will leak your secret key, which most old implementations (i.e. the ones likely to end up in your hardware) don't protect against.

If you reuse an ECDSA nonce, you will leak your secret key.

If you have even the smallest timing leak, guess what.

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-7056

https://web-in-security.blogspot.com/2015/09/practical-inval...

Re: Cryptographic Right Answers

#172
post #134

Earlier quoted context omitted.

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

I don't think you can deem mbedTLS too risky on one hand, and then on the other recommend Noise, with it's slew of unfinished and largely unverified libraries. Outside of the WireGuard RHUL effort for a specific 'pattern' AFAIK the Noise core hasn't really seen any formal analysis either. Commoditizing the DH operation means you can build an enormous amount of AKEs, and even people like Trevor Perrin can make mistake…

You’re not wrong; it’s at least a close call.

You’re right that they’ve gotten less scrutiny, but they also need less scrutiny. (I’m not saying more isn’t better.) TLS carries a lot baggage from phlogiston era crypto and is significantly more complex than a dumb NOISE impl.

Note that I qualified my suggestion to “you need to have someone around for that” and that I also mentioned low cost. Specifically, I imagine you’d instantiate NOISE with some boring primitives, ideally in a memory safe language, and spend some time and money pointing Tamarin at it, for example. If you don’t have that, fine, get a tiny TLS stack. I’m just saying that a priori I can’t tell you I have less faith in random mbedTLS-containing ROM vs NOISE-with-reasonable-implementor. (I appreciate that we’re comparing apples to oranges with a concrete ROM vs an abstract protocol.) I also happily appreciate that we’re in territory where the constraints are too restrictive to make blanket recommendations.

Let me rephrase: would you agree that there are platforms that actually shipped with garbage crypto where it’s plausible that they could’ve made NOISE work but didn’t embed a TLS stack because size/perf?

Re: Cryptographic Right Answers

#173
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 love Cryptopals almost as much as I love Microcorruption, although I'm not anywhere close to being ready for set 8 yet. Are these challenges going to be available somewhere I can find them months after I've forgotten about this HN thread? Or should I just send the mail once I get to that point?

Re: Cryptographic Right Answers

#174
post #67

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…

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.

You need to provide more info.

  1. How much of your flash budget is eaten up by the application?

  2. What performance do you need for different use cases and operations?
Generally, RAM is often the least of your problems. And if you are into Cortex M0 or even M0+ territory, your MCU will quite probably sport an AES-128 core. Even if it is slow you should try and use that.

Re: Cryptographic Right Answers

#175
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 find the recommendations for HMAC to be somewhat imprecise. Latacora states for symmetric signtures to use "HMAC". But then under "Avoid" for the same category lists HMAC-MD5, HMAC-SHA1.

RFC 2014 defines HMAC with different hash functions such as HMAC-MD5 and HMAC-SHA1. All are valid HMACs. There are other versions of HMAC with for example SHA-256, SHA-224, SHA-512/256 etc defined.

Re: Cryptographic Right Answers

#176

Earlier quoted context omitted.

Which of those answers are going to hold up in the post-quantum world?

Asymmetric crypto (RSA, curve25519, etc.) and Diffie-Hellman (including ECDH) are both in danger, thanks to Shor’s algorithm. I think the only thing remaining is large-enough quantum computers. If I remember correctly, hashes and symmetric crypto are generally safe, and so those recommendations shouldn’t change.

> I think the only thing remaining is large-enough quantum computers.

That’s a very, very big “only” :).

In any case, there are several compelling computational problems which are (as of current research) post-quantum resistant. They’re based on lattices, error correcting codes, hashes, multivariate polynomials and supersingular elliptic curve isogenies (the latter one being the hot new thing).

Each of those problems has at least a few (but generally many) viable contenders for actual cryptography. Hashes give us very nice signatures, from old-school Winternitz one time signature to merkle trees to current frontrunners like SPHINCS (and its variants). Unfortunately hash-based cryptography can only be used for signatures so far, but they really excel at that.

The ring-LWE problem (and more generally, module-LWE) in lattice cryptography is pretty versatile: we can get fast encryption, signature and encapsulation schemes. The tradeoff is that key sizes run larger. But there is a lot of research into provable security in average-case and worst-case lattice assumptions. The NTRU problem is the other large “school” of lattice cryptography, which mostly has the same problem: very fast, but with larger key sizes.

Error correcting codes give us fewer computational problems to work with than lattices (essentially general decoding and syndrome decoding), but they are extremely well-studied. McEliece remains secure (for binary Goppa codes), which is incredible because it was published only two years after the notion of Diffie-Hellman PKE. Unfortunately most types of error correcting codes are not suitable for cryptography because they have excessive structure. We’ve been mostly stuck with binary Goppa codes for 40 years, though there is exciting work on quasi-cyclic and quasi-dyadic codes in the NIST PQ CFP. Otherwise, similar story as lattices: relatively fast, but very large key sizes.

Isogenies are extremely new and only have a few credible cryptosystems based on them. The most prominent researchers leading this domain are Jao, Longa, de Feo, Plut and Galbraith. The two contenders are SIDH and the NIST proposal succeeding it, SIKE. These have the opposite advantage to lattices and codes, because their key sizes are incredibly small (the smallest among all post-quantum cryptosystems), but their key exchange time is commensurately slower. The additional benefit is that they use much of the same mathematics as traditional elliptic curves, which means you could design hybrid ECDH-like and SIDH-like schemes with a relatively small library.

There are some wonkier proposals (such as Joux’s Mersenne prime one), but these are the ones receiving the most research attention. I wouldn’t say it’s a solved problem, but I’m personally confident there will be mature cryptography available when quantum computers can practically break our current state of the art.

Re: Cryptographic Right Answers

#177

Earlier quoted context omitted.

Just curious - why the downvote?

At a guess, it might be because the things that you say are "missing" are specific to HTTP, yet the document says nothing (that I remember) about HTTP at all. The recommendations being discussed in the article are at a completely different level. It's like if I said, "you forgot to mention to disable root logins via SSH". While that might certainly be a good recommendation, it's out of scope as it has nothing to do w…

Ah, thank you. I fully understand now the stupidity of my response. The title itself says "cryptographic" in it, and my answers had nothing to do with that. My mistake.

Re: Cryptographic Right Answers

#179
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 was slightly surprised to see scrypt so high up the list, given its vulnerability to cache timing side channels.

Is this because you think the side channel isn't that important, or that getting the params for argon2 right is complex enough that you're cautious about recommending it more strongly, or is there something else that I'm missing? Apologies if you answered this elsewhere - I had a look and didn't find anything.

Re: Cryptographic Right Answers

#180
post #105

Earlier quoted context omitted.

I'm under the impression Argon2 is at least marginally better than scrypt as it has heavily analyzed side channel mitigations and such. Is scrypt better in some other way?

Argon2 and the PHC precipitated a lot of analysis that increased our confidence in scrypt, too. My point is that it doesn’t really matter, so optimize for availability. I like Argon2 for the stamp of approval, but dislike all the confusion around parameter selection and i-vs-d confusion. (I know argon2id exists.)

Doesn't scrypt suffer from much of the same parameter selection issues? I know I've had to choose some fairly obtuse values when using scrypt for login in a webapp.

In fact, taking a quick look again I find Argon2's "memorySizeKB" and "iterations" make much more sense to me than scrypt's "CostFactor" and "BlockSizeFactor" parameters as it's a lot clearer what's being impacted. I agree with the i-vs-d confusion, but in most cases I think using argon2id as you mentioned should resolve the contention as is already the suggested default in the IETF draft.

Post reply on HN