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

181–190 of 243 posts

Re: Cryptographic Right Answers

#181

Post by lvh »

piracykills wrote: post #180
lvh wrote: post #105

Earlier quoted context omitted.

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

Re parameter selection, I’m referring to:

https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03#sectio...

Specifically:

> We recommend the following procedure to select the type and the parameters for practical use of Argon2.

As opposed to just pick a profile, which, to be fair, the RFC also suggests :) So I guess that’s a fair point, it just feels like as with the i-vs-d thing there’s just more song and dance around it that I wish wasn’t there. The suggestion in the RFC vs published 3rd party recommendations (eg jjarmoc’s NNC reco) are also off by a factor of 100 or so? I’m happy to buy that that’s an unfair subjective impression, but when I was reviewing an argon2id python implementation last week I really just wanted to give people a function that just does “encrypt my damn password already”. Maybe that’s up to the implementation layers job, that’s fine - I did that for txscrypt too and I don’t remember where I got the magic numbers from :)

To be clear in case someone else reads this out of context: I am not saying not to use Argon2id!

Re: Cryptographic Right Answers

#182

Post by gshayban »

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 libhydrogen's NORX construction with the Gimli permutation for AEAD and hashing? Seems like it checks a lot of boxes (from a layman's perspective.)

Re: Cryptographic Right Answers

#183

Post by zx2c4 »

asd2r23dasd wrote: post #153
lvh wrote: 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…

There's another paper besides the RHUL one, which preceded it, using tamarin: https://git.zx2c4.com/wireguard-tamarin/tree/wireguard.m4 https://www.wireguard.com/papers/wireguard-formal-verificati... There are other groups who are also currently working on similar and better proofs. I think the end goal is to get proofs of the general pattern language of Noise rather than just the WireGuard handshake (IKpsk2), which will probably then satisfy your concerns with Noise. The Noise project itself is also working on things like NoiseSocket which will be more of an easily pluggable "right answer".

Re: Cryptographic Right Answers

#184

Post by Freaky »

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.

Restic's threat model assumes trusted systems - the ability to make a backup also implies the ability to destroy and tamper with existing ones. Tarsnap has fine-grained access controls which can severely restrict hosts:

https://www.tarsnap.com/man-tarsnap-keymgmt.1.html

e.g. you may give each host their own write-only key so they can automatically create new snapshots, while keeping the keys that permit reading and deleting old snapshots on separate machines with separate passphrases.

Re: Cryptographic Right Answers

#185

Post by Freaky »

rsync wrote: post #147
jlgaddis wrote: post #114

Earlier quoted context omitted.

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.

"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 on rsync.net?

Re: Cryptographic Right Answers

#186

Post by sametmax »

Can someone explain to a layman why you need to avoid RSA ? Is this only for the particular use case the article talks about or you should avoid it for other things, like encrypting a hard drive?

Re: Cryptographic Right Answers

#187

Post by CiPHPerCoder »

sametmax wrote: post #186

Can someone explain to a layman why you need to avoid RSA ? Is this only for the particular use case the article talks about or you should avoid it for other things, like encrypting a hard drive?

I've covered this before, targeting the PHP community, but most likely generally applicable: https://paragonie.com/blog/2016/12/everything-you-know-about...

The short of it is: If you're interoperating with anything in the real world, you're forced to use insecure modes. And even if you're not, the library you'll be working with probably has insecure defaults. Unless your job title rhymes with 'Cryptography Engineer', steer clear of it.

Re: Cryptographic Right Answers

#188

Post by exabrial »

CiPHPerCoder wrote: post #171
michaelt wrote: post #167

Earlier quoted context omitted.

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

I found this article helpful: https://web-in-security.blogspot.com/2015/09/practical-inval...

Essentially, a bunch of ECC implementations didn't do proper bounds checking and leaked data. ECC still offers a lot of benefits in terms of key size, performance, and security, however, so do your research carefully.

Re: Cryptographic Right Answers

#189

Post by exabrial »

Can you expand on the DSA/ECDSA problems? One this I greatly dislike is having "only one option" of RSA. In my opinion, it's better to have a variety of secure algorithms available and that are well studied, so if a new attack emerges we're not completely hosed.

Also, while I don't believe NIST is a mouthpiece for the NSA, I'm curious why they haven't proposed some alternatives to P-256, given some of the difficultly implementing it correctly. Is anyone aware if they are working on this?

Post reply on HN