[rust-dev] Rust crypto highlights

[Tony Arcieri]

I've been trying to keep an eye on what's been brewing in the Rust
crypto-world. There's a lot of parts that people have been working on that
I'd really love to see brought together in a coherent manner, perhaps in
the form of an (out-of-tree) common crypto library for Rust. Here are a few
highlights:

- common.rs <https://github.com/seb-m/common.rs>: a cool library with a
terrible name! This library implements SBufs
<https://github.com/seb-m/common.rs/blob/master/src/sbuf.rs>: secure
buffers with guard pages, suitable for storing keying material. I would
still love to see this extended to do RAII-style memory protection that
sets PROT_NONE on buffer pages when they're not in use

- rust-constanttime
<https://gist.github.com/lifthrasiir/56cdcf404edce0a8f256>: [ WARNING:
BROKEN DO NOT USE ] a library similar to Go's crypto/subtle
<http://golang.org/pkg/crypto/subtle/>: data types that try to ensure
constant-time operations, unfortunately LLVM is really smart and likes to
performance optimize by adding branches even when you really don't want it
to. If someone knew of a way to make it actually verifiably constant time,
that would be amazing.

- suruga <https://github.com/klutzy/suruga>: a Rust implementation of TLS
1.2. Wouldn't it be great if a Servo-powered browser didn't have to use
OpenSSL? ;) This seems like it could benefit from SBufs and
rust-constanttime, if they were fully baked. Right now it does no memory
protections around keying material or internal cipher state.

[Tony Arcieri]

Sidebar on SBuf: I'd be curious how it could be written completely in terms
of MemoryMap, or if MemoryMap needs to be extended to support mprotect() /
VirtualProtect().

Post by Tony Arcieri
I've been trying to keep an eye on what's been brewing in the Rust
crypto-world. There's a lot of parts that people have been working on that
I'd really love to see brought together in a coherent manner, perhaps in
the form of an (out-of-tree) common crypto library for Rust. Here are a few
- common.rs <https://github.com/seb-m/common.rs>: a cool library with a
terrible name! This library implements SBufs
<https://github.com/seb-m/common.rs/blob/master/src/sbuf.rs>: secure
buffers with guard pages, suitable for storing keying material. I would
still love to see this extended to do RAII-style memory protection that
sets PROT_NONE on buffer pages when they're not in use
- rust-constanttime
BROKEN DO NOT USE ] a library similar to Go's crypto/subtle
<http://golang.org/pkg/crypto/subtle/>: data types that try to ensure
constant-time operations, unfortunately LLVM is really smart and likes to
performance optimize by adding branches even when you really don't want it
to. If someone knew of a way to make it actually verifiably constant time,
that would be amazing.
- suruga <https://github.com/klutzy/suruga>: a Rust implementation of TLS
1.2. Wouldn't it be great if a Servo-powered browser didn't have to use
OpenSSL? ;) This seems like it could benefit from SBufs and
rust-constanttime, if they were fully baked. Right now it does no memory
protections around keying material or internal cipher state.
--
Tony Arcieri

[Daniel Micay]

Post by Tony Arcieri
Sidebar on SBuf: I'd be curious how it could be written completely in
terms of MemoryMap, or if MemoryMap needs to be extended to support
mprotect() / VirtualProtect().

MemoryMap doesn't support controlling memory protections.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140930/a49d57e1/attachment.sig>

[Tony Arcieri]

On Mon, Sep 29, 2014 at 10:50 PM, Daniel Micay <danielmicay at gmail.com>

Post by Daniel Micay
MemoryMap doesn't support controlling memory protections.

Will it ever, or is the recommended approach to brew your own
MemoryMap-alike like SBuf is presently doing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140929/5ce56c48/attachment.html>

[Florian Zeitz]

