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

201–210 of 243 posts

Re: Cryptographic Right Answers

#201

Post by loup-vaillant »

lvh wrote: post #195
jfindley wrote: post #179

Earlier quoted context omitted.

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

Any of them are fine. I don't think cache timing side channels or any of the other fun scrypt trivia (like PBKDF2-induced trivial collisions) are how you're gonna get popped. If you wanna do Argon2id that's fine too :-)

I don't get the rationale for Argon2id. If you don't expect (cache) timing attacks, Argon2d is computationally stronger. If you do, Argon2i is immune. Argon2id is partially immune, so if someone can do timing attacks, they can crack half the algorithm, and need to do the rest the hard way.

What is the rationale behind the assumption that this middle ground is better than straight up Argon2i for general purpose password derivation? I've never seen it explained anywhere.

Re: Cryptographic Right Answers

#202

Post by CiPHPerCoder »

Wingwing wrote: post #168
rsync wrote: post #147

Earlier quoted context omitted.

"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)." borg[1] has been referred to as "the holy grail of backups"[2] and is supported at rsync.net.[3] The end result is encrypted, zero knowledge remote backups on a ZFS filesystem that you can SSH to. I think everyone here knows all about rsync.net, but here are some examples:[4]…

This isn't zero-knowledge. Please use this opportunity to educate the public instead of muddying the term for the sake of marketing buzzwords.

To add to this comment: https://paragonie.com/blog/2016/08/crypto-misnomers-zero-kno...

Re: Cryptographic Right Answers

#203

Post by lvh »

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.

Re: Cryptographic Right Answers

#204

Post by CiPHPerCoder »

exabrial wrote: post #190

Also, any opinion on the Million Dollar Curve? https://cryptoexperts.github.io/million-dollar-curve

I can't speak for the authors of the Latacora page but I generally find this unnecessary.

We had enough curve arguments on the CFRG leading up to RFC 7748/8032 that any additional curves for ECC gets filed under "needless bikeshedding".

Why not pick PinkBikeShed or FuchsiaBikeShed instead?

Re: Cryptographic Right Answers

#205

Post by lvh »

loup-vaillant wrote: post #201
lvh wrote: post #195

Earlier quoted context omitted.

Any of them are fine. I don't think cache timing side channels or any of the other fun scrypt trivia (like PBKDF2-induced trivial collisions) are how you're gonna get popped. If you wanna do Argon2id that's fine too :-)

I don't get the rationale for Argon2id. If you don't expect (cache) timing attacks, Argon2d is computationally stronger. If you do, Argon2i is immune. Argon2id is partially immune, so if someone can do timing attacks, they can crack half the algorithm, and need to do the rest the hard way. What is the rationale behind the assumption that this middle ground is better than straight up Argon2i for general purpose passwo…

Not everyone who needs to store a password is in a position to judge if cache timing attacks will never be in their threat model. Sane recommendations for people who would like to just not mess up their password database matter.

I'm assuming you're familiar with the Argon2 RFC sections on Argon2id? I think it goes into quite a bit of detail between the two.

Re: Cryptographic Right Answers

#206

Post by tptacek »

garmaine wrote: post #144
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…

What about the disadvantageous aspect of djb’s curves, like that they have a non-unit cofactors? That’s a huge foot-gun that has already maimed a few people. Also, deterministic signing nonces have NOTHING to do the DSA/ECDSA vs alternative signatures scheme. The library you recommend just uses its own deterministic signer internally, just as any ECDSA implementation can and should (e.g. bitcoin’s does).

The only place we discuss directly using Curve25519 is in straightforward DH, as with X25519.

There is more distinguishing Ed25519 from Deterministic ECDSA than deterministic nonce generation.

Re: Cryptographic Right Answers

#207

Post by loup-vaillant »

lvh wrote: post #205
loup-vaillant wrote: post #201

Earlier quoted context omitted.

