<p dir="ltr">Den 28 nov 2016 23:05 skrev "Ryan Carboni" <<a href="mailto:ryacko@gmail.com">ryacko@gmail.com</a>>:<br>
><br>
> 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.</p>
<p dir="ltr">Actual uses;</p>
<p dir="ltr">* Multi-player gaming - sub-millisecond response time desired in competition settings <br>
* 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 <br>
* Autonomous vehicle coordination protocols - you can imagine why... </p>
<p dir="ltr">There's probably much, much more. </p>
<p dir="ltr">> 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.</p>
<p dir="ltr">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. </p>
<p dir="ltr">I and a few others have already considered the use of stream cipher keyed block ciphers. </p>
<p dir="ltr">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). </p>
<p dir="ltr">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). </p>
<p dir="ltr">> Given that Chrome isn't totally sandboxed, secure enclaves certainly won't protect against all attacks.<br>
><br>
> Ideally an operating system would have the security features of OpenBSD, grsec, and the architecture would aid in securing it.</p>
<p dir="ltr">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?</p>