[Cryptography] High volume thermal entropy from an iPhone

[Ray Dillinger]

On 12/15/2017 12:54 PM, Jerry Leichter wrote:

> We often remark here that you should rely on proven code from experts,
> not do your own crypto code.  That's true with respect to some kinds of
> attack scenarios, not so simple with respect to others.  If you're a
> small target, making sure that attacks against you are significantly
> distinct from attacks against the big targets is probably not a bad idea.

In some accounts, I suppose that I may be considered an expert....
but I don't really consider myself to be one.

That said there are bits and pieces of code I can write and be quite
confident in.  Unfortunately, most of them aren't the kind of thing
you'd want in a standard.

I can write deterministic pseudo-random number generators that are
reasonably efficient and whose resistance to cryptanalysis I'm as
confident of as I am in the more widely published generators.  They are,
however, "reasonably" efficient rather than "very" efficient - the math
is cool, the coding is fun, and I get to make generators that have
particular, peculiar properties that for whatever reason I happen to
want in a particular application (Reversibility, variable state size,
parallel keying, other esoterica).  But they're not going to win any
design competitions or get adopted in any standards, and I well know it,
and I don't expect anyone who's not me to trust them.

Of course a pseudo-random number generator can be used as a mask
generator for a stream cipher.  But friends don't let friends use stream
ciphers.  Seriously, just don't.


A mildly peculiar cipher I created when I was thinking about everything
that's wrong with stream ciphers used a reduced Feistel cipher - just
four rounds, which is the minimum for the security proof - with a new
key for every block, drawn from the next bits of the stream-cipher mask.
 This is a construction that might actually work with an efficient
stream generator and sufficient key agility; if you can generate a
128-bit key and use it to encrypt a 512-bit block with a reduced (FAST!)
block cipher, then you get what might amount to a two-to-one discount on
encrypting the 512 bit block because speed from round reduction, and
have to pay some of it back (hopefully less than you gained) for
generating a new key and rekeying for the next block. I'm still toying
with this.  It's about the only idea I've had that might actually be a
good one worth using.


I could use one of my deterministic PRNGs for a very good cryptographic
hash. A couple of the PRNG designs have arbitrary-length keys/states; I
could simply take the document to be hashed - all of it - as the state,
produce and throw away several times the document's length in bits for
the cascading side effects in the state, and then produce the hash. This
approach absolutely eiminates length extension attacks where a prefix or
subsequence collision can be leveraged into longer or other collisions.
But it also absolutely eliminates important properties that a good
number of people want in a hashing algorithm, such as a small constant
memory footprint and a streaming mode that works on arbitrary-length
streams as they arrive, without even knowing how much data is in them at
the outset. And it's slower than most hashes and there's no possible way
to implement it in hardware, which leaves it completely out of the
running for most design standards.

I've implemented Feistel ciphers whose security I'm confident of, but
they're brutish.  They're mostly an exercise in "find the best efficient
round function I know how to find, then account for my pessimism about
people figuring out more math about round functions than I know, by
iterating them for so many rounds that the cipher becomes ludicrously
inefficient."  I know a lot about Feistel round functions but there are
a lot of people who know so much more that I can't be confident that
none of them could break it.

I've coded software simulations of WWII and cold-war rotor cipher
machines - and a few hypothetical machines that nobody ever built - just
for fun.

And I've created some real peculiarities like a "timelock" cipher that
allows a document (or stream) to be encrypted, "reasonably" efficiently
(about an RSA block's worth of calculation, which is many times slower
than a block cipher), in a way that will take some arbitrary,
predetermined amount of time per block to decrypt - and you can give
different people keys with different work factors.  It's based on
Rivest's Timelock, so credit where credit's due.

Another peculiarity, this one for an underhanded crypto contest, was a
"polymorphic" cipher in which, with some work, one could create
gimmicked keys, otherwise quite secure and normally usable although
ridiculously long for keys, that would encrypt twenty to thirty
preselected messages into preselected ciphertexts (It's an exponential
curve; 20 preselects is "instant" and happens when you take your finger
off the return key.  A key for 30 preselects took an all-night run on an
8-core machine to find). The minimum key length of a gimmicked key was a
multiple of the length of the longest message you wanted to work into
the gimmick. As a cipher, it was brutally inefficient - took 1800% or
more of the encryption/decryption time of a standard cipher as I recall.

But you know what I have absolutely no confidence in my ability to do,
however brutally or inefficiently?  What I have never even had the
temerity to experiment with?

There is absolutely no way I would ever trust code I write myself to do
key management.  Key management is hard.


				Bear


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171216/83045a9b/attachment.sig>