Feature Request: encryption primitives for devices without AES cpu instructions

[DavyLandman]

Hi @rfjakob,

Thank you for this great application! The reverse mode is what really sets it apart from other options.

I checked the issues, and it doesn't seem to be discussed yet, but what do you think about adding support for a different collection of encryption primitives that are better suited for more low-end devices?

I'm running gocryptfs on a few ARMv6/7 based NAS machines, they are nice: low energy, and quite fast. But they lack native AES instructions, my fastest ARM device (Odroid XU4) maxes out at 40MB/s, while for example the raspberry-pi's and friends are quite a bit slower (rpi1 is at 15MB/s).

Maybe Google Adiantum (also added to linux kernel 5.0 for cryptfs) is a nice fit, Adiantum is based on XChaCha12 and Poly1305 and is roughly 5 quicker than AES-XTS for devices without AES instructions.

For the reverse mode maybe something based on ChaCha20Poly1305?

Just for comparison, on my Odroid XU4, ChaCha20Poly1305 runs at 320MB/s, on my RPi1 it gets close to 40MB/s.

So I'm just wondering what your view is on this topic.

Cheers,
Davy

[rfjakob]

Hi, would you mind running gocryptfs -speed on your ARM machines and posting the result? (and cat /proc/cpuinfo | grep -E "model name|flags" | head -2).

I'd like to add it to our CPU zoo at ( https://github.com/rfjakob/gocryptfs/wiki/CPU-Benchmarks )

[DavyLandman]

I've taken all different kind of ARM devices I have:

Odroid XU4 (Exynos 5422 - ARM Cortex-A15 - 2 GHz)

model name      : ARMv7 Processor rev 3 (v7l)
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae

$ gocryptfs -speed
AES-GCM-256-OpenSSL       34.26 MB/s    (selected in auto mode)
AES-GCM-256-Go            17.24 MB/s
AES-SIV-512-Go            17.58 MB/s

$ openssl speed -evp chacha20-poly1305 && openssl speed -evp aes-256-gcm
...
The 'numbers' are in 1000s of bytes per second processed.
type                 16 bytes    64 bytes     256 bytes    1024 bytes   8192 bytes   16384 bytes
chacha20-poly1305    64066.72k   130153.44k   275532.80k   306572.84k   320018.56k   307903.74k
aes-256-gcm          40323.87k   49980.74k    64734.47k    70323.03k    71862.66k    71786.19k

Raspberry Pi 3 B rev 1.2 (BCM2835 - ARM Cortex-A53 - 1.2Ghz)

model name      : ARMv7 Processor rev 4 (v7l)
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

$ gocryptfs -speed
AES-GCM-256-OpenSSL       17.13 MB/s    (selected in auto mode)
AES-GCM-256-Go             5.27 MB/s
AES-SIV-512-Go             4.31 MB/s

$ openssl speed -evp chacha20-poly1305 && openssl speed -evp aes-256-gcm
...
The 'numbers' are in 1000s of bytes per second processed.
type                 16 bytes     64 bytes     256 bytes    1024 bytes   8192 bytes   16384 bytes
chacha20-poly1305    30020.39k    63560.13k    77169.32k    82019.33k    83536.55k    83645.78k
aes-256-gcm          16137.38k    19500.97k    20668.33k    20986.20k    21127.17k    21135.36k

Raspberry Pi B rev 2 (BCM2835 - ARM 11 - 700Mhz)

model name      : ARMv6-compatible processor rev 7 (v6l)
Features        : half thumb fastmult vfp edsp java tls

$ gocryptfs -speed
AES-GCM-256-OpenSSL        4.80 MB/s    (selected in auto mode)
AES-GCM-256-Go             1.85 MB/s
AES-SIV-512-Go             1.50 MB/s

$ openssl speed -evp chacha20-poly1305 && openssl speed -evp aes-256-gcm
...
The 'numbers' are in 1000s of bytes per second processed.
type                  16 bytes    64 bytes     256 bytes    1024 bytes   8192 bytes   16384 bytes
chacha20-poly1305     8090.97k    18202.65k    23222.03k    24960.34k    25666.44k    24958.29k
aes-256-gcm           4525.91k    6268.65k     6972.36k     7141.38k     7230.33k     7150.88k

