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

61–70 of 243 posts

Re: Cryptographic Right Answers

#61

Post by tptacek »

Xeoncross wrote: post #43

> Encrypting Data Percival, 2009: AES-CTR with HMAC. I just found that AES-CTR + HMAC is very simple and doable in in languages like Go and Javascript for large objects which can't (or shouldn't) all be put into memory at the same time. In fact, a popular google drive client uses this: https://github.com/odeke-em/drive/wiki/End-to-End-Encryption (assuming standard secure key generation for both the AES-CTR stream and…

Go already gives you an AEAD API with "Seal" and "Open" and implements it with GCM, which is what you should use in a clean-slate designs if you're sticking to the standard library.

Re: Cryptographic Right Answers

#62

Post by marknadal »

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…

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 browser constraints, what are your thoughts?

Thanks!

Re: Cryptographic Right Answers

#63

Post by lmm »

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 right answers exist for code that has to run in phone apps? As javascript in a web browser?

If I want to do asymmetric encryption/signatures and am terrified of the security implications of non-memory-safe languages and/or libraries written in them, do I have any good options? (i.e. is there something I could use from a JVM or an OCaml unikernel or the like?)

(I would ask the same thing about website security and transport encryption, but honestly I'm going to stick with ocaml-tls whatever you say)

Re: Cryptographic Right Answers

#64

Post by ketralnis »

lvh wrote: post #46
iamwil wrote: post #39

Earlier quoted context omitted.

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…

It's not always a foregone conclusion that it scales better. I've seen people argue that when using ECDSA verification that's 4x longer than an in-DC RTT. Usually: DB kv lookups aren't even close to the most expensive thing your app does. Generally: don't do encrypted tokens. If you must: don't do JWT for this. Just secretbox a thing and be done with it, or use PASETO[0]. [0]: https://github.com/paragonie/paseto

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

Re: Cryptographic Right Answers

#65

Post by tptacek »

lmm wrote: post #63
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 right answers exist for code that has to run in phone apps? As javascript in a web browser? If I want to do asymmetric encryption/signatures and am terrified of the security implications of non-memory-safe languages and/or libraries written in them, do I have any good options? (i.e. is there something I could use from a JVM or an OCaml unikernel or the like?) (I would ask the same thing about website security an…

My advice regarding crypto code that needs to run in Javascript in a web browser has not changed: don't design systems that depend on crypto running in a web browser.

The rest of this should be fine in a native phone app.

Re: Cryptographic Right Answers

#66

Post by lvh »

marknadal wrote: post #62
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…

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…

Are you shipping a real webapp where the server fully controls the JS anyway, or are you shipping, like, a WebExtension?

I think the TL;DR is "I'm not sure you can do this safely without having a security person on your team".

Re: Cryptographic Right Answers

#67

Post by vardump »

loup-vaillant wrote: post #32
suf wrote: post #17

Earlier quoted context omitted.

Hey, can you share some crypto advice for limited embedded systems (let's say minimum being 32bit cortex-M0). Say for firmware updates, user data uploading, etc.

Use Monocypher, TweetNaCl, or Libsodium. Monocypher is portable (C99/C++), pretty fast, and has low memory footprint (generated binary between 30kB and 60kB). Problem: it isn't trusted yet. (I'd like to run a bug bounty, but I'm not sure how I should go about it.) TweetNaCl is portable (C89), has low memory footprint, and is made by trustworthy professional cryptographers. Problem: it is slow . Libsodium is blazing f…

What could be used with a small/medium sized microcontroller, something like 64 kB total flash budget and 4-20 kB RAM?

IOW, Cortex M0 territory.

Small IoT is about this size, so I think many will be interested in some answers... any answers.

Say, for securely transmitting sensor data to an x86 server (or similar) without hardcoding symmetric keys on the devices.

Re: Cryptographic Right Answers

#68

Post by lvh »

suf wrote: post #55
lvh wrote: post #42

Earlier quoted context omitted.

Disclaimer: I'm not 'tptacek but I'm one of the Latacora principals and co-edited this document. Embedded crypto gets weird fast. General recommendations are a little tricky, but: is that device talking to the internet directly or some kind of IoT hub or whatever?

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 protocol instance is in fact the right answer; depends a little on what else the box is doing and how frequently.

Sorry, I get that it's not a satisfying answer :-) It's complicated!

Re: Cryptographic Right Answers

#69

Post by brohee »

A bit tired with "Just use HMAC". HMAC makes you pull a hash dependency, which is not much if you do software, but can be a waste of silicon if all you want is a MAC. If you already spent real estate on AES, then CMAC becomes a lot more attractive...

This is the reasons it's at the core of SCP03, the smartcard world is very sensitive to transistor count...

Re: Cryptographic Right Answers

#70

Post by loup-vaillant »

tptacek wrote: post #59
MrBuddyCasino wrote: post #50

Earlier quoted context omitted.

Got an opinion on BearSSL?

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 however to get even further than Monocypher on the constant time thing. Monocypher needs the platform to provide constant time 64-bit multiplication. Most do, but not all.)

Post reply on HN