Cryptographic Right Answers • Hacker News Board

Re: Cryptographic Right Answers

#81

Post by loup-vaillant » Tue, Apr 03, 2018, 10:37 PM UTC

vardump wrote: post #67

loup-vaillant wrote: post #32

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.

Take Monocypher or TweetNaCL, and rip off any primitive you don't need. This may be enough. Even when you take the whole thing, Monocypher only needs 30kb of x86-64 machine code when compiled with -Os. If you only keep authenticated encryption and x25519, which are enough for many uses, I think you should be able to halve that down to 15kb or less.

If speed doesn't matter, TweetNaCl is even smaller.

If those aren't enough still, you may want to dive in, learn a ton about crypto (starting with https://www.crypto101.io/), and investigate the sponge construction, whose versatility may allow you to shrink the code even more. Perhaps. I'm in over my head at this point.

Re: Cryptographic Right Answers

#82

Post by suf » Tue, Apr 03, 2018, 10:42 PM UTC

lvh wrote: post #68

suf wrote: 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…

Thanks, yeah embedded systems are always an exception that makes for strange design.

Re: Cryptographic Right Answers

#83

Post by deathanatos » Tue, Apr 03, 2018, 10:43 PM UTC

justincormack wrote: post #38

loup-vaillant wrote: post #23

Earlier quoted context omitted.

I may have to update my manual, which currently recommends getrandom() on Linux, and arc4random_buf() on BSD. https://monocypher.org/manual/#Random_number_generation On which systems is getentropy() available? My Ubuntu 16.04 doesn't seem to have it.

It is getrandom(2) on Linux, similar to getentropy(2) on OpenBSD. It should be in 16.04, it is kernel 3.17+ although it was not added to glibc until recenrtly so you might have to use the syscall directly.

getentropy(2) exists on Linux. I do not know when it was introduced, but my Arch system has it. (I feel as if your comment implies that it is the BSD equivalent to getrandom(2).)

Re: Cryptographic Right Answers

#84

Post by lvh » Tue, Apr 03, 2018, 10:43 PM UTC

marknadal wrote: post #78

lvh wrote: post #66

Earlier quoted context omitted.

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

I don't think you can do this safely without having a security person on board. And there's a chance they'll try to ship a real crypto library in the Electron app.

I'll give it a shot though, some things that come to mind:

* RFC6979 ECDSA or bust

* Have you considered off-curve attacks for that ECDH?

* How do you authenticate your symmetric ctexts?

Re: Cryptographic Right Answers

#85

Post by lvh » Tue, Apr 03, 2018, 10:45 PM UTC

Xeoncross wrote: post #74

lvh wrote: post #60

Earlier quoted context omitted.

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

I don't see which 512 bit MAC you're referring to. I'm referring to the chunked encryption scheme 'dchest mentioned.

Re: Cryptographic Right Answers

#86

Post by deathanatos » Tue, Apr 03, 2018, 10:45 PM UTC

lvh wrote: post #15

keithwinstein wrote: post #13

Would propose one amendment to "Random IDs": if you can rely on it being available, getentropy() is preferable to /dev/urandom. (1) It blocks if the system has just booted and the kernel has not yet collected enough entropy to initialize the entropy pool. (Good on VMs, embedded systems, etc., where there's a risk that the initial state might be identical.) It would be nice if Linux had a file-based /dev/uxrandom that…

Sure. FWIW, my favorite is APIs like Python's os.urandom which just always does the right thing already (including, IIRC, in very recent versions, getentropy()/getrandom()/arc4random_buf() or whatever where available). I feel like currently there are slightly fewer ways you could open up /dev/urandom and screw it up (you mention a few valid ones -- but now you're doing feature detection) and it's incidentally cross-p…

If you have a modern version of Python, you can do:

  import secrets
  secrets.token_bytes()  # returns a randomized token

You can pass in the number of bytes you want, but I would think it would be better to rely on the default (presently 256 bit). This module is intended for cryptographic purposes. There are also helper functions to get a hex string or a URL safe string back.

https://docs.python.org/3/library/secrets.html

Re: Cryptographic Right Answers

#87

Post by blattimwind » Tue, Apr 03, 2018, 10:46 PM UTC

vardump wrote: post #67

loup-vaillant wrote: post #32

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.

libhydrogen might be an option.

Re: Cryptographic Right Answers

#88

Post by schoen » Tue, Apr 03, 2018, 10:59 PM UTC

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…

I ask experts about this every few years, but I don't seem to write down what they tell me and I've encountered a bit of a range of opinion, but:

What's bad about cipher cascades?

(No, I don't current encourage people to use them and I tell people that there's some expert sentiment discouraging them; I want to remember the basis of that sentiment.)

Re: Cryptographic Right Answers

#89

Post by lvh » Tue, Apr 03, 2018, 11:01 PM UTC

suf wrote: post #82

lvh wrote: post #68

Earlier quoted context omitted.

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…

Thanks, yeah embedded systems are always an exception that makes for strange design.

Yeah. Unfortunately this cuts both ways: I've also heard "you don't understand, we are on an embedded platform" when they mean "we're on a raspi".

Re: Cryptographic Right Answers

#90

Post by loeg » Tue, Apr 03, 2018, 11:10 PM UTC

deathanatos wrote: post #83

justincormack wrote: post #38

Earlier quoted context omitted.

It is getrandom(2) on Linux, similar to getentropy(2) on OpenBSD. It should be in 16.04, it is kernel 3.17+ although it was not added to glibc until recenrtly so you might have to use the syscall directly.

getentropy(2) exists on Linux. I do not know when it was introduced, but my Arch system has it. (I feel as if your comment implies that it is the BSD equivalent to getrandom(2).)

OpenBSD introduced getentropy(2). Since it is a subset of getrandom(2) functionality, glibc added a compatibility wrapper that provides the same ABI.

(FreeBSD only recently added the getrandom(2) syscall and getentropy(3) libc wrapper functions in -CURRENT.)