Re: [Forwarded] RealID: How to become an unperson.

2005-07-12 Thread Peter Hendrickson
Perry Metzger wrote:
 So, the next time one of your friends in Germany asks why the crazy
 Americans think ID cards and such are a bad thing, remember my
 father, and remember all the people like him who fled to the US over
 the last couple hundred years and who left children that still
 remember such things, whether from China or North Korea or Germany
 or Spain or Russia or Yugoslavia or Chile or lots of other places.

And one of those places is the US itself.  African-Americans have no
trouble envisioning scenarios in which mandatory IDs and universal
surveillance could be a problem.  Japanese-Americans don't have to
think very hard to remember that banking regulation can also be used
to freeze bank accounts, or that postal and census data can be used
by the Army to put a particular ethnic group in concentration camps.
Followers of the Church of Jesus Christ of Latter-day Saints do not
believe that vicious religious persecution in the US is an


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: M-209 broken in WWII

2004-10-07 Thread Peter Hendrickson
Hadmut Danisch quoted As a german codebreaker in World War II:
 Even experts didn't know until some years ago that german
 deciphering specialists broke ciphers of the allied in the second
 world war.

German success against the M-209 is discussed in David Kahn's The
Codebreakers.  It cites a 1962 letter as a source, so presumably this
information was in the 1967 edition.  In other words, German
cryptanalytic success has been public for a long time.

Kahn's book has quite a bit of good information on Axis cryptanalytic
efforts.  Germany was particularly successful, and was using
automation to assist their work.

One little gem is that Italy managed to pull off an active attack
against the Yugoslav Army.  They had been reading Yugoslav traffic for
awhile, got into a difficult situation, and convinced two divisions
they had been ordered to retreat using fake messages.  By the time
this was discovered and resolved the game was over.


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Beware of /dev/random on Mac OS X

2003-08-29 Thread Peter Hendrickson
It's a /dev/urandom which has been labeled /dev/random.  It claims
to be a Yarrow implementation so is presumably only 160 bits strong.

 /dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom
 will produce lower quality output if the entropy pool drains, while
 /dev/random will prefer to block and wait for additional entropy to
 be collected.  With Yarrow, this choice and distinction is not
 necessary, and the two devices behave identically. You may use

As I'm sure everybody here knows, /dev/random on every other OS blocks
until it has enough entropy available because that is what /dev/random
is.  The design goal is that it is as strong as the number of bits
read from it.

Here are the NetBSD and Linux man pages for comparison:

From the Apple man page, it appears they are aware of the problem but
consider it to be unimportant:
 Paranoid programmers can counter-act this risk somewhat by collecting
 entropy of their choice (e.g. from keystroke or mouse timings) and
 seeding it into random directly before obtaining important random

This workaround doesn't cut it for three reasons.

First, the entropy pool in Yarrow is only 160 bits.  From Section 6
Open Questions and Plans for the Future of the Yarrow paper
referenced above:
 Yarrow-160, our current construction, is limited to at most 160 bits
 of security by the size of its entropy accumulation pools.

If the program needs more than 160 bits, it can seed it with more than
that amount of entropy.  (Strictly, it could seed it with 160 bits,
read it, seed it, read it, but this isn't mentioned on the man

Second, the seeding process needs to guarantee that no other process
drains the entropy pool before it can read it.  This is not possible.

Three, the great idea behind /dev/random is that the program doesn't
have to manage entropy itself.  This is a good thing because the
kernel has access to entropic bits which the process doesn't.  Also,
each environment varies so good sources of entropy on one machine may
not be so good on another.  /dev/random permits the implementation of
good portable crypto - except to OS X.

Apple apparently only accepts bug reports from members of the Apple
Developers Connection.  If any such members are on this list, it
might be a good idea to submit a report:

Apple's inability to provide a real /dev/random is inexplicable given
that free implementations have been available for years.  Even if
Apple feels uncomfortable with GPL'd code, there's BSD licensed code
as well.


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]