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

231–240 of 243 posts

Re: Cryptographic Right Answers

#231

Post by [deleted] »

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…

[deleted]

Re: Cryptographic Right Answers

#232

Post by loup-vaillant »

tptacek wrote: post #228
loup-vaillant wrote: post #156

Earlier quoted context omitted.

It may help if we point out that we now have at least two independent implementations of XChacha20: your Libsodium and my Monocypher. This should raise confidence. I'd love to add the extended nonce to RFC 7539, though.

Why would implementation in your own library raise confidence? Sodium is interesting because thousands of people use it.

> Why would implementation in your own library raise confidence?

I thought this would be obvious.

I didn't look at Sodium to implement XChacha20, but I did compare our two implementations (my test vectors come from Sodium). At the very least, this is evidence that Sodium did things right.

> Sodium is interesting because thousands of people use it.

By that metric, OpenSSL is even more interesting. Have those users also tested Sodium? I personally put more weight in Matthew Green's security audit.

Likewise, Monocypher is interesting because of its small size (easy to audit, won't take months like Sodium), its paranoid test suite, and to a lesser degree the proof that Poly1305 works. https://monocypher.org/poly1305-proof

Re: Cryptographic Right Answers

#233

Post by lvh »

pvg wrote: post #218
lvh wrote: post #7

Earlier quoted context omitted.

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

Makes sense, thanks. Did the document mention ALB yesterday?

I didn’t put it up, but I think I mentioned ALB in one of the editing passes. Could’ve missed it then though, so no idea :)

Re: Cryptographic Right Answers

#234

Post by lvh »

asd2r23dasd wrote: post #209
lvh wrote: post #172

Earlier quoted context omitted.

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…

I would definitely agree, yeah. Notwithstanding the legacy protocol core, Noise has great potential to allow people to step away from the asn1, X509 etc TLS cruft. Comparing between those two options is a question of appetite for risk, your threat model, and the level of competency you have available. On the latter note, _at the moment_, I think the subset of people who are capable of taking advantage of Noise would…

Appetite for risk, threat model, competency available _and_ platform constraints, IMO. I think we're in violent agreement: you should only do this if you have someone on board who knows what the hell they're doing, and you literally can't afford a decent TLS stack on that device.

Re: Cryptographic Right Answers

#235

Post by dsacco »

loup-vaillant wrote: post #70
tptacek wrote: post #59

Earlier quoted context omitted.

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

I'm not yet to the point where I can recommend my thing without even mentioning the other two competitors. I did get bloody thorough, though, and I do think it is good enough for me to bet my job. (Meaning, I'd be willing to lose my job if my employer uses Monocypher on my watch, and data gets leaked because of that choice.) (As for the original question, I don't know BearSSL enough to have an opinion. It does seem h…

> (Meaning, I'd be willing to lose my job if my employer uses Monocypher on my watch, and data gets leaked because of that choice.)

Would you be willing to be personally liable for that data leak?

(Put aside the philosophical question of whether or not it's reasonably for developers to be personally liable for their software failures - I'm interested in how far your confidence in your cryptography goes).

Re: Cryptographic Right Answers

#236

Post by chme »

lvh wrote: post #203
chme wrote: post #178

Why is this page not available over https? A bit ironic that we have to trust the connection between us and the server to get advice about security.

Because we're messing with a little microblogging service and haven't set up HTTPS for it yet.

There seems to be an old version with expired letsencrypt certificates still running: https://latacora.singles

Re: Cryptographic Right Answers

#237

Post by evrydayhustling »

lvh wrote: post #194
evrydayhustling wrote: post #161

Earlier quoted context omitted.

This guide is amazing. It's incredibly useful to be offered one happy path that lets non-experts (myself included) get started easily. BUUUUUT I can't help reading these and being reminded of Vernor Vinge's "Net of a Million Lies", where people looking for shortcuts end up getting traps. We know that state actors have haunted academic and industry efforts to disseminate info and implementations of cryptography, inser…

Surely HN counts as some form of public scrutiny. If all of us are compromised, then yeah, you're fucked. But we've tried not speaking up and telling people to leave it to the pros and we got like a decade of CBC padding oracle bugs so that didn't work out and now we're trying to at least give people a fighting chance to stay on our professional opinion of the straight and narrow. Disclaimer: I'm a co-editor of the n…

Yeah, I'm mostly thinking about about taking what works about HN and naming it or even extracting / concentrating it. Some thoughts about what that is: - individual views and reps - open to competing interests - signal / noise ratio

All could be amplified.

Re: Cryptographic Right Answers

#238

Post by marknadal »

ryan-c wrote: post #154
marknadal wrote: post #62

Earlier quoted context omitted.

Question, I build webapps, meaning I only have access to the native WebCrypto API that doesn't have some of these other things mentioned. Advice/pointers? Here is our setup: ECDSA sign/verify P-256; ECDH enc/dec P-256; PBKDF2 password + salt = extension, using SHA-256, 5000 iterations, 64 ks; private key encrypted with PBKDF2 extension via AES-CBC But it isn't like WebCrypto gives you access to much else. So given br…

5000 iterations of PBKDF2 is very low. I'd use at least 100,000. Benchmark it, but that should be reasonable even on mobile provided you're caching the keys.

Thank you, I missed a 0: 50,000

I shall up it to 100K!

Re: Cryptographic Right Answers

#239

Post by JoachimS »

lvh wrote: post #196
JoachimS wrote: post #175

Earlier quoted context omitted.

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.

That's a good point; as I recall reading it it was supposed to say HMAC-SHA256. But, to be clear: HMAC-MD5 isn't really busted, I just would prefer not to see it in new code.

Exactly. We want to move away from md5 (and SHA-1) and has been trying to do that for many years now. So we should not use it _even if_ it is ok in a specific construction. It adds yet another dependency that makes it harder to remove md5.

Re: Cryptographic Right Answers

#240

Post by Toast_25 »

evrydayhustling wrote: post #161
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…

This guide is amazing. It's incredibly useful to be offered one happy path that lets non-experts (myself included) get started easily. BUUUUUT I can't help reading these and being reminded of Vernor Vinge's "Net of a Million Lies", where people looking for shortcuts end up getting traps. We know that state actors have haunted academic and industry efforts to disseminate info and implementations of cryptography, inser…

There are waaaayyyy easier and cheaper ways to get your private information than by a massive, distributed covert operation designed to make your encryption implementations slightly easier to brute-force.
Post reply on HN