Live data from Hacker News

Cryptographic Right Answers

latacora.singles

71–80 of 243 posts

Re: Cryptographic Right Answers

#71
post #46

Earlier quoted context omitted.

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?

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

Re: Cryptographic Right Answers

#72
post #69

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

The audience for this document is software engineers. It woudl be impossible to write a document that serves every audience. Unless you're also suggesting that you should AES-CMAC a password reset token? And if we're going to go there, why not PMAC? Or OMAC?

Re: Cryptographic Right Answers

#73
post #45

Earlier quoted context omitted.

I think the most useful parts of the document are the 'really try hard to use TLS for any comms problem' or 'try to use Amazon's key management for encryption' answers, and pointers to good libraries. Beyond that: developers aren't normally tasked with building systems out of cryptographic primitives. Those that do are typically (hopefully!) experienced enough to pick a solid primitive. Those who need to look-up whic…

Usually, when I think composition of primitives I think MtE vs EtM vs M&E; but that feels like something that's covered. There's also protocol design, but that's also covered ("use TLS"). Can you give an example of the sort of composition you're talking about? FWIW I'm more hopeful that I can make mTLS work immanently as part of the environment than everyone getting it right in their app. Less httpd more caddy, if th…

Ha yeah, composition was a bad choice of word.

Maybe an quick example off the top of my head would be: you know you need to authenticate and perhaps additionally 'encrypt' something --- for say a software update, fancy over-Bluetooth authentication scheme etc.

You need to pick: symmetric or asymmetric schemes? Auth then encrypt? What does replay of an old signature or MAC mean for your system? Key usage limitations? Key re-use? Quite a few ways you can err where the choice of e.g Ed25519 over P-256 ECDSA pales in comparison.

Or in other words: most people are trying to build a secure system, and where security is only achieved by the combination of the protocols, primitives used.

W.r.t TLS, yeah, bake in default configs as part of an environment where you can, although there'll always be plenty of people developing directly against the software API, and compatibility issues will typically play a part.

Re: Cryptographic Right Answers

#74
post #60

Earlier quoted context omitted.

Can you explain what is easy to get wrong? You want a CSPRNG to generate the IV, HMAC key, and AES key (which Go and node both have). Are their other implementation details that are complex?

Example: if you don't specify that something is the last token, an attacker can trivially truncate.

That is what the 512bit MAC is for

Re: Cryptographic Right Answers

#75
post #28

Earlier quoted context omitted.

Did you feel that entire graf was condescending or just parts of it? The "you don't have to understand how KMS works" perhaps? (It's definitely not meant that way :-))

I admit that I wrote that before I read the rest of the article. The rest of the article is great :). I don't know why that one paragraph stuck out at me so much, but it triggered the "screw you, don't tell me what to do" reflex.

When it comes to security, that reflex is almost categorically wrong. I say "almost" because the people who tell people like us what to do are also reading this thread.

You don't get to have an ego when it comes to security or operational reliability (two separate fields, but ones with often similar resistance from developers). It just doesn't work that way.

Re: Cryptographic Right Answers

#76
post #61

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

This requires the whole plaintext/cipher text to fit into memory. For small blobs I would agree that GCM is perfect, but for anything larger you end up with extra projects like https://github.com/minio/sio trying to break streams into smaller ordered chunks. They are on v2 now.

Re: Cryptographic Right Answers

#77
post #63
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…

To pick on the memory-safe languages bit:

- I get it. But libcrypto is less likely to have some insane UAF bug than, say, libtiff or whatever. If you're going to use unsafe code, libcrypto and libsodium are pretty great choices. I wrote a Clojure (so JVM) library that binds libsodium FWIW.

- I hear nice things about Rust's ring lib. Still gotta FFI from OCaml or the JVM though.

- A lot of the recommendations on this list are algorithms designed to be safe to implement. For example, it's unlikely that a JVM impl of XSalsa20 + Poly1305 is suddenly unsafe because of the environment you're running in. This is NOT TRUE for things like AES-GCM; firstly a lot of naive AES implementations are insecure, and good luck doing GHASH safely in software.

Re: Cryptographic Right Answers

#78
post #66

Earlier quoted context omitted.

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".

Assume it is a NodeJS Electron app that people run locally (and in the future, a browser extension).

(there is also a web version, which of course could always be compromised, but we're encouraging users to download the app so they have full control and don't have to worry about that. But they need to be compatible.)

Telling our users not to use crypto isn't an option. Recommending our users not use a browser is possible, but forcing them not to use a browser isn't an option either.

Re: Cryptographic Right Answers

#79
post #45

Earlier quoted context omitted.

Usually, when I think composition of primitives I think MtE vs EtM vs M&E; but that feels like something that's covered. There's also protocol design, but that's also covered ("use TLS"). Can you give an example of the sort of composition you're talking about? FWIW I'm more hopeful that I can make mTLS work immanently as part of the environment than everyone getting it right in their app. Less httpd more caddy, if th…

Ha yeah, composition was a bad choice of word. Maybe an quick example off the top of my head would be: you know you need to authenticate and perhaps additionally 'encrypt' something --- for say a software update, fancy over-Bluetooth authentication scheme etc. You need to pick: symmetric or asymmetric schemes? Auth then encrypt? What does replay of an old signature or MAC mean for your system? Key usage limitations?…

When I figure out how to pour that in a document I'll let you know :-D Until then it's one small bite at a time. But yeah, you're right: this is the style of audit and design work we do for clients.

General reco from your list: the answer is always symmetric unless you literally can not accomplish the same thing any other way. (And you probably can.)

Re: Cryptographic Right Answers

#80
post #67

Earlier quoted context omitted.

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.

When you're that small it really requires more context. What are you trying to do?

I've deployed TLS in 50 KiB flash and 6 Kb RAM. But I could rely on hardware support for some public key operations and could pick a single ciphersuite, and controlled the server end as well.

The boring answer is that you'll need to identify the set of primitives you need and then find a library that matches. I can't think of any single primitive that would break that budget, so it'll depend on how many you need!

Post reply on HN