John Kelsey wrote:
Quoting me:
> >Proposal:
> >
> >Could we do a large part of this with a fairly simple chip,
> >all digital, without diodes etc.? A system bus has typically
> >at least 32 data and 32 address lines plus a bunch of
> >control signals. Perhaps 80 bits that can be sampled at
> >perhaps 100 MHz. 10 Mbytes/sec. Crunch that down to 10K
> >highly random bytes?
> >
> >Some bits have dreadful entropy of course: ...
[snip]
>
> >I have a crunching mechanism to propose. Nyberg showed that
> >perfect s-boxes (all columns and all linear combinations of
> >columns are bent boolean functions) can be built whenever
> >there are twice as many input bits as output bits. Build a
> >substitution-permutation network with perfect s-boxes.
>
> Wait a second, here! Nyberg's perfect S-boxes can give you
> provable security against standard differential and linear
> attacks, but I don't see why this is relevant, here. We're
> trying to crunch this huge stream of data down into a
> fixed-length buffer, presumably with some kind of arguments
> for entropy-preservation. We don't care much here about
> an attacker controling our inputs--he would have to be in
> control of our system bus!
But an attacker can know some inputs, and in some cases control
them. e.g. I can influence some things by sending you packets
and if I have an account on your system, I can run programs
with predictable and perhaps controllable effects on the system
bus. e.g. allocate a big chunk of memory & fill it with zeroes.
Collecting more-or-less everything on the bus clearly won't work
without some hardware compression mechanism. That might just be a
buffer you XOR it all into.
> Anyway, I think your entropy-gathering proposal ought to be
> kept separate from the crunching mechanism.
Yes.
> I claim that we
> can design a reasonable crunching mechanism using existing
> components, probably block ciphers or hash functions. Is
> there a reason why (say) treating the buffer as circular,
> and continually processing inputs by XORing them into the
> buffer, and then CBC-mode encrypting the resulting blocks
> with a fixed key, wouldn't suffice?
Methinks you can have two crunching mechanisms. One processes
the input en route to the buffer. The main goal there is to
ensure the buffer ends up sufficiently random and unknowable
to an attacker. The other produces output from the buffer.
My proposal crunches really large amounts of input down to
something high-entropy and of manageable size for the software.