Post by Tony Arcieri
I've been trying to keep an eye on what's been brewing in the Rust
crypto-world. There's a lot of parts that people have been working on
that I'd really love to see brought together in a coherent manner,
perhaps in the form of an (out-of-tree) common crypto library for Rust.
- common.rs <https://github.com/seb-m/common.rs>: a cool library with a
terrible name! This library implements SBufs
<https://github.com/seb-m/common.rs/blob/master/src/sbuf.rs>: secure
buffers with guard pages, suitable for storing keying material. I would
still love to see this extended to do RAII-style memory protection that
sets PROT_NONE on buffer pages when they're not in use
- rust-constanttime
BROKEN DO NOT USE ] a library similar to Go's crypto/subtle
<http://golang.org/pkg/crypto/subtle/>: data types that try to ensure
constant-time operations, unfortunately LLVM is really smart and likes
to performance optimize by adding branches even when you really don't
want it to. If someone knew of a way to make it actually verifiably
constant time, that would be amazing.
- suruga <https://github.com/klutzy/suruga>: a Rust implementation of
TLS 1.2. Wouldn't it be great if a Servo-powered browser didn't have to
use OpenSSL? ;) This seems like it could benefit from SBufs and
rust-constanttime, if they were fully baked. Right now it does no memory
protections around keying material or internal cipher state.

Is there any particular reason you chose this three projects?
I was rather surprised rust-crypto
<https://github.com/DaGenix/rust-crypto> isn't on your list. Also
common.rs links to the two projects it was written for: crypto.rs
<https://github.com/seb-m/crypto.rs> and Curve41417.rs
<https://github.com/seb-m/curve41417.rs>, which seem rather interesting
to me.

Regards,
Florian Zeitz

[Tony Arcieri]

On Tue, Sep 30, 2014 at 7:05 AM, Florian Zeitz <florob at babelmonkeys.de>

Post by Florian Zeitz
Is there any particular reason you chose this three projects?

Because I consider it somewhat bad idea to implement cryptographic
primitives building on this sort of foundation.

Post by Florian Zeitz
I was rather surprised rust-crypto <https://github.com/DaGenix/rust-crypto>
isn't on your list.

rust-crypto is exactly the kind of library that needs these cryptographic
primitives. Since it doesn't have them, it's most likely providing
implementations that aren't sidechannel resistant, and it doesn't protect
data in memory. Perhaps I should test the former empirically empirically
with djb's cpucycles library.

This is, of course, why I bring up the need for these things now:
retrofitting them later will be difficult.

Post by Florian Zeitz
Also
common.rs links to the two projects it was written for: crypto.rs
<https://github.com/seb-m/crypto.rs> and Curve41417.rs
<https://github.com/seb-m/curve41417.rs>, which seem rather interesting
to me.

Yes, although they are, again lacking constant time primitives to build on.

[Brian Anderson]

Thanks for the updates, Tony.

Post by Tony Arcieri
I've been trying to keep an eye on what's been brewing in the Rust
crypto-world. There's a lot of parts that people have been working on
that I'd really love to see brought together in a coherent manner,
perhaps in the form of an (out-of-tree) common crypto library for
- common.rs <https://github.com/seb-m/common.rs>: a cool library with
a terrible name! This library implements SBufs
<https://github.com/seb-m/common.rs/blob/master/src/sbuf.rs>: secure
buffers with guard pages, suitable for storing keying material. I
would still love to see this extended to do RAII-style memory
protection that sets PROT_NONE on buffer pages when they're not in use
- rust-constanttime
BROKEN DO NOT USE ] a library similar to Go's crypto/subtle
<http://golang.org/pkg/crypto/subtle/>: data types that try to ensure
constant-time operations, unfortunately LLVM is really smart and likes
to performance optimize by adding branches even when you really don't
want it to. If someone knew of a way to make it actually verifiably
constant time, that would be amazing.

I've been told by LLVM folks that getting LLVM to do constant time code
generation is essentially hopeless, and it should just be written in
asm. One could start by compiling with LLVM, then hand-inspecting the
output.

Post by Tony Arcieri
- suruga <https://github.com/klutzy/suruga>: a Rust implementation of
TLS 1.2. Wouldn't it be great if a Servo-powered browser didn't have
to use OpenSSL? ;) This seems like it could benefit from SBufs and
rust-constanttime, if they were fully baked. Right now it does no
memory protections around keying material or internal cipher state.
--
Tony Arcieri
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140930/9d6766b1/attachment.html>

[Tony Arcieri]

On Tue, Sep 30, 2014 at 10:05 AM, Brian Anderson <banderson at mozilla.com>

Post by Brian Anderson
I've been told by LLVM folks that getting LLVM to do constant time code
generation is essentially hopeless, and it should just be written in asm.
One could start by compiling with LLVM, then hand-inspecting the output.

That's unfortunate. It would probably be good for any pure Rust
implementation of any cryptographic primitive to do a timing variability
study on the main CPU architectures they intend for their code to be run
on. Perhaps I'll work on a tool to do that ;)

If any you are curious why this is a problem, I'd suggest taking a look at
djb's original cache timing attacks paper, where he demonstrates
over-the-network AES key recovery using cache timing sidechannels in
OpenSSL:

http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

Things get worse when you're talking about two VMs that are cotenant on the
same hypervisor, or shared hosting systems in general.

--
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140930/0d144c3c/attachment.html>

[Erick Tryzelaar]

What a great coincidence that this came up. I'm in the process of
organizing a crypto-themed rust meetup. Would anyone like to give a talk
about something crypto related?

Post by Tony Arcieri
On Tue, Sep 30, 2014 at 10:05 AM, Brian Anderson <banderson at mozilla.com>

Post by Brian Anderson
I've been told by LLVM folks that getting LLVM to do constant time code
generation is essentially hopeless, and it should just be written in asm.
One could start by compiling with LLVM, then hand-inspecting the output.

That's unfortunate. It would probably be good for any pure Rust
implementation of any cryptographic primitive to do a timing variability
study on the main CPU architectures they intend for their code to be run
on. Perhaps I'll work on a tool to do that ;)
If any you are curious why this is a problem, I'd suggest taking a look at
djb's original cache timing attacks paper, where he demonstrates
over-the-network AES key recovery using cache timing sidechannels in
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
Things get worse when you're talking about two VMs that are cotenant on
the same hypervisor, or shared hosting systems in general.
--
Tony Arcieri
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140930/4ff03376/attachment.html>

[Tony Arcieri]

I already talked to you about giving a talk so seems good ;)

I also had various point me at rust-crypto's implementation and it is much
better than I realized. It's using the asm! macro to take advantage of a
lot of neat Intel features including AES-NI acceleration. That's great!

I also learned about the existence of the asm! macro in the process. It'd
be really interesting to see someone try to reimplement rust-constanttime
in ASM. That should solve any worries about LLVM optimizations, and provide
a good building block for implementing crypto in otherwise pure Rust,
specifically for things like RSA or ECC.

On Tue, Sep 30, 2014 at 8:19 PM, Erick Tryzelaar <erick.tryzelaar at gmail.com>

Post by Erick Tryzelaar
What a great coincidence that this came up. I'm in the process of
organizing a crypto-themed rust meetup. Would anyone like to give a talk
about something crypto related?

Post by Tony Arcieri
On Tue, Sep 30, 2014 at 10:05 AM, Brian Anderson <banderson at mozilla.com>

Post by Brian Anderson
I've been told by LLVM folks that getting LLVM to do constant time code
generation is essentially hopeless, and it should just be written in asm.
One could start by compiling with LLVM, then hand-inspecting the output.

That's unfortunate. It would probably be good for any pure Rust
implementation of any cryptographic primitive to do a timing variability
study on the main CPU architectures they intend for their code to be run
on. Perhaps I'll work on a tool to do that ;)
If any you are curious why this is a problem, I'd suggest taking a look
at djb's original cache timing attacks paper, where he demonstrates
over-the-network AES key recovery using cache timing sidechannels in
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
Things get worse when you're talking about two VMs that are cotenant on
the same hypervisor, or shared hosting systems in general.
--
Tony Arcieri
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[Jordan Earls]

Is there an Ed22519 implementation for Rust yet?

Also, I take it none of this is actually secure yet, since it's not been
audited and lacks time-constant code and what not

Post by Tony Arcieri
I already talked to you about giving a talk so seems good ;)
I also had various point me at rust-crypto's implementation and it is much
better than I realized. It's using the asm! macro to take advantage of a
lot of neat Intel features including AES-NI acceleration. That's great!
I also learned about the existence of the asm! macro in the process. It'd
be really interesting to see someone try to reimplement rust-constanttime
in ASM. That should solve any worries about LLVM optimizations, and provide
a good building block for implementing crypto in otherwise pure Rust,
specifically for things like RSA or ECC.
On Tue, Sep 30, 2014 at 8:19 PM, Erick Tryzelaar <

Post by Erick Tryzelaar
What a great coincidence that this came up. I'm in the process of
organizing a crypto-themed rust meetup. Would anyone like to give a talk
about something crypto related?

Post by Tony Arcieri
On Tue, Sep 30, 2014 at 10:05 AM, Brian Anderson <banderson at mozilla.com>

Post by Brian Anderson
I've been told by LLVM folks that getting LLVM to do constant time code
generation is essentially hopeless, and it should just be written in asm.
One could start by compiling with LLVM, then hand-inspecting the output.

That's unfortunate. It would probably be good for any pure Rust
implementation of any cryptographic primitive to do a timing variability
study on the main CPU architectures they intend for their code to be run
on. Perhaps I'll work on a tool to do that ;)
If any you are curious why this is a problem, I'd suggest taking a look
at djb's original cache timing attacks paper, where he demonstrates
over-the-network AES key recovery using cache timing sidechannels in
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
Things get worse when you're talking about two VMs that are cotenant on
the same hypervisor, or shared hosting systems in general.
--
Tony Arcieri
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

--
Tony Arcieri
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20141001/039f2939/attachment.html>

[Tony Arcieri]

On Wed, Oct 1, 2014 at 12:42 PM, Jordan Earls <earlz at lastyearswishes.com>

Post by Jordan Earls
Is there an Ed22519 implementation for Rust yet?

There's an Ed25519 binding in sodiumoxide:

https://github.com/dnaq/sodiumoxide/blob/master/src/sodiumoxide/crypto/ed25519.rs

Post by Jordan Earls
Also, I take it none of this is actually secure yet, since it's not been
audited and lacks time-constant code and what not

sodiumoxide is fine, since it's a binding to the libsodium C/ASM code.
Likewise rust-openssl is "fine"

Pure Rust implementations of cryptographic primitives are definitely in
need of expert scrutiny before they should be used for anything serious.

[Kevin Cantu]

Thanks for the updates, Tony!


Kevin

Post by Tony Arcieri
On Wed, Oct 1, 2014 at 12:42 PM, Jordan Earls <earlz at lastyearswishes.com>

Post by Jordan Earls
Is there an Ed22519 implementation for Rust yet?

https://github.com/dnaq/sodiumoxide/blob/master/src/sodiumoxide/crypto/ed25519.rs

Post by Jordan Earls
Also, I take it none of this is actually secure yet, since it's not been
audited and lacks time-constant code and what not

sodiumoxide is fine, since it's a binding to the libsodium C/ASM code.
Likewise rust-openssl is "fine"
Pure Rust implementations of cryptographic primitives are definitely in need
of expert scrutiny before they should be used for anything serious.
--
Tony Arcieri
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[Palmer Cox]

Regarding rust-crypto and timing attacks: in general the library tries to
provide constant time implementations where possible. There are two
implementations of AES - the AES-NI implementation and a bit-sliced pure
software implementation. There isn't currently a table lookup based
implementation included. I believe that the AES-NI implementation is likely
constant time since all that actual crypto work is being done by the AES-NI
instructions. The bit sliced software implementation is hopefully constant
time - there aren't any conditionals or table lookups on keys, plaintext,
or ciphertext in the code. However, no one has verified that LLVM
optimizations don't add some in.

Memory comparisons are done using assembly code to prevent LLVM doing
optimizations and there are implementations for x86 and ARM. It might be
possible to adopt these routines to build something like rust-constanttime.

Rust-crypto isn't currently doing anything special to protect key material
or plaintext data in memory other than using as little unsafe code as
possible.

-Palmer Cox

Post by Kevin Cantu
Thanks for the updates, Tony!
Kevin

Post by Tony Arcieri
On Wed, Oct 1, 2014 at 12:42 PM, Jordan Earls <earlz at lastyearswishes.com

Post by Jordan Earls
Is there an Ed22519 implementation for Rust yet?

https://github.com/dnaq/sodiumoxide/blob/master/src/sodiumoxide/crypto/ed25519.rs

Post by Tony Arcieri

Post by Jordan Earls
Also, I take it none of this is actually secure yet, since it's not been
audited and lacks time-constant code and what not

sodiumoxide is fine, since it's a binding to the libsodium C/ASM code.
Likewise rust-openssl is "fine"
Pure Rust implementations of cryptographic primitives are definitely in

need

Post by Tony Arcieri
of expert scrutiny before they should be used for anything serious.
--
Tony Arcieri
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20141008/88f19213/attachment.html>

[Tony Arcieri]

rust-crypto and timing attacks [...] AES-NI [...] no one has verified that
LLVM optimizations [...] assembly code [...] build something like
rust-constanttime

Seems like an OK trajectory, but it would be good to verify if data
dependent timings give attackers a useful statistical signal in Rust crypto
applications, even ones where the core is assembly. I am working on a
library for measuring this empirically.