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

211–220 of 243 posts

Re: Cryptographic Right Answers

#211

Post by rsync »

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.

Your point is well taken. Thanks.

Re: Cryptographic Right Answers

#212

Post by charonn0 »

> Avoid: designing your own encrypted transport, which is a genuinely hard engineering problem; using TLS but in a default configuration, like, with “curl”; using “curl”, IPSEC.

I'm not sure what they're saying here. Is there a problem with the way curl handles TLS?

Re: Cryptographic Right Answers

#213

Post by asd2r23dasd »

zx2c4 wrote: post #183
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…

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…

Ah cheers for the link. Yeah a proof at the level of abstraction up from a single pattern would be lovely. I don't really have 'concerns' as such: it's just if your risk profile is the thing that has kicked you away from TLS towards Noise then you need a good justification (notwithstanding, a proof of security for a new AKE should really be par for the course).

IMO the interesting aspect with the development of Noise will be if it can avoid bloat. From the mailing list I can see that there's solid awareness of that risk (would assume Trevor is aware anyway), but it will be interesting to see how the simplicity of pattern API will handle things like signatures, when they're inevitably added. I see at least one Noise-using project has already made the leap on that front.

Re: Cryptographic Right Answers

#214

Post by stouset »

lvh wrote: post #199
andrewflnr wrote: post #111

Earlier quoted context omitted.

Just how much trouble can you get into with HMAC? I recently ran into some HMAC-based crypto that I thought was pretty sketchy based on the "no custom crypto" principle, but I'm wondering if my concerns were overblown. I haven't found any obvious holes in it, but I'm not an expert so I don't know if that means much.

HMAC will, hell or high water (assuming you're not doing HMAC-CRC32 or whatever :-)) give you a MAC. (It'll do slightly better; unlike, say, GMAC -- but that's a boring detail for now.) You can shoot yourself in the foot with HMAC but it won't be because of HMAC; for example: if your messages don't contain a nonce or timestamp they might be replayable or something. But that's not an HMAC flaw. So to answer your quest…

Also if you don't use an unambiguous encoding if you're signing multiple aggregated fields. Either by using field separators that can't occur in the data, or by using a format that prefixes fields with their lengths.

Re: Cryptographic Right Answers

#215

Post by stouset »

iamwil wrote: post #22
lvh wrote: post #14

Earlier quoted context omitted.

I might be misunderstanding you, but... 'tptacek and I worked on the 2018 recommendations in the article, and I think we still agree with what we said last week when we edited it :-)

Ah, didn't know he also worked on it. It wasn't obvious in the article. Then I have two basic questions (for either you and tptacek): 1) Given I just need to hash the contents of a file for content-addressed data (like in git), it seemed like sha2-256 would be sufficient. However, it seemed like on 64-bit machines, sha2-512 is faster, and I can just lop off the first 256 bits. Is that correct? And in what cases would…

> However, it seemed like on 64-bit machines, sha2-512 is faster, and I can just lop off the first 256 bits.

Just as a heads-up, SHA-512/256 isn't exactly just SHA-512 with 256 bits chopped off. It also uses a unique IV. This might not be a big difference in practice, but I'd lean toward using SHA-512/256 explicitly, and not SHA-512 truncated to 256 bits.

Re: Cryptographic Right Answers

#216

Post by lvh »

stouset wrote: post #214
lvh wrote: post #199

Earlier quoted context omitted.

HMAC will, hell or high water (assuming you're not doing HMAC-CRC32 or whatever :-)) give you a MAC. (It'll do slightly better; unlike, say, GMAC -- but that's a boring detail for now.) You can shoot yourself in the foot with HMAC but it won't be because of HMAC; for example: if your messages don't contain a nonce or timestamp they might be replayable or something. But that's not an HMAC flaw. So to answer your quest…

Also if you don't use an unambiguous encoding if you're signing multiple aggregated fields. Either by using field separators that can't occur in the data, or by using a format that prefixes fields with their lengths.

Right. You can use JSON or something to get out of this quick.

Re: Cryptographic Right Answers

#217

Post by asd2r23dasd »

colmmacc wrote: post #112
pvg wrote: post #3

Earlier quoted context omitted.

Do you lot have some special insight into the security of ELB, since you are so bullish on it? It's a sweet service but it's one of the more black-boxy, voodoo-ish things AWS offers and always gives me mild, irrational pangs of paranoia as a termination point.

I've been working on ELB day-to-day since 2013, first as Principal engineer and now as one of the AWS services I focus on and help out. I do have some special insight - feel free to AMA. I can get pretty deep on the TLS/SSL side if you have specifics; I'm also the main author of s2n, our Open Source implementation of TLS, and a participant in the TLS1.3 process.

Hey, this is largely off-topic but worth a punt: do you have any info on when AWS IoT (maybe other AWS services as well?) will move off the dependency on the Verisign RSA/SHA-1 CA? I'd love to get a certificate chain that was ECDSA or RSA sigs only (and would also love to be able to turn off SHA-1 for the obvious reason).

Re: Cryptographic Right Answers

#218

Post by pvg »

lvh wrote: post #7
pvg wrote: post #3

Earlier quoted context omitted.

Do you lot have some special insight into the security of ELB, since you are so bullish on it? It's a sweet service but it's one of the more black-boxy, voodoo-ish things AWS offers and always gives me mild, irrational pangs of paranoia as a termination point.

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

Re: Cryptographic Right Answers

#219

Post by andrewflnr »

lvh wrote: post #199
andrewflnr wrote: post #111

Earlier quoted context omitted.

Just how much trouble can you get into with HMAC? I recently ran into some HMAC-based crypto that I thought was pretty sketchy based on the "no custom crypto" principle, but I'm wondering if my concerns were overblown. I haven't found any obvious holes in it, but I'm not an expert so I don't know if that means much.

HMAC will, hell or high water (assuming you're not doing HMAC-CRC32 or whatever :-)) give you a MAC. (It'll do slightly better; unlike, say, GMAC -- but that's a boring detail for now.) You can shoot yourself in the foot with HMAC but it won't be because of HMAC; for example: if your messages don't contain a nonce or timestamp they might be replayable or something. But that's not an HMAC flaw. So to answer your quest…

Well, sure, but it's not AES's fault when you reuse nonces, either. :)

Re: Cryptographic Right Answers

#220

Post by garmaine »

tptacek wrote: post #206
garmaine wrote: post #144

Earlier quoted context omitted.

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.

You suggest using Ed25519 which is vulnerable to third party signature malleability as its cofactor is 8 and the library doesn’t check that the signature is actually a point in the curve.

On the other point, then don’t list deterministic nonces as a comparative advantage since it is not actually distinguishing.

Post reply on HN