Baud rate?

[Liam D. Gray]

On Fri, Jul 6, 2012 at 4:06 AM, Daniel Silverstone
<dsilvers at digital-scurf.org> wrote:
> On Fri, Jul 06, 2012 at 03:29:39AM -0700, Liam D. Gray wrote:
>> The Entropy Key emulates a USB CDC serial port.  What is the baud
>> rate, or which baud rates are possible?
>
> The USB actually always runs at the same rate, and the key always generates
> packets at the same rate.

Let me put it this way: Full rate for USB 1.1, apparently used here,
is 12 Megabits per second.  But a device has the option to fill any
portion of the channel capacity, from zero to 100%.  So at what rate
does Entropy Key send entropic bits into the 12Mbit/sec channel?  This
determines how quickly my receive buffer will fill up after each time
I tell Entropy Key to start sending.

> As such, you'll just have to discard extraneous entropy packets if you don't
> want to process them.
> You could queue up a bunch of entropy and then send "^C" to reset the key and
> halt the entropy flow while you use up what you have, before re-keying it to
> resume.  [Assuming you're writing your own host driver and not using ekeyd]

That's a worthy idea, but see below.

>Also if you're not worried about being sniffed or man-in-the-middled for
>whatever reason (physical security of device is enough, etc) then you can skip
>the validation/decryption phases of the protocol to save CPU bandwidth.

A clever suggestion.  Actually I may want to be my own
man-in-the-middle for this application: I want my microcontroller to
control something with the entropic bits from Entropy Key before*
passing them on to a host computer that will log them.  (*Not after,
and there's a reason for that.) And I want to avoid using the
non-payload part of the stream, those parts added by the protocol for
its own use.  I don't want to use any of the protocol's
configuration/control bits, because they are not independently derived
from (though I'll happily permit any pure permutation of) quantum
random processes.  (This is for faithfulness in replicating an
experiment whose whose results and mechanism we are very far from
understanding.)

And it looks as though, in Skein, the protocol mixes its control bits
into the payload. From
http://www.skein-hash.info/sites/default/files/skein1.3.pdf :
"Skein’s novel idea is to build a hash function out of a tweakable
block cipher. The use of a tweakable block cipher allows Skein to hash
configuration data along with the input text in every block [...]"

So it seems as though I must implement Skein on my microcontroller,
and probably use ^C resets in lieu of flow control as well, once I
know the actual (vs. potential) data rate I'm dealing with.

I apologize for not having read the ekeyd source before asking these
questions. I'm sure that some of my questions are answered in the
source.  Or here:
http://lists.randombit.net/pipermail/cryptography/2011-January/000566.html

Best,
Liam