3 ms·

I think what we really need is a constant-time coprocessor. An FPGA would be ideal, since you can reconfigure it to support new/improved algorithms over time. I

I think what we really need is a constant-time coprocessor. An FPGA would be ideal, since you can reconfigure it to support new/improved algorithms over time. It's much easier to defend against side-channels when you have control over the hardware. Are there any products or projects in this direction? Ideally, you'd have a drop-in software library replacement, which would redirect all relevant operations to the hardware.

tomxor 4y ago
> which would redirect all relevant operations to the hardware. That might be more than you think.
- Retr0id 4y ago
  Offloading all the asymmetric ops would be a good start, since they're generally the most affected by side-channels, and performed relatively infrequently (compared to the symmetric ops)
akamoonknight 4y ago
I don't know that your topic is their specific aim, but I remember Popcorn Linux coming up on HN before: http://www.popcornlinux.org/ http://www.popcornlinux.org/ To some extent their goal is to enable better improve the interoperability of heterogeneous hardware.
DSingularity 4y ago
extreme response.
wahern 4y ago
> Ideally, you'd have a drop-in software library replacement, which would redirect all relevant operations to the hardware. Many years ago OpenBSD had the /dev/crypto interface for exposing cryptographic accelerators to userland, including for hashes and ciphers (not just expensive asymmetric primitives).[1][2] And their fork of OpenSSL included built-in support for /dev/crypto, though I'm not sure whether and to what extent the application had to explicitly ask OpenSSL to use it. IIRC, it was removed from OpenBSD because of security headaches with exposing accelerators to user land, and because the future seemed to lie in ISA extensions rather than discrete devices. It was ported to other BSDs where it looks like it still lives on: https://www.freebsd.org/cgi/man.cgi?query=crypto&apropos=0&sektion=4&manpath=FreeBSD+13.1-RELEASE https://www.freebsd.org/cgi/man.cgi?query=crypto&apropos=0&s... [1] https://man.openbsd.org/OpenBSD-5.6/crypto.4 https://man.openbsd.org/OpenBSD-5.6/crypto.4 [2] https://en.wikipedia.org/wiki/OpenBSD_Cryptographic_Framework https://en.wikipedia.org/wiki/OpenBSD_Cryptographic_Framewor...

tomxor 4y ago

> which would redirect all relevant operations to the hardware. That might be more than you think.

Retr0id 4y ago
Offloading all the asymmetric ops would be a good start, since they're generally the most affected by side-channels, and performed relatively infrequently (compared to the symmetric ops)

akamoonknight 4y ago

I don't know that your topic is their specific aim, but I remember Popcorn Linux coming up on HN before: http://www.popcornlinux.org/ http://www.popcornlinux.org/ To some extent their goal is to enable better improve the interoperability of heterogeneous hardware.

DSingularity 4y ago

extreme response.

wahern 4y ago

> Ideally, you'd have a drop-in software library replacement, which would redirect all relevant operations to the hardware. Many years ago OpenBSD had the /dev/crypto interface for exposing cryptographic accelerators to userland, including for hashes and ciphers (not just expensive asymmetric primitives).[1][2] And their fork of OpenSSL included built-in support for /dev/crypto, though I'm not sure whether and to what extent the application had to explicitly ask OpenSSL to use it. IIRC, it was removed from OpenBSD because of security headaches with exposing accelerators to user land, and because the future seemed to lie in ISA extensions rather than discrete devices. It was ported to other BSDs where it looks like it still lives on: https://www.freebsd.org/cgi/man.cgi?query=crypto&apropos=0&sektion=4&manpath=FreeBSD+13.1-RELEASE https://www.freebsd.org/cgi/man.cgi?query=crypto&apropos=0&s... [1] https://man.openbsd.org/OpenBSD-5.6/crypto.4 https://man.openbsd.org/OpenBSD-5.6/crypto.4 [2] https://en.wikipedia.org/wiki/OpenBSD_Cryptographic_Framework https://en.wikipedia.org/wiki/OpenBSD_Cryptographic_Framewor...