A Puzzle for Today

> 1. Random is balanced only over the infinite time.

The puzzle didn't specify any maximum time.  My solution balances
already very well over runs as short as a few bytes.

> 2. There is a possibility of matching the data and the key stream,
> although unlikely.

As specifically said, the key must be randomly selected.  The
likelyhood of a match can be minimized arbitrarily by choosing a
bigger cipher blocksize.  It's sufficient to push it below the error
rate of the other components of your system.

For example, with AES256 you get a collision resistance of 2^128.  Use
it to transfer data on a serial 1gbit/s link and you find that your
link must have a MTBF of >2^56 million hours.  Only then the DC
balancer is likely to fail first.  If you build the link from
realworld parts, then the link will fail for other reasons long
before.

To put this into context:  Professional ethernet equipment comes with
MTBF between 300K to 2M hours.  And there's quite a difference between
2^1 and 2^56..

> Not a solution.

Please explain why.

Regards,
Marc

On Apr 22, 12:40�pm, jetm...@hotmail.com wrote:
> > 1. Random is balanced only over the infinite time.
>
> The puzzle didn't specify any maximum time. �My solution balances
> already very well over runs as short as a few bytes.
>
> > 2. There is a possibility of matching the data and the key stream,
> > although unlikely.
>
>snip<
> To put this into context: &#4294967295;Professional ethernet equipment comes with
> MTBF between 300K to 2M hours. &#4294967295;And there's quite a difference between
> 2^1 and 2^56..
>
Just because an event has a 1:N proability of failing does not mean
that one has to wait for N events for it to fail. It does not even
mean that a failure is guaranteed after N events. The failure could
occur on the 1st event or the 1st few events.

In article
<a8634061-40de-408f-966c-f8273a7e0365@q16g2000yqg.googlegroups.com>,
<jetmarc@hotmail.com> wrote:

> > 1. Random is balanced only over the infinite time.
> 
> The puzzle didn't specify any maximum time.  My solution balances
> already very well over runs as short as a few bytes.
> 
> > 2. There is a possibility of matching the data and the key stream,
> > although unlikely.
> 
> As specifically said, the key must be randomly selected.  The
> likelyhood of a match can be minimized arbitrarily by choosing a
> bigger cipher blocksize.  It's sufficient to push it below the error
> rate of the other components of your system.
> 
> For example, with AES256 you get a collision resistance of 2^128.  Use
> it to transfer data on a serial 1gbit/s link and you find that your
> link must have a MTBF of >2^56 million hours.  Only then the DC
> balancer is likely to fail first.  If you build the link from
> realworld parts, then the link will fail for other reasons long
> before.
> 
> To put this into context:  Professional ethernet equipment comes with
> MTBF between 300K to 2M hours.  And there's quite a difference between
> 2^1 and 2^56..
> 
> > Not a solution.
> 
> Please explain why.

If a string of 20 of the same bit is enough to cause errors, then your
perfectly random crypto on your 1 Gbit/s serial link will fault a
thousand times a second.

The puzzle didn't specify a maximum time, but a 1 ms MTBF is rarely
acceptable in the real world.

-- 
David M. Palmer  dmpalmer@email.com (formerly @clark.net, @ematic.com)