Cryptography-Digest Digest #534, Volume #13 Tue, 23 Jan 01 19:13:00 EST
Contents:
Re: using AES finalists in series? (Bryan Olson)
Re: using AES finalists in series? (wtshaw)
Encrypted file? ("Ernst")
TSEPRNG, a secure RNG ? (Bryan Mongeau)
Re: Why Microsoft's Product Activation Stinks (Noah Simoneaux)
Re: Why Microsoft's Product Activation Stinks (wtshaw)
Re: Creating a self extracting encrypted exe? (Bryan Mongeau)
Re: Some Enigma Questions (David Hamer)
Snake Oil (William Hugh Murray)
Re: TSEPRNG, a secure RNG ? (Splaat23)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Some Enigma Questions (David Hamer)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Tue, 23 Jan 2001 22:38:55 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
> Douglas A. Gwyn wrote:
> >[...]
> >Chaining of AES candidates seems to be proposed as a
> >way to feel better about the uncertainty of their actual strength
> >against competent cryptanalysis, but if so that is misguided,
> >since *that* concern has not yet been addressed for chaining.
>
> I think that issue *has* been plainly addressed, and has been implicit
> in most such discussions.
>
> For one thing, a "chain" of ciphers is certainly stronger against
> known-plaintext attacks which could function against an individual
> cipher.
Though probably correct, no proof of that is known. What we
can prove is that against known plaintext or ciphertext only,
the chain must be at least as strong as the first cipher in
the chain. Against chosen plaintext, it must be at least as
strong as the strongest. Both assume independent keys. See:
U. M. Maurer and J. L. Massey.
Cascade ciphers: The importance of being first.
J. of Cryptology, Vol. 6, No. 1, pages 55-61, 1993.
> Simply by preventing access to information which is otherwise
> considered exposed (plaintext and the related ciphertext for one of
> the internal ciphers), whole classes of attacks simply cannot be
> mounted.
That's just a handwave. Excluding the obvious way to mount
the attack proves nothing.
> The other issue is what we do not know. Presumably, your argument is
> that if we are willing to assume that a particular cipher can be
> broken, we might as well assume that all ciphers can be broken, and
> there can be no advantage. So if we can throw a baseball, we should
> be able to throw a house. What is wrong with this reasoning?
That reasoning is your own straw man. I think we can agree
that the three cipher chain with independent keys is a more
conservative design that any one of those three ciphers by
itself. It does not solve the problem of uncertainty about
the strength of encryption. On the issue provable strength we
have a tie.
> If we are willing to accept that some ciphers may be weak (of course
> we would not knowingly use a weak cipher), it is to our advantage to
> use multiple ciphers -- I would say at least three -- including the
> best we know of. If that cipher really *is* good, the data are
> protected. But if there is some weakness in that cipher -- and if
> that weakness can be exploited in the ciphering chain -- then the
> other ciphers may act to protect our data in the face of weakness.
Of course we can apply the same reasoning to the three-cipher
chain to show that we should use a nine-cipher chain. No
matter how many we compose, we never arrive at a method
certain to resist cryptanalysis. Somewhere we must make the
trade-off between efficiency and confidence in security.
Let's not fall for the fallacy that in cipher design, more
conservative means better. The only crypto that can protect us
is the stuff we deploy, not the stuff we advocate. Today the
world of personal and commercial communication runs on
un-authenticated cleartext. To change that, we need to build
crypto into the systems people actually use. AES is for the
real world.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: using AES finalists in series?
Date: Tue, 23 Jan 2001 16:21:17 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> > Terry Ritter wrote:
> > > That idea that we need "key efficiency" represents a time now long
> > > gone. In the context of modern communications, why should anyone be
> > > anxious about sending additional keying material? Do we really worry
> > > about sending another 256 bits, or 1024 bits, or whatever? This is
> > > message key material, random and endless; we can take all we need, and
> > > send it at almost no cost.
>
> This is utterly wrong. I'm currently working on the design of a
> new communication system, and key distribution is a major issue.
You too?? What will we do with so much expertise? I reflect that Herr
Ritter already sees efficiency as important, while so many follow Carson's
Rule, to fill all available space as quickly as possible. It stands to
put reasonable restraint of endless data waste clearly ahead of some small
additional amounts used to greatly increase security. Repeating a flawed
maximim that encyption must suffer under impossible limitations to keep it
kosher is, respectfully, too picky.
--
Some people say what they think will impress you, but ultimately
do as they please. If their past shows this, don't expect a change.
------------------------------
From: "Ernst" <[EMAIL PROTECTED]>
Subject: Encrypted file?
Date: Tue, 23 Jan 2001 23:46:56 +0100
Hi,
I'was given a somehow encrypted file whose composition I doesn't understand.
The only hint is the file header. Viewed with a Hex Editor each file starts
with HEX "4C 43 46 31" (/*000000:*/ 0x4C, 0x43, 0x46, 0x31), ASCII "LCF1".
That is the only regularity. Does anyone know anything about the file type
or the kind of encryption? Thank you.
------------------------------
From: Bryan Mongeau <[EMAIL PROTECTED]>
Subject: TSEPRNG, a secure RNG ?
Date: Tue, 23 Jan 2001 23:00:34 GMT
We may very well have reinvented the wheel, but:
On the topic of CSPRNGs, a colleague of mine recently elucidated an
interesting theory:
What if, using lightweight processes (threads), controlled race conditions
can be created and their entropy tapped? Process scheduling is by nature
an extremely fickle beast, and running a controlled "race" with many
threads for a given number of rounds would result in exceedingly
unpredictable data, regardless of system status at the time.
Basically, entropy on demand, no collection routines required.
We have implemented this as an RNG, and are currently running statistical
analysis on the distribution of its randomness.
Some preliminary results: with the *same seed* ("1"), the RNG generated
309,000 numbers over the course of 3 days on a pII 500. There were only 180
collisions, even though the 32-byte output was CRCed. These tests were
conducted with 32 threads operating on 32 bytes for 3 rounds.
We would appreciate any feedback or insights on this RNG method, barring
its speed. It takes 500-750 msec per number using the test parameters, and
this is acceptable in our application. An intelligent approach to using
this CSPRNG in a secure app is to run it once, then use the random bytes to
seed a PRNG for quicker numbers later on.
We call it the Thread Scheduling Entropy PRNG. The programmer can set the
number of threads to participate in the race, the byte size to work on, and
the number of rounds. By bumping up the rounds, security is greatly
increased, at the cost of speed of course.
Criticisms/flames (TOM) welcome,
--
<==================================>
Bryan Mongeau
Lead Developer, Director
eEvolved Real-Time Technologies Inc.
www.eevolved.com
<==================================>
"I know not with what weapons World War III will be fought, but World War
IV will be fought with sticks and stones."-- Einstein
------------------------------
From: [EMAIL PROTECTED] (Noah Simoneaux)
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Tue, 23 Jan 2001 23:03:59 GMT
On Tue, 23 Jan 2001 11:46:07 -0800, "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
>I should have jumped on this sooner, and noticed that Szopa was posting to
>several groups for this. For those that are uninformed about the general
>concensus about Szopa, please have a look at the newsgroup history
>surrounding Szopa in sci.crypt (www.deja.com will be helpful). He is
>generally considered very offensive.
I was wondering about those initials. ASS? ;)
(snip)
Noah Simoneaux
Each of us is a mixture of good qualities and some(perhaps) not-so-good qualities. In
considering our fellow people, we should remember their good qualities and realize
that their faults only prove that they are, after all, only human. We should refrain
from making harsh judgments of people just because they happen to be dirty rotten
sons-of-bitches.
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Tue, 23 Jan 2001 16:42:00 -0600
In article <94i1dd$2nd$[EMAIL PROTECTED]>, zapzing <[EMAIL PROTECTED]> wrote:
> Void where prohibited by law.
>
Couldn't that get you in trouble?
--
Some people say what they think will impress you, but ultimately
do as they please. If their past shows this, don't expect a change.
------------------------------
From: Bryan Mongeau <[EMAIL PROTECTED]>
Subject: Re: Creating a self extracting encrypted exe?
Date: Tue, 23 Jan 2001 23:26:47 GMT
Ernst wrote:
> I'd like to automatically send encrypted self extractinc exe files via
> email. Does anyone know a tool which can automatically (batch) create self
> extracting exe files (secure protection). The (printed) public key or
> password could be sent via registered mail to customers.
> Does anyone know a maufacturer of such a software?
>
>
Google works:
http://data-encryption.com/datasheets/ds_dsht.html
--
<==================================>
Bryan Mongeau
Lead Developer, Director
eEvolved Real-Time Technologies Inc.
www.eevolved.com
<==================================>
"I know not with what weapons World War III will be fought, but World War
IV will be fought with sticks and stones."-- Einstein
------------------------------
Date: Tue, 23 Jan 2001 18:31:02 -0500
From: David Hamer <[EMAIL PROTECTED]>
Subject: Re: Some Enigma Questions
"Douglas A. Gwyn" wrote:
>
> > Q7: Did the German Navy's creation of a 4th rotor position that included a
> > rotor that in one position made the machine act like 3 rotor machine result
> > in a weakened 4th rotor -- even if it hadn't already been compromised
> > otherwise? Seems to me what the 4th rotor did was simply create a 3 rotor
> > machine with 26 possible reflecting rotors, instead of the previous 1 fixed
> > rotor. Right or wrong?
>
> I was under the impression that the additional rotor was a true rotor.
The fourth wheel was not a regular Enigma wheel and could only occupy
the LH wheel position as half of a 26-position reflector. It had no
notches and no ratchet and did not move during
encipherment/decipherment.
A 'Greek' wheel has 'pins' [spring contacts] on both sides unlike a
normal
Enigma wheel which has 'pins' on one face and 'plates' [flat contacts]
on
the other.
There were two 'Greek' wheels [Beta and Gamma] and two 'thin reflectors
B and C]. Thus there were four possible pairings each of which created
a 26-position, settable Umkehrwalze. When a Beta/B or Gamma/C
combination
was used and set to the 'A' position [in the Enigma window] the M4 acted
like a 3-wheel machine with a 'B' or 'C' reflector, respectively.
The best reference for this is 'Naval Eniga: M4 and its Rotors' by Ralph
Erskine and Frode Weierud, Cryptologia, Volume XI(4), October 1987.
David Hamer
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David Hamer The Crypto Simulation Group
[EMAIL PROTECTED] or [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Snake Oil
Date: Tue, 23 Jan 2001 23:26:59 GMT
Anthony Stephen Szopa wrote:
> Richard Heathfield wrote:
> >
> > Anthony Stephen Szopa wrote:
> > >
> > <snip over 200 lines>
> > >
> > > So that's all I have to say for a while.
> >
> > Is that a promise?
>
> Here is a guy who spits on the souls of anyone for no damned reason.
>
> I told you that I am the inventor that will save people tens or
> hundreds of billions of dollars in lost revenue and you verbally
> shit on me with your sarcasm.
> <snip>
> Gee, you didn't get any more significant information from me about
> my claim?
>
> Too bad.
My Daddy told me, "Son, if it looks like snake oil, tastes like snake
oil, and a smells like snake oil, it is usually snake oil." My Daddy was
a wise man and he loved me very much. He rarely misled me.
We see a lot of claims here that look like snake oil. Sci.crypt seems to
attract more than its fair share of snake oil. We are very sensitive to
snake oil and have a very low tolerance for it. This is not a place for
unsupported assertions. It is not a place for the discussion of trade
secrets or pending patents. These might be snake oil; it is not
possible to tell. It is not personal it, is just sci.crypt.
We have noticed that snake oil salesmen have very thin skins; they are
easily provoked and become very defensive. One can often detect a snake
oil salesman by taking a little poke at him and watching to see how he
walks and talks. If he walks like a snake oil salesman and talks like a
snake oil salesman, he may be a snake oil salesman; one cannot tell for
sure. Sci.crypt attracts a lot of snake oil salesmen and we tend to have
a very low tolerance for them. We have a low tolerance for people who
are overly defensive. It is not personal, it is just sci.crypt.
Being a great inventor, humanist, philosopher, or philanthropist is not
much of a defense here. We might not crucify Jesus Christ here but we
would certainly contribute the hammer and the nails. It is not personal,
it is just sci.crypt.
Please do not take it personally or go away mad; just go away. There
are probably lots of forums that will appreciate you for the great human
being that you are. We are not one of them. It is not personal, it is
just sci.crypt.
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: TSEPRNG, a secure RNG ?
Date: Tue, 23 Jan 2001 23:35:01 GMT
Yes, similar things have been done. "TrueRand" is think is one where
differences between multiple timers in the system is used for entropy.
As with many things, these can potentially be controlled by an attacker
and should be used with other forms of entropy.
- Andrew
In article <m2ob6.1674$[EMAIL PROTECTED]>,
Bryan Mongeau <[EMAIL PROTECTED]> wrote:
> We may very well have reinvented the wheel, but:
>
> On the topic of CSPRNGs, a colleague of mine recently elucidated an
> interesting theory:
>
> What if, using lightweight processes (threads), controlled race
conditions
> can be created and their entropy tapped? Process scheduling is by
nature
> an extremely fickle beast, and running a controlled "race" with many
> threads for a given number of rounds would result in exceedingly
> unpredictable data, regardless of system status at the time.
>
> Basically, entropy on demand, no collection routines required.
>
> We have implemented this as an RNG, and are currently running
statistical
> analysis on the distribution of its randomness.
>
> Some preliminary results: with the *same seed* ("1"), the RNG
generated
> 309,000 numbers over the course of 3 days on a pII 500. There were
only 180
> collisions, even though the 32-byte output was CRCed. These tests
were
> conducted with 32 threads operating on 32 bytes for 3 rounds.
>
> We would appreciate any feedback or insights on this RNG method,
barring
> its speed. It takes 500-750 msec per number using the test
parameters, and
> this is acceptable in our application. An intelligent approach to
using
> this CSPRNG in a secure app is to run it once, then use the random
bytes to
> seed a PRNG for quicker numbers later on.
>
> We call it the Thread Scheduling Entropy PRNG. The programmer can set
the
> number of threads to participate in the race, the byte size to work
on, and
> the number of rounds. By bumping up the rounds, security is greatly
> increased, at the cost of speed of course.
>
> Criticisms/flames (TOM) welcome,
>
> --
> <==================================>
> Bryan Mongeau
> Lead Developer, Director
> eEvolved Real-Time Technologies Inc.
> www.eevolved.com
> <==================================>
>
> "I know not with what weapons World War III will be fought, but World
War
> IV will be fought with sticks and stones."-- Einstein
>
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Tue, 23 Jan 2001 23:37:26 GMT
On Tue, 23 Jan 2001 22:12:41 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>All of which is not a problem, because the actual permutation which
>encrypted the data is hidden in that clump. There is no information
>to distinguish the correct one.
>You might as well say there is a problem because one could read the
>RNG state and thus know the keying of the cipher. We assume that
>state is kept secure.
>There is no way to distinguish the correct permutation from the huge
>group which can generate the same transformation. And it is only the
>correct permutation which leads back (eventually) to the shuffling
>sequence.
>A weakness which cannot be exploited is no weakness at all.
But in what way does that differ from me saying that - if I propose a
cipher which consists of four rounds of DES, with subkeys supplied by
some form of stream cipher generator - that given a corresponding
plaintext and ciphertext after two rounds,
there are 2^32 different subkey pairs which could have produced that
particular output from the given input? (because of the expansion
permutation and the way the S-boxes in DES work)
If _you_ are going to complain that DES isn't a good starting point to
work from, because it can't produce all (2^64)! mappings between
inputs and outputs, so it's not a "true general substitution", then I
don't see why I shouldn't point out that Dynamic Transposition is also
not a true general substitution of bit-balanced blocks.
Ah, but it's a transposition, and it is a "true general
transposition", you seem to have said. I'm pointing out that this is
something that really doesn't matter; if it's a limitation for one
case, it's a limitation for the other case as well, that the total
overall relation of possible inputs to possible outputs is limited.
Essentially, the fact that "transposition" is used as the name for a
class of ciphers considered distinct from substitution - while "XOR",
or "monalphabetic substitution" are considered forms of substitution -
is leading you into a fallacy based on regarding accidental historical
linguistic habits as somehow fundamental.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Tue, 23 Jan 2001 19:06:16 -0500
From: David Hamer <[EMAIL PROTECTED]>
Subject: Re: Some Enigma Questions
"David C. Barber" wrote:
>
> Q8: Is there a reference that gives the rotor wiring for all German WW II
> rotors?
>
> *David Barber*
If you go to: <http://www.eclipse.net/~dhamer/Enigma1.htm>
...you'll be able to download the complete wiring for all of
the Service Enigmas.
The link is at the bottom of the page...
David Hamer
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David Hamer The Crypto Simulation Group
[EMAIL PROTECTED] or [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
