[Cryptography] Nasruddin Cryptographic Function (99% finalized)

[Ryan Carboni]

To Ray:


> Rijndael has a proof of security against linear and differential
> cryptanalysis.
>
>
This uses the same S-box. Thus the security proof has been forked. This
essentially replaces the mix columns with a better mixing function, as the
AES mix columns appears to have anti-cryptographic properties. Although
Rijndael seems vulnerable to Bicliques.

One thing that SIMD ciphers are particularly prone to is
> Tempest attacks.  You get a whole lot of processors doing
> the same thing at the same time, and they act like a little
> phased array of tiny radio transmitting antennas.
>
>
Except that each input is different? It is an interesting challenge to
distinctly figure out the internal state of each ALU unit based on
emissions, although when many ALU units are simultaneously active, that may
make things difficult.

I'm not capable of addressing your other points.

-------------------------------------------------

To *Alexandre:*

This is both heavier and slower than regular AES
>
>
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 costs at least one hundred
thousand cycles for the key schedule. The key schedule for ciphers in
Veracrypt requires around 10,000,000 cycles?

That's the thing, for big computers, key set-up time is insignificant
compared to asymmetric cryptography, or for key stretching.

For long messages, Nasruddin aims to be fast using modern instruction sets.
AESENCLAST has a latency of 6 cycles, but a throughput of 2 cycles. Thus
the subbytes step will cost (although the requirement of having a few
registers dedicated to a key of zero could cause a cache miss) eight cycles
per round.

Packed addition may take a few cycles per round.

This might be... two or three cycles per byte?

In any case, if computers gain a Speck New Instructions set, and if it
includes the ability to pipeline multiple Speck encryptions per cycle, than
this will be less than a cycle per byte. But such a thing is purely
hypothetical. But it seems likely that Speck would be standardized over
Simon, considering that Simon is nearly broken and it hasn't even been
adopted! It's simple key schedule certainly reduces it's security margin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150718/70612954/attachment.html>