Live data from Hacker News

Cryptographic Right Answers

latacora.singles

111–120 of 243 posts

Re: Cryptographic Right Answers

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

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.

Re: Cryptographic Right Answers

#112
post #3
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…

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.

Re: Cryptographic Right Answers

#113

This article was worth writing, and I'm glad you wrote it. It is helpful. You might not realise it but: > If you could use KMS but encrypting is just a fun weekend project and you might be able to save some money by minimizing your KMS usage, use KMS. If you’re just encrypting secrets like API tokens for your application at startup, use SSM Parameter Store, which is KMS. You don’t have to understand how KMS works. Pa…

> Security Professionals seem to have an unfortunate habit of talking down to everybody else.

I understand the feeling, and I have a related one, which is that the crypto field seems to be too "Rock-Star" focused. Unlike most other areas of software engineering, where a design flaw is unlikely to be business-threatening[1] and so engineers are comfortable rolling their own, crypto is very much of the "get it exactly right or don't do it at all" category.

It's hard to get right, and it goes against many (most?) programmer's instinct of "I can code it up in a week(end)". Add to that the steady stream of news about some company's compromised security, and crypto experts who care to communicate to fix the software industry's happy-go-lucky culture are forced to become ever more strident and dumb-down the message to reach the widest possible audience.

And then people think they're being condescending...

It's a cultural issue based on a technical one, and I don't know how to fix it other than have software engineers be more careful.

On the "rock-star" thing, it's because of how much we depend on a few recognized sources of authority (here, cperciva, tptacek) who we trust to point us in the right direction in the every-changing minefield of crypto practices. Other than have the field stop evolving and best practices become common-sense (which they absolutely aren't currently), I don't know how to fix that either.

[1] they might cause bugs, they might cause downtime, they might cause frustration with users, but by themselves are unlikely to cost you [m/b]illions and kill your company

Re: Cryptographic Right Answers

#114

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.

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.

Re: Cryptographic Right Answers

#115
post #68
post #55

Earlier quoted context omitted.

Let's say talking directly to the internet.

If it's on the raspi side of powerful, just use OpenSSL, or maybe Go's TLS stack, again, assuming you can get away with it. On smaller systems, things get weird. If you can't afford go/openssl, there aren't a lot of things I'm very confident in. BearSSL near the top of the list. That's still double-digits kilobytes of RAM though, so maybe I just ate all your budget. You might be in one of the cases where a NOISE prot…

What's wrong with PolarSSL/Mbed TLS? It is designed for low-end ARM processors and is directly backed by ARM.

Re: Cryptographic Right Answers

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

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

Re: Cryptographic Right Answers

#117
post #39
post #34

Earlier quoted context omitted.

1) Yes, use SHA512/256 (truncated SHA512). I don't think I'd default to SHA3 anywhere. 2) Are you entirely convinced you actually need client tokens? In particular, can you get away with a 256-bit random token and store the session in a database? 3) Re: HMAC input malleability: yep, concat and HMAC is fine. Serializing JSON or whatever is also fine. You're usually providing the tag (that's what the output of HMAC is…

1) Huh. Weird it exists at all then. 2) Hrm. I guess maybe? As I understand it, the reason for a client token is to have stateless servers, so the server doesn't need to look up a valid token upon every request--which scales better. In my case, the API endpoint is for something that doesn't (and won't) get a lot of traffic, so I can probably get away with a 256-bit random token over TLS? Since it's over TLS, there pr…

1) Adam Langley explains why SHA-3 exists and why it shouldn't be used:

https://www.imperialviolet.org/2017/05/31/skipsha3.html

Re: Cryptographic Right Answers

#118

Missing 1. Content security policy headers for web 2. "strict" Samesite cookie flags for CSRF and authentication tokens Difference of opinion Didn't argon2 win the last password hashing competition?

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 with what is being discussed.

Re: Cryptographic Right Answers

#119
post #71

Earlier quoted context omitted.

> Generally: don't do encrypted tokens Can you point to a RTFM on why not? I'm sure it's a big list of reasons but where can I read about the biggest one?

Because they cause more problems than they solve. A lot of the implementations _aren't even faster_, but the laundry list of security bugs they have caused is very real. Suddenly you get to worry about irrevocable tokens in order to solve scaling problems you don't have. A good intro is: http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.pn...

from: http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...

Re: Cryptographic Right Answers

#120

Here is a summary, roughly ordered from constant to changed the most. Percival Ptacek Latacora 2009 2015 2018 Online backups tarsnap tarsnap tarsnap Symmetric key length 256-bit 256-bit 256 bit Symmetric “Signatures” HMAC HMAC HMAC Random IDs 256-bit 256-bit 256-bit Hashing algorithm SHA256 (SHA-2) SHA-2 SHA-2 Password handling scrypt scrypt scrypt PBKDF2 bcrypt argon2 PBKDF2 bcrypt PBKDF2 Website security OpenSSL Op…

Quick update though: for client-server security, I copy-paste misquoted Colin and just now noticed it (because Colin noticed it for me). The 2015 document correctly says Colin's client-server recommendation is "custom RSA protocol", but when I formatted this document I managed to accidentally make it say the same as his recommendation for "website security".

I regret the error (but not the recommendation; don't make your own custom RSA-based transport protocol).

Post reply on HN