[Cryptography] What's the point of low-latency cryptography?

[Natanael]

Den 28 nov 2016 23:05 skrev "Ryan Carboni" <ryacko at gmail.com>:
>
> What is the actual latency that would cause pipeline stalls? I would
think that most computations on a computer require at least a hundred
cycles before the result is presented to the user. RAM to begin with
requires ten nanoseconds to retrieve data. Nearly all single-cycle
implementations are probably smaller than the gate area required for a DDR4
Bus.

Actual uses;

* Multi-player gaming - sub-millisecond response time desired in
competition settings
* High-frequency trading - these companies are literally paying extra to
have their hardware one room closer to the stock broker's server to reduce
latency
* Autonomous vehicle coordination protocols - you can imagine why...

There's probably much, much more.

> Although a more holistic approach would use a seekable stream cipher to
generate independent subkeys for a block cipher the size of each
addressable word (which appears to be the byte). This would be vulnerable
to codebook attacks if one can somehow read the encrypted output and submit
256 plaintexts if one knows the address of the data one wishes to
manipulate/read.

Given a proper implementation with software and hardware protections, you
can't get race-conditions or similar conflicts in assignment of key
material. Thus no such attacks.

I and a few others have already considered the use of stream cipher keyed
block ciphers.

Given the result on XEX from the paper "Revisiting minimalism in
cryptography", you just need one XOR key of N bits per block of N bits,
both before and after the permutation (keeping latency low). And the
permutation in XEX can even be unkeyed and public (essentially static), and
thus much faster and smaller in hardware than most classical block ciphers
(no key schedule!). And if the permutation is customizable / tweakable, you
could even choose your own block size (excellent for FDE, since you can
match arbitrary disk block sizes).

Combined with a fast seekable stream cipher (which really only need to
achieve unpredictability, not much else when combined with XEX) like you
said, you can massively parallelize the encryption and decryption, perhaps
even saturating the bandwidth of high-end supercomputer GPUs (and ASIC
implementations will essentially always be as fast as your I/O).

> Given that Chrome isn't totally sandboxed, secure enclaves certainly
won't protect against all attacks.
>
> Ideally an operating system would have the security features of OpenBSD,
grsec, and the architecture would aid in securing it.

How would a capabilities based OS taking full advantage of TPM / TrustZone
functionality look like, if it was designed in the open and made FOR  the
public?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161128/c28b765b/attachment.html>