I don't get the rationale for Argon2id. If you don't expect (cache) timing attacks, Argon2d is computationally stronger. If you do, Argon2i is immune. Argon2id is partially immune, so if someone can do timing attacks, they can crack half the algorithm, and need to do the rest the hard way. What is the rationale behind the assumption that this middle ground is better than straight up Argon2i for general purpose passwo…

Not everyone who needs to store a password is in a position to judge if cache timing attacks will never be in their threat model. Sane recommendations for people who would like to just not mess up their password database matter. I'm assuming you're familiar with the Argon2 RFC sections on Argon2id? I think it goes into quite a bit of detail between the two.

OK, the latest version of the RFC is much better than what I had initially read. Still, I see no discussion of side channel attacks with Argon2id. When they discuss the "best attack", it looks like they're discussing offline attacks that makes no use of timing information.

Assuming timing attacks breaks Argon2d entirely at relatively little cost, the attacker advantage for a 1-pass Argon2id would be twice that of a one-pass Argon2i: about 10. A three pass Argon2i with a third of the memory looks better: about 3. Not that it matters that much, but still.

Or is my threat model of timing attacks (which assumes they could recover whatever they can at little cost) too paranoid?

Re: Cryptographic Right Answers

#208

Post by lvh »

loup-vaillant wrote: post #207
lvh wrote: post #205

Earlier quoted context omitted.

Not everyone who needs to store a password is in a position to judge if cache timing attacks will never be in their threat model. Sane recommendations for people who would like to just not mess up their password database matter. I'm assuming you're familiar with the Argon2 RFC sections on Argon2id? I think it goes into quite a bit of detail between the two.

OK, the latest version of the RFC is much better than what I had initially read. Still, I see no discussion of side channel attacks with Argon2id. When they discuss the "best attack", it looks like they're discussing offline attacks that makes no use of timing information. Assuming timing attacks breaks Argon2d entirely at relatively little cost, the attacker advantage for a 1-pass Argon2id would be twice that of a o…

I think the RFC suggests sufficiently conservative parameters that it doesn't matter much. And, more generally: I don't think Argon2i vs Argon2d vs Argon2id vs scrypt is where people should be racking their brains.

Re: Cryptographic Right Answers

#209

Post by asd2r23dasd »

lvh wrote: post #172
asd2r23dasd wrote: post #153

Earlier quoted context omitted.

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…

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 be largely similar to the same subset you could safely task with designing and implementing a custom AKE+messaging protocol from scratch anyway. I think the level of competency you need available is on the very far end of the spectrum. Edit: and on the risk point, even if the library has been eyeballed less, at least you know with mbedTLS that if a bug drops you'll get a patch pretty quickly. If you goof up your Noise impl you're on your tod.

Re: Cryptographic Right Answers

#210

Post by rsync »

Freaky wrote: post #185
rsync wrote: post #147

Earlier quoted context omitted.

"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)." borg[1] has been referred to as "the holy grail of backups"[2] and is supported at rsync.net.[3] The end result is encrypted, zero knowledge remote backups on a ZFS filesystem that you can SSH to. I think everyone here knows all about rsync.net, but here are some examples:[4]…

One of the nicer bits of borg is the ability to restrict it to append-only mode, which limits the damage compromised hosts can do. e.g in authorized_keys: command="/usr/local/bin/borg serve --append-only --restrict-to-path=/home/backup/bla",restrict ... I use this with passphrase-free ssh keys to allow automated backups without permitting the destruction of any existing backups. Do you get enough control do to that o…

"Do you get enough control do to that on rsync.net?"

Yes. You have your own .ssh folder in your account and can edit (upload) your keys as you see fit.

Also, if you have our ZFS snapshots enabled, those are immutable/readonly - so even if you aren't using a sophisticated tool like borg, you still have snapshots of your data that are immune to attack - even from someone who knows all of your credentials.

Post reply on HN