[rfjakob]

Awesome, thanks! Added to https://github.com/rfjakob/gocryptfs/wiki/CPU-Benchmarks .

[rfjakob]

I have added an XChaCha20-Poly1305 benchmark to gocryptfs -speed in the xchacha20 branch. On my PC, the results look very promising, with xchacha20 being almost as fast as hardware-accelerated AES-GCM:

$ gocryptfs -speed
AES-GCM-256-OpenSSL 	 585.92 MB/s	
AES-GCM-256-Go      	 899.28 MB/s	(selected in auto mode)
AES-SIV-512-Go      	 164.05 MB/s	
XChaCha20-Poly1305-Go	 773.27 MB/s	

HOWEVER, looking at https://github.com/golang/crypto/tree/master/chacha20poly1305 , there only seems to an optimized assembly version for amd64 (xxx_amd64.s).

Could you run gocryptfs -speed from the xchacha20 branch on one of your ARM devices, so see how the fast Go implementation is there?

EDIT: But there is a chacha_arm64.s here: https://github.com/golang/crypto/tree/master/chacha20

[rfjakob]

I have compiled that branch for Armv7, binary: gocryptfs.xchacha20.armv7.tar.gz

[DavyLandman]

Thanks for the binary:

on the Odroid XU4:

$ ./gocryptfs.xchacha20.armv7 --speed
AES-GCM-256-OpenSSL         N/A
AES-GCM-256-Go            17.04 MB/s    (selected in auto mode)
AES-SIV-512-Go            14.79 MB/s
XChaCha20-Poly1305-Go     23.37 MB/s
$ gocryptfs --speed
AES-GCM-256-OpenSSL       41.12 MB/s    (selected in auto mode)
AES-GCM-256-Go            16.92 MB/s
AES-SIV-512-Go            19.10 MB/s

The other ARM devices I have to try later.

Pitty golang has not added asm chacha versions yet, maybe the same openssl bridge for speed?

[rfjakob]

I had the same idea, unfortunately, openssl does not have xchacha20 yet: openssl/openssl#5523

They do have chacha20, but this cannot be used with random nonces (too high risk of collisions)

[DavyLandman]

that's a shame, could you add an option to also bench chacha20 case?

Just to get a sense of the impact of non-asm version, it might be that chacha20 is faster than xchacha20?

[DavyLandman]

I'm reading a bit, and the size & message restrictions on chacha20 are not that bad right?

https://pycryptodome.readthedocs.io/en/latest/src/cipher/chacha20.html
https://libsodium.gitbook.io/doc/advanced/stream_ciphers/chacha20

[rfjakob]

The table on https://pycryptodome.readthedocs.io/en/latest/src/cipher/chacha20.html is very nice!

The problem with ChaCha20: Max 200 000 messages. In gocryptfs, one "message" is a 4kiB data block, so that's a limit of 800 GiB data written over the lifetime of the filesystem!

[DavyLandman]

The normal one in go (and I think also openssl) is the second row in that table.

[lechner]

Hi, I previously ported Gocryptfs to use wolfSSL. Does the code below allow the use of a random nonce with ChaCha20?

https://github.com/wolfSSL/wolfssl/blob/master/wolfcrypt/src/chacha.c#L111

[rfjakob]

@DavyLandman I see, 96 bit nonces, that's less bad. gocryptfs used 96 bit nonces in earlier versions. I moved to 128 bits because 96 bit it too little for very large filesystems, I have the calculations saved in #17 (comment) .

And also, https://pkg.go.dev/golang.org/x/crypto/chacha20poly1305 says,

XChaCha20-Poly1305 is a ChaCha20-Poly1305 variant that takes a longer nonce, suitable to be generated randomly without risk of collisions. It should be preferred when nonce uniqueness cannot be trivially ensured, or whenever nonces are randomly generated.

so I'd rather not go with ChaCha20.

@lechner Yes it does, but only 96 bits according to the function comment

this version uses the typical AEAD 96 bit nonce