Cryptography-Digest Digest #382, Volume #10 Sat, 9 Oct 99 23:13:03 EDT
Contents:
Re: Ritter's paper
Re: Using PGP as a source of random numbers (Jim Dunnett)
Re: on linear keyspaces (Tom St Denis)
Re: Using PGP as a source of random numbers (jerome)
Re: on linear keyspaces (SCOTT19U.ZIP_GUY)
Re: Q: AI (Tom St Denis)
Re: FBI issues warrant for Alice & Bob (James Moore)
Re: spoofing a crl ([EMAIL PROTECTED])
Re: David A. Huffman, "father" of compression died yesterday (Jim Haynes)
Re: Addition/subtraction mod 256 vs. XOR ([EMAIL PROTECTED])
Re: Research paper...
Re: Research paper...
Re: Research paper...
Re: on linear keyspaces (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Ritter's paper
Date: 9 Oct 99 20:51:42 GMT
[EMAIL PROTECTED] wrote:
: Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
: : The original papers when published in the open
: : literature around 1967 had all cryptologic applications
: : carefully expunged, alas.
: Well, that's understandable: but if one, from the mathematical literature,
: understands the concepts involved, I would think that coming up with at
: least some of the simpler cryptologic applications might not be too hard
: (even if the most important ones might be missed for a while).
: At the moment, I only recall the very simple example of a Markov model
: given in Scientific American wherein one, starting with balls numbered
: from 00 to 99 in one of two containers, switched a ball from one container
: to the opposite one when its number was selected.
: That nicely illustrated how pressure would equalize between two vessels
: after the valve between them was opened, so it was nice for understanding
: thermodynamics and statistical mechanics, but _that_ kind of model
: certainly was far away from anything cryptological. Unless one is
: enciphering cocktail party conversation which is starting to get boring.
Thus, instead of the Markov chain, one wants something more "steady-state"
to model a language. My pet model of English text for compression purposes
works like this:
First one draws from a drum packed with word lengths distributed as in
English. This starts a counter.
Then, one draws from a drum with letters distributed according to the
initial letter frequency in English.
Then, as long as the counter allows, one draws from one of 26 drums,
labelled with the previous letter one has drawn.
Thinking of the model this way helps one to see where it is lacking. The
word length is chosen independently of letters, so one should really do
something more 'organic'; first draw for how many syllables are in the
word, then draw from a drum with slips in it labelled v, cv, vc, and cvc,
and then one has drums for the part before the vowel, the vowel, and the
part after the vowel of a syllable...
or, if one doesn't wish to parse syllables when compressing, there is
still the fact that the high frequency of T as an initial letter comes
from short words like "the" and "that", so one should really have a
separate initial-letter drum for each word length...
It seems, though, that Markov models are primarily relevant to cryptology
by helping us improve our compresssion algorithms, from this preliminary
glance.
John Savard
------------------------------
From: amadeus @0SPAM.netcomuk.co.uk (Jim Dunnett)
Subject: Re: Using PGP as a source of random numbers
Date: Sat, 09 Oct 1999 18:56:29 GMT
Reply-To: Jim Dunnett
On Sat, 09 Oct 1999 13:49:40 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
wrote:
> But it would be best ot get something based on some quantum effect like
>radioactive decay or some other quatum measurment for true randomness.
Radio noise/static is also useful for this.
--
Regards, Jim. | The mad are all in God's keeping.
amadeus%netcomuk.co.uk |
dynastic%cwcom.net |
| Kipling, 1865 - 1936.
PGP Key: pgpkeys.mit.edu:11371 |
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: on linear keyspaces
Date: Sat, 09 Oct 1999 21:49:24 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> : Ok I think some mass confusion has gone around about this compress/encrypt
> : stuff.
>
> : Assuming with the current attack the keyspace is linear, you still have to
> : search on avg 1/2 of the keys before you find the right one. I could for
> : example give you
>
> : 12345678 = Ek(ABCDDCBA)
>
> : And you would have to search about 1/2 of the keyspace before you found it.
>
> : So really it doesn't matter what compression you use. Even if it's
> : one-to-one I could expect to find the key in the same ammount of time.
>
> Even if the /only/ attack on the cypher is trying keys sequentially,
> an automated technique for determining if you have the right key is
> still likely to help, as trying to decompress is probably easier to
> automate than frequency analysis on the (English?) plaintext.
>
> However, to my mind, the whole point of eliminating clues from the
> compression algorithm is that it makes *other* types of cryptanalysis
> (*besides* brute-forcing the keyspace) more difficult - by removing
> statistical artefacts from the compressed text.
>
> : And another thing is that if your routines are 'functions' (i.e reversible)
>
> Functions = reversible?!? ;-)
>
> : then you can still look for patterns in the output. I could for example look
> : for words or structured grammer in the output and not just ascii text.
> : It's not hard, just takes linearly more time.
>
> Again, this is assuming that the attack on the compressed, encyphered
> text involves brute force search through the keyspace. If the attack
> involves spotting irregularities in the compressed text and working from
> those, this consideration may not be relevant. In particular if
> you need anything less than the whole plaintext to conclude that the
> result is an invalid compressed file, that might be a source of problems.
>
> : So you might make the keyspace x(2^n) instead of just 2^n by using
> : one-to-one, but I can simply add log2(x) bits to the key and use my
> : current method.
>
> Well, yes (again assuming the only possible attack is to brute-force the
> keyspace). Alternatively you can increase the size of the key to be the
> size of the message and use a OTP.
>
> Increasing the size of the key unnecessarily is not good practice.
> Surely it would be better to remove the inefficiency that's causing the
> use of the longer key at its root.
> --
Ok I should have said flat keyspaces, but my point is still valid. If the
keyspace is flat, then NO OTHER attack exists. Otherwise it's not flat. For
example in DES it's not for several reasons. a) it has weak keys, b) keys
can become weak after an enormous amount of work. none of this is damaging
but still thems the facts.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Using PGP as a source of random numbers
Reply-To: [EMAIL PROTECTED]
Date: Sat, 09 Oct 1999 20:36:46 GMT
about automatic test of randomness, i would like to know if
D0=0; Di = MD5(Di) pass these tests ?
On Fri, 08 Oct 1999 23:14:32 GMT, Johnny Bravo wrote:
>
> Use scramdisk from www.scramdisk.clara.net, the container files it creates
>pass the Diehard test suite for randomness and can be created to very large
>sizes easily. They might be suitable for your purposes.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: on linear keyspaces
Date: Sat, 09 Oct 1999 23:42:51 GMT
In article <7tod92$v7s$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> Tom St Denis <[EMAIL PROTECTED]> wrote:
>>
>> : Ok I think some mass confusion has gone around about this compress/encrypt
>> : stuff.
>>
>> : Assuming with the current attack the keyspace is linear, you still have to
>> : search on avg 1/2 of the keys before you find the right one. I could for
>> : example give you
>>
>> : 12345678 = Ek(ABCDDCBA)
>>
>> : And you would have to search about 1/2 of the keyspace before you found it.
>>
>> : So really it doesn't matter what compression you use. Even if it's
>> : one-to-one I could expect to find the key in the same ammount of time.
>>
>> Even if the /only/ attack on the cypher is trying keys sequentially,
>> an automated technique for determining if you have the right key is
>> still likely to help, as trying to decompress is probably easier to
>> automate than frequency analysis on the (English?) plaintext.
>>
>> However, to my mind, the whole point of eliminating clues from the
>> compression algorithm is that it makes *other* types of cryptanalysis
>> (*besides* brute-forcing the keyspace) more difficult - by removing
>> statistical artefacts from the compressed text.
>>
>> : And another thing is that if your routines are 'functions' (i.e reversible)
>>
>> Functions = reversible?!? ;-)
>>
>> : then you can still look for patterns in the output. I could for example
> look
>> : for words or structured grammer in the output and not just ascii text.
>> : It's not hard, just takes linearly more time.
>>
>> Again, this is assuming that the attack on the compressed, encyphered
>> text involves brute force search through the keyspace. If the attack
>> involves spotting irregularities in the compressed text and working from
>> those, this consideration may not be relevant. In particular if
>> you need anything less than the whole plaintext to conclude that the
>> result is an invalid compressed file, that might be a source of problems.
>>
>> : So you might make the keyspace x(2^n) instead of just 2^n by using
>> : one-to-one, but I can simply add log2(x) bits to the key and use my
>> : current method.
>>
>> Well, yes (again assuming the only possible attack is to brute-force the
>> keyspace). Alternatively you can increase the size of the key to be the
>> size of the message and use a OTP.
>>
>> Increasing the size of the key unnecessarily is not good practice.
>> Surely it would be better to remove the inefficiency that's causing the
>> use of the longer key at its root.
>> --
>
>Ok I should have said flat keyspaces, but my point is still valid. If the
>keyspace is flat, then NO OTHER attack exists. Otherwise it's not flat. For
>example in DES it's not for several reasons. a) it has weak keys, b) keys
>can become weak after an enormous amount of work. none of this is damaging
>but still thems the facts.
>
Tom you still don't get it. Bad compression makes it easyer to break an
encrypted message. You can't even prove that any of the AES candidates
are safe from attacks less than a brute force seach. You seem to base
everyting on that assumpution. The fact is you can't.
But if one compresses it is foolish to give information to the attacker
by using a compression routine that can only help the attacker and that
is what most compression routines do. Why use one that aids the
attacker by rulling out most of the keyspace independent of the data
that was compressed.
Thems the facts.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Q: AI
Date: Sat, 09 Oct 1999 21:46:22 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
>
> > In which side? Cryptanalysis or actual protection? It has already been
> > developed in a limited sense such as the linear attack on DES. When you
> > think about it any program is AI, it's not sentient so to one degree it's not
> > a life form. But if you think about it, any program can perceive and make
> > decisions based on what it knows.
>
> I said cryptology, which includes both sides. Your concept of AI
> is definitely not shared by the majority in computer science.
Ok call it artificial decision maker, see what I care.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: James Moore <[EMAIL PROTECTED]>
Subject: Re: FBI issues warrant for Alice & Bob
Reply-To: [EMAIL PROTECTED]
Date: Sat, 09 Oct 1999 17:08:12 -0500
... thought the readers of this thread might also be interested in the
following:
An FBI memo written in 1946, and made public through the FoI Act
denounced the movie "It's a Wonderful Life", starring Jimmy Stewart
and Donna Reed, as Communist propoganda. According to the memo the
film attacked bankers "by casting Lionel Barrymore as a 'Scrooge-type'
so that he would be the most hated man in the picture... a common
trick used by Communists."
James Moore
=================================================================
"Truth is the most valuable thing we have. Let us economize it."
Mark Twain (1835-1910)
=================================================================
On 2 Oct 1999 16:46:25 GMT, "Goyra" <[EMAIL PROTECTED]>
wrote:
>
> Goyra news service
> Dateline 2.Oct.99
>
>The FBI issued today a warrant for the arrest of two
>persons known only as Alice and Bob. FBI director
>Louis Freeh stated "There are many first-hand
>accounts, in the cryptanalytic literature, of these two
>individuals communicating with secure systems. In
>some cases they are described as being in an unnamed
>"foreign country". The equipment they use is clearly
>subject to U.S. export restrictions and we want to interview
>them about just what equipment they have taken out
>of the country."
>
>The surnames of Alice and Bob are unknown, and no
>pictures are available. None the less the FBI are determined
>to pursue them. "This is an issue pertaining to national
>security" stated Freeh, "and we take it very seriously. Also
>we would like an individual known as Eve to step forward and
>tell us what she knows." Eve, according to all accounts, is
>a surveillance expert who has spent years trying to crack Alice
>and Bob's codes without success. "Eve has nothing to fear
>from us" stated Freeh. "In fact we want to employ her".
>
>
> (c) Goyra 1999
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: spoofing a crl
Date: 9 Oct 1999 15:08:05 -0700
In article <[EMAIL PROTECTED]>,
Miky <[EMAIL PROTECTED]> wrote:
>If somone or some security product requests a crl and does not have the
>issing CAs cert, can't a spoofed site offer its own CRL signed by its
>own keypair?
Any end entity which needs to verify a CRL needs to have a trusted copy
of the root CA's piblic key. Sometimes this is done by keeping a copy
of the (or more than one) CA's cert in a known place and using the
public key inside while traversing the chain (Netcape does this).
Sometimes a hash of the root CA cert is kept by the end entity (i.e.
embedded in code) which is then used to verify a root CA cert in the
chain.
Some security products allow the user to accept new root certs
into the "trusted root cert database", usually by answering a number
of dialog box questions of the form "Are you sure you want to do
this? Are you really really sure?". Some security products might
allow a user to accept a CRL signed by a "new" root CA. However it
would be a serious flaw to allow a CRL signed by one CA to revoke
certs signed by another.
------------------------------
From: [EMAIL PROTECTED] (Jim Haynes)
Crossposted-To: comp.compression
Subject: Re: David A. Huffman, "father" of compression died yesterday
Date: 9 Oct 1999 22:41:46 GMT
Reply-To: [EMAIL PROTECTED]
http://www.ucsc.edu/currents/99-00/10-11/huffman.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Addition/subtraction mod 256 vs. XOR
Date: 9 Oct 1999 22:51:59 GMT
In article <7t4sir$kel$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom St
Denis) wrote:
> You mean block[i] += state[(state[x] + state[y]) mod 256]; instead of
> the xor?
use subtraction instead of addition:
block[i] = state[(state[x] + state[y]) mod 256] - block[i];
does encrypt and decrypt
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Research paper...
Date: 10 Oct 99 01:07:13 GMT
[EMAIL PROTECTED] wrote:
: I'm doing an extended essay (4000 words) for the IB program at my school
: (the IB program is advanced honors...kinda like AP, but a level higher),
: and I have decided on the topic:
: "The Effects of Cryptography in World War II"
: I have found a few good articles on the Enigma machine, but I am at a
: lack of books on the subject. Does anyone know of a good book that I
: can site for my essay? Also, any internet articles would be most
: apreciated.
There were a number of books at the time (1974) the information was first
made public.
Some of the first few books, though, contained some inaccuracies. For
example, the British had a very effective system of radio countermeasures
that usually caused the German bombers to drop their bombs in the wrong
places. When Coventry was bombed, however, it failed.
Since the codebreakers at Bletchley Park already knew enough secrets, they
weren't informed about this part of the secret war; hence, when the lid
first came off about Ultra, the rumour that Coventry was sacrificed to
protect Ultra came out.
One book specifically about the impact of the Enigma solutions on the war
is called "Ultra in the West", about its effect on the Normandy campaign
starting in 1944. Also, while David Kahn's book "The Codebreakers" was to
early to discuss Ultra, the later book "Kahn on Codes" included some
articles on the subject, and he also wrote "Seizing the Enigma",
specifically about Ultra and the Battle of the Atlantic against the
U-boats.
"Ultra Goes to War" by Ronald Lewin is another book to investigate.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Research paper...
Date: 10 Oct 99 01:01:47 GMT
Steven Alexander ([EMAIL PROTECTED]) wrote:
: check out J. Savard's page. The link is floating around sci.crypt
: somewhere.
http://www.ecn.ab.ca/~jsavard/crypto.htm
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Research paper...
Date: 10 Oct 99 01:08:16 GMT
Steven Alexander ([EMAIL PROTECTED]) wrote:
: check out J. Savard's page. The link is floating around sci.crypt
: somewhere.
But my page discusses the Enigma and its solution almost exclusively from
a _technical_ viewpoint. Other references will be required to investigate
how the Ultra solutions affected World War II.
John Savard
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: on linear keyspaces
Date: Sun, 10 Oct 1999 01:21:55 GMT
> Tom you still don't get it. Bad compression makes it easyer to break an
> encrypted message. You can't even prove that any of the AES candidates
> are safe from attacks less than a brute force seach. You seem to base
> everyting on that assumpution. The fact is you can't.
> But if one compresses it is foolish to give information to the attacker
> by using a compression routine that can only help the attacker and that
> is what most compression routines do. Why use one that aids the
> attacker by rulling out most of the keyspace independent of the data
> that was compressed.
> Thems the facts.
Ok first off stop trying to plug your really shitty software. This is a
scientific forum, not cheapo software. I plug peekboo once in a while, but
that's because it's a usefull program (using accepted ciphers and key
exchanges). Anyways...
Second should we just throw our hands up and say all crypto (including yours)
is useless because we can't prove it strong? Or should we rely on
cryptanalysis of ciphers to design strong ones? I mean CAST for example was
not thrown together, it's S-BOXES have strict rules for construction that
hinder known forms of analysis. This appears to be the best we can do.
Unlike your cipher which has no theory, it was simply thrown together.
Third you assume 'weak compression' has a good ratio (like DEFLATE). You say
things like the DEFLATE in PGP is weak because it's not one-to-one but you
have not proven so. Still yet you have not explained how having less entropy
per bit (like in your huffman code) is better then having more entropy per
bit (like in deflate). I don't get it. If each bit of the second is more
random then yours, would it not be harder to model?
I truly think you should answer my last question and stop just posting 'tom
you stupid kid'. Seems to me you can't answer it (just like my questions on
your block cipher).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
