Cryptography-Digest Digest #408, Volume #11 Fri, 24 Mar 00 04:13:01 EST
Contents:
"THE DES, An Extensive Documentation and Evaluation" - from Aegean ("John A.
Malley")
Re: Open source or not. (Was: Re: Planet Poker Claims...) (Johnny Bravo)
Re: Card shuffling (DMc)
Re: implementing rot13 ([EMAIL PROTECTED])
Re: 64-bit Permutations (Paul Rubin)
Re: what is a 2048 bit cipher? (Gareth Howell)
Re: Open source or not. (Was: Re: Planet Poker Claims...) (Mike Caro)
Re: NIST publishes AES3 papers (Jim Gillogly)
Re: NIST publishes AES3 papers (Jim Gillogly)
Re: new Echelon article (Arturo)
Re: OAP-L3: Answer me these? (Anthony Stephen Szopa)
Re: Hashing Algorithms. (basic newbie question) (Yen-Choon Ching)
Re: Hashes! (newbie question) (Runu Knips)
Re: pgp key collision (Lutz Donnerhacke)
Re: OFB, CFB, ECB and CBC (Jerry Coffin)
Re: OAP-L3: Answer me these? ("Joseph Ashwood")
----------------------------------------------------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: "THE DES, An Extensive Documentation and Evaluation" - from Aegean
Date: Thu, 23 Mar 2000 22:25:21 -0800
Hello all,
Has anyone ever read "THE DES, An Extensive Documentation and
Evaluation, Mikael J. Simovits" from Aegean Press? Aegean Press' web
site outlines the content as follows:
Chapters include: History of the DES and Fundamental Theory;
Differential Cryptanalysis;
Linear Cryptanalysis;
plus various appendices.
If you bought it and read it, would you recommend it to someone
interested in learning more about differential and linear cryptanalysis?
Does it provide examples?
Thanks,
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Open source or not. (Was: Re: Planet Poker Claims...)
Date: Fri, 24 Mar 2000 01:03:21 -0500
On Thu, 23 Mar 2000 23:10:09 GMT, Mike Caro <[EMAIL PROTECTED]> wrote:
>>>I also specifically challenge the idea that "atomic decay" methods of
>>>random number generation are a superior solution.
>>
>> Because natural atomic decay is proven to be random. If you know of a
>>flaw in John Bell's proof or Alain Aspect's experimental verification of
>>that proof, publish it and pick up your Nobel Prize in Physics. :)
>
>Interesting, and I take it in the good smiley-face spirit it was
>delivered, but it doesn't seem to apply to what I said.
Why? You challenge that "atomic decay" methods are superior. Do you
have any proof that any other method is random? Hard to be superior in
randomness than something absolutely proven to be random.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: DMc <[EMAIL PROTECTED]>
Subject: Re: Card shuffling
Date: Fri, 24 Mar 2000 06:43:46 GMT
On Thu, 23 Mar 2000 17:20:19 GMT, [EMAIL PROTECTED] (Scott Nelson)
wrote:
[snip]
>>[EMAIL PROTECTED] previously wrote:
>>
>>On your probability scale all possible sequences, or
>>lack of sequences, will total 1. Of course, you may have a mental
>>picture of what you mean by a sequence value of 0, and the
>>reversible card ordering which will cause that 0. I am interested in
>>seeing such an example from you.
>
>I defined "sequence value" as the number of cards which are in
>sequence.
>
>Assume the deck is ordered;
>Ac 2c 3c 4c 5c 6c 7c 8c 9c Tc Jc Qc Kc -
>Ad 2d 3d 4d 5d 6d 7d 8d 9d Td Jd Qd Kd -
>Ah 2h 3h 4h 5h 6h 7h 8h 9h Th Jh Qh Kh -
>As 2s 3s 4s 5s 6s 7s 8s 9s Ts Js Qs Ks
>
>By definition this has a sequence value of 51.
>That is, 51 of the cards are followed by the
>next card in sequence.
>
>Now reverse the order of the deck;
>Ks Qs Js Ts 9s 8s 7s 6s 5s 4s 3s 2s As -
>Kh Qh Jh Th 9h 8h 7h 6h 5h 4h 3h 2h Ah -
>Kd Qd Jd Td 9d 8d 7d 6d 5d 4d 3d 2d Ad -
>Kc Qc Jc Tc 9c 8c 7c 6c 5c 4c 3c 2c Ac
>
>That has a sequence value of 0. That is, 0 of
>the cards are followed by the next card in
>sequence.
>
For me, the reverse order in example two is just as sequenced
as the original order in example one.
>
>Here's a an example of a sequence value of 1.
>Tc 7d Th Qd 9h 3s Js 2h 9c Jc 4c 8d 5c -
>Kc Qs Qh 2c 8c 4h Ks As 6c Jd 8h 2d Td -
>5d 7s 7c 9s Ah Qc Kd 3d 4d 5h 7h Ac Kh -
>Ts Ad 6h 5s 6s 9d 3h Jh 2s 3c 8s 4s 6d
>
>The 5s is followed by the 6s, but no other
>cards are followed by the next card in
>sequence.
>
Just a small point: In row 3, the 8th and 9th cards are
also a sequence; 3d - 4d.
>
>As you pointed out, if one chooses a random permutation,
>the probability that it will have a sequence value
>between 0 and 51 inclusive, is 1.
>
>As I pointed out, if one chooses a random permutation,
>the probability that it will have a sequence value
>greater than 8 is very small - less than .1%.
>
>If one chooses a permutation by an unknown process
>and the sequence value is greater than 8,
>then there's good reason to doubt the randomness
>of the choosing process. If you repeat the process
>ten times, and get a sequence value greater than 8
>all ten times, then it's even more likely that
>the choosing process is not random.
>
There seems to be an internal inconsistency with your 0 -> 51 indirect
probability scale. Your reverse order number two example rates 0,
which is less than 8. You imply it is most possible. Example one rates
51, which must be the rarest possibility. Yet examples one and two are
absolute equivalents by inspection. Furthermore, example three seems
to be more than one (or two) increment(s) away in probability from
example two.
Two other small, or large, points:
1. I do not see what your 0 -> 51 scale adds in utility to your
decimal probability scale.
2. I fail to see past the practical difficulty of someone, no matter
how experienced, totally reversing the order of a card deck while
appearing to be riffling it. I think that to be the stuff of theater.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: implementing rot13
Date: Fri, 24 Mar 2000 06:46:43 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Dan Day wrote:
> >Why not instead:
> >for ( char *s=string; *s; s++)
> > *s += isalpha(*s) ? (toupper(*s)<('A'+13))*26-13 : 0;
>
> Cute.
> Okay, the gauntlet has been thrown -- who can do it in even
> fewer (non-whitespace) characters?
replace 'A'+13 with 'N'
- --
Disastry
http://i.am/disastry/
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
Comment: get this Plugin at http://disastry.dhs.org/pgp.htm
iQA/AwUBONrzKTBaTVEuJQxkEQL77wCffWnnsCzpahlAxytcrmuyns/zZ7wAnR61
WhHaqrdQeuc5z6+ppZryITtF
=FwVo
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: 64-bit Permutations
Date: 24 Mar 2000 06:54:12 GMT
In article <[EMAIL PROTECTED]>,
Stephen Houchen <[EMAIL PROTECTED]> wrote:
>Imagine a cipher where you took plaintext in 64-bit blocks.
>The bits in each block are simply permuted in the same
>fashion for each block. The key, then would be the bit-
>mapping.
>
>My gut feeling is that this is so simple that it's probably not
>very hard to break.
>
>So cryptanalysts, how would you break it?
Utterly trivial chosen plaintext attack: use 64 chosen plaintexts:
000000000..0001
000000000..0010
000000000..0100
000000000..1000
...
000100000..0000
001000000..0000
010000000..0000
100000000..0000
Encrypting them all gives you the solution.
Known plaintext is a little harder and is left as an exercise.
Note that E(A xor B) = E(A) xor E(B). So if you have two known
plaintexts that differ in just one bit, that immediately reveals
one of the "wires" in the cipher.
------------------------------
From: Gareth Howell <[EMAIL PROTECTED]>
Subject: Re: what is a 2048 bit cipher?
Date: Fri, 24 Mar 2000 08:53:52 +0200
In article <7rBC4.65644$[EMAIL PROTECTED]>, "Tom St Denis"
<[EMAIL PROTECTED]> wrote:
> So how do ciphers and algorithms fall? Cryptanalysis. Essentially not
> abrute force search.
Hi !
More often than not its because someone left their password lying around, or even
because they chose a bad password.
Who needs to search through 2048 bits , or whatever, if they only have a 5 character
password ?
Cheers
Gareth
--
Our greatest glory is not in never falling,
but in rising every time we fall.
- Oliver Goldsmith
------------------------------
From: Mike Caro <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Open source or not. (Was: Re: Planet Poker Claims...)
Date: Fri, 24 Mar 2000 07:04:32 GMT
On Fri, 24 Mar 2000 01:03:21 -0500, Johnny Bravo <[EMAIL PROTECTED]>
wrote:
>On Thu, 23 Mar 2000 23:10:09 GMT, Mike Caro <[EMAIL PROTECTED]> wrote:
>
>>>>I also specifically challenge the idea that "atomic decay" methods of
>>>>random number generation are a superior solution.
>>>
>>> Because natural atomic decay is proven to be random. If you know of a
>>>flaw in John Bell's proof or Alain Aspect's experimental verification of
>>>that proof, publish it and pick up your Nobel Prize in Physics. :)
>>
>>Interesting, and I take it in the good smiley-face spirit it was
>>delivered, but it doesn't seem to apply to what I said.
>
> Why? You challenge that "atomic decay" methods are superior. Do you
>have any proof that any other method is random? Hard to be superior in
>randomness than something absolutely proven to be random.
Interesting, but it doesn't seem to apply to what I said.
Straight Flushes,
Mike Caro
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES3 papers
Date: Fri, 24 Mar 2000 07:23:13 +0000
"Douglas A. Gwyn" wrote:
>
> Jim Gillogly wrote:
> > there's no significant difference in strength between a
> > 112-bit search and a 127-bit one... they're both out reach.
>
> I'm sure Jim knows this, but he forgot to add the qualification:
> "assuming that there is no attack substantially better than
> brute-force key search". Which is quite an assumption..
Yes, attacks substantially better than brute force are the ones to
watch for, and of course when one is found all bets are off. However,
my remark is true in that I was observing the similarity between a
112-bit search and a 127-bit search... not an analytical search to
break an algorithm that would require a 112-bit search to solve with
brute force.
--
Jim Gillogly
3 Astron S.R. 2000, 07:20
12.19.7.1.3, 1 Akbal 11 Cumku, Fifth Lord of Night
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES3 papers
Date: Fri, 24 Mar 2000 07:29:52 +0000
Joseph Ashwood wrote:
>
> "Jim Gillogly" <[EMAIL PROTECTED]> wrote in message
> > I don't see that. The three doses of DES use different
> keys.
>
> Actually most implementations only use 2 keys, because of
> the meet in the middle attack.
Not in IPSec -- using two keys is an error.
> My statement was with regards to the maximal strength, since
> all attacks on the methods are not known, we can only make
> estimates, and the current estimates of an AES finalist is
> 30,000+ times the strength of triple-DES.
And my point is that it doesn't matter if a brute force search
takes millions of times longer than another brute force search
that's also totally out of reach. Here's a thought experiment: why
aren't you using 8192-bit or 16384-bit RSA moduli? Why shouldn't
AES have required 512-bit or 1024-bit symmetric keys? Wouldn't
those make it ever so much more secure? (Always assuming the
lack of an analytical attack that's much better than brute force,
as Doug correctly points out.)
The answer to the thought experiment is that at some point
you have enough protection against brute force attacks, and
doubling the keylength for that system does nothing for you
but use up your keybits twice as fast.
--
Jim Gillogly
3 Astron S.R. 2000, 07:23
12.19.7.1.3, 1 Akbal 11 Cumku, Fifth Lord of Night
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Arturo)
Subject: Re: new Echelon article
Date: Fri, 24 Mar 2000 07:57:41 GMT
On Fri, 24 Mar 2000 01:29:29 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>John Savard wrote:
>>
>> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>> >Mok-Kong Shen wrote:
>>
>> >> ... German companies may expend money in
>> >> bribery in foreign (as against national) contracts and have tax
>> >> deductions too. From what you wrote above, I deduce that this is
>> >> forbidden by law in the US.
>>
>> >Indeed, we have a general principle that assisting someone else
>> >in the commission of a crime is a crime in itself.
>>
Before we turn this into a bribery-yes-vs-no thread, let me remember
a couple points.
First, Echelon does not spy on European bribing companies because
they want to level the field and make it more fair for US industries.
Echelon does spy on every European company it can.
Second, Echelon does not spy on European companies alone. They spy
on just one word: everything. They have been doing it for years. Europe is
paying attention now only because there�s big money on it, but its existence
has been known and denounced for over a decade.
Third, Echelon is not the only big ear around snooping on civilian
traffic. French and others have also been doing, fine. But at least they
didn�t try to sell the story that they are defending the free world.
Fourth, Echelon was created during the Cold War, and now that it�s
over they are just trying to give it some other job. It�s like using Desert
Storm troopers as bank security guards, M1 and Apache choppers included.
Fifth, I really don�t care a damn about the damage on private
companies. After all, if they are so careless as to talk about
billion-dollar contracts on insecure comm. means, they deserve what they
get. If I�m going to get a thousand bucks our of an ATM machine, I won�t
cry out loud.
Sixth: what I am really concerned is about the fact that Echelon
(along with their little brothers, cousins and the like) is after our
communications. All of them. No matter if we behave or not, if we are
law-abiding citizens or the bad guys. If you read Orwell�s 1984, Big
Brother was just that: the big brother that listens, sees and knows all,
regardless of what the people think or make.
We are all treated as guilty until proven otherwise, and to hell
with our constitutional rights. If they want it that way, I want to hear it
loud and clear from them. At least, that would let us know where we all
stand.
And as for Thomson or Boeing, stop crying and protect your secrets
better. I don�t care; after all, we don�t get a buck out of their profits
do we?
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Thu, 23 Mar 2000 23:40:56 -0800
Joseph Ashwood wrote:
>
> > OAP-L3: Answer me these?
> >
> > Where is the bias in any of the procedures and processes
> in OAP-L3?
>
> First we need to see your algorithms, but you don't want to
> reveal those.
>
> >
> > Where is any bias introduced into any of the procedures
> and processes
> > found in OAP-L3 when used according to recommendations?
> In the algorithm(s) that generate the ordering.
>
> >
> > What conclusions can we draw if there are no biases in any
> of the
> > procedures and processes, and no biases introduced in
> > any of the procedures and processes used in OAP-L3?
>
> We can draw no conclusions from lack of bias. A very simple
> example of a completely unbiased, and still completely
> useless stream is generated by simply iterating through each
> possible output in order. For example
> 0123456789012345678901234567890123456789.....
> There is no bias, but it is certainly not suitable for
> random number generation.
> Joe
You are sure a great talker. I wonder how many of you are busily
studying OAP-L3 theory, and procedures and processes all the while
"dissing" OAP-L3 and evading the software publicly? I think some
of you should be suspicious. When opportunity knocks there are
those who know enough to answer the door. Some disperse smoke
screens to confuse others. Bill Gates jumped on an opportunity
while nearly everyone else remained clueless. How many of you are
CHOOSING to remain clueless?
It appears that you (and most others) have willfully chosen not to
address the theory, and specification of the procedures and
processes. This should be noted by all readers to this news group.
It appears that the attack has admittedly been chosen to be an
attack on the implementation. No other options?
I thank many of you for unintentionally giving me such credibility
(short-lived or not.)
By the way, "0123456789012345678901234567890123456789....." is
totally biased and certainly not random. How many in this
news group are impressed with your obtuse observations, ridiculous
illogical concoctions, and equally ridiculous conclusions? What are
they learning from you? Certainly not critical thinking.
By the way, OAP-L3 Version 4.3 will be available in about a week
or so. Six new processes are being added to mix things up even
more.
http://www.ciphile.com
Original Absolute Privacy - Level3 Encryption Software Package
------------------------------
Date: Fri, 24 Mar 2000 16:37:24 +0800
From: Yen-Choon Ching <[EMAIL PROTECTED]>
Subject: Re: Hashing Algorithms. (basic newbie question)
This is a multi-part message in MIME format.
==============AE81BE9FEC5E845596898D27
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> Hash functions, by definition, should be collision resistant. That is, it
> should be computationally infeasable to find distinct message X, Y s.t. H(X)
> = H(Y)
> However, unless SD was collision resistant, then you can find distinct
> message X, Y s.t. SD(X)=SD(Y) which would imply H(X)=H(Y)
How do you prove that it is collision resistant? I can do an exhaustive
search if it is 40 bit. Do you do this also for 160-bit hash?
BTW, are there any different with these terms:
- one-way function
- hash function
- collision free hash function
Do they meant the same thing?
==============AE81BE9FEC5E845596898D27
Content-Type: text/x-vcard; charset=us-ascii;
name="ycching.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Yen-Choon Ching
Content-Disposition: attachment;
filename="ycching.vcf"
begin:vcard
n:Ching;Yen-Choon
x-mozilla-html:FALSE
org:Multimedia University;Faculty of Engineering
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Tutor
fn:Yen-Choon Ching
end:vcard
==============AE81BE9FEC5E845596898D27==
------------------------------
Date: Fri, 24 Mar 2000 09:37:15 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Hashes! (newbie question)
Boris Kazak wrote:
> Original message is divided into segments of the size
> twice that of the final hash. The size of the hash and
> segments is #defined by the HASHBLOCKSIZE constant and can
> be altered according to need. For example, if the final hash
> will be 160 bit, the segments will be 320 bit each.
>
> This proposed function is based on multiplication
> (mod 2^32+1) with some "twists". The function uses one single
> modular multiplier which in the program is #defined as
> "SEED". This number is 0x6A09E667, which happens to be
> the first 8 hex digits of SQRT(2), less initial 1.
> The use of this number should dispel any suspicions about
> a "trap door" built into SEED.
>
> In all subsequent description I shall refer to the
> M-transformation, which is now going to be described.
> All multiplications are assumed to be (mod 2^32+1).
This doesn't look like a good algorithm.
(a) a toggled input bit has to toggle 50% of the output
bits (in average) in a good oneway hash function.
here it only affects 32 of the output bits !!!
(b) you use nothing but multiplication to produce the
hash. muliplication is both slow and bad for certain
input values (for example, 0*anything=0).
------------------------------
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Subject: Re: pgp key collision
Date: 24 Mar 2000 07:44:55 GMT
* Paul Koning wrote:
>Lutz Donnerhacke wrote:
>> Of course. I only refered to a deadbeed attack as a attack to a given
>> section of the fingerprint.
>
>Ok, fine, then you agree that there is NOT a problem with key
>fingerprints -- because key fingerprint checking means checking
>all the bits of the fingerprint, not just 32 bits --
Ack.
>everyone knows that.
Nack.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: OFB, CFB, ECB and CBC
Date: Fri, 24 Mar 2000 02:03:32 -0700
In article <hOCC4.3532$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> What the heck is this?
> OFB, CFB, ECB and CBC
Output FeedBack, CipherFeedBack, Electronic Code Book and Cipher
Block Chaining, respectively.
> I understand that CBC is a way to check if a file is preserved in its
> original state...is this true?
Hmm...CBC (as well as CFB) chain blocks together, BUT they also allow
a degree of error recovery. If there's an error in transmitting one
block, CFB or CBC will automatically re-syncrhonize after another
block, and the rest of the file will be received intact (unless there
are more errors in transmission).
> What are the differences among the types and which should I use for an
> encryption routine...and why?
I'd advise CBC or CFB, but that's more or less personally personal
prejudice.
> I'm wondering this because I am attempting to use a SkipJack routine that
> has these various implementations available to me.
ECB encodes each block completely separately from all the others, so
if an attacker knows the contents of a particular block, they know
what they block will encrypt to with any particular key. With the
other modes, the blocks are chained together (with an Initialization
Vector as the first block) so they won't know this ahead of time. In
descending order of preference, I'd use CBC, CFB, OFB and finally, if
I had NO other choice, ECB.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Fri, 24 Mar 2000 00:57:58 -0000
Crossposted-To: talk.politics.crypto
Let's analyse your claims.
Claim 1) Someone intelligent is busy analyzing your theory
Reality 1) You have revealed virtually nothing about your
theory.
Claim 2) We have chosen to ignore your theory
Reality 2) See Reality 1
Claim 3) We attack only your implementation
Reality 3) Your implementation is the only reference for you
method, since you theory claims are totally worthless
Claim 4) We are unintentionally giving you credibility
Reality 4) That may be the case for a very small number of
people, while the majority will actually read what has been
said, and realize that what has been said is that without
further knowledge we can only assume that your method is
worthless.
Claim 5) 01234567890123456789... is biased
Reality 5) Each output digit will occur an exactly equal
number of times making a bias of exactly zero
Claim 6) By adding a new process you inherently add ability
to "mix things up even more"
Reality 6) That is simply not the case a trivial example is
to use 2 functions (what you call processes) where the
second is the inverse of the first, regardless of the
functions chosen this makes for a very weak stream.
Joe
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
