Cryptography-Digest Digest #607, Volume #10 Mon, 22 Nov 99 12:13:03 EST
Contents:
Re: AES cyphers leak information like sieves ("Douglas A. Gwyn")
Re: AES cyphers leak information like sieves ("Douglas A. Gwyn")
Re: Distribution of intelligence in the crypto field ("Douglas A. Gwyn")
Re: Nova program on cryptanalysis -- also cipher contest ("Douglas A. Gwyn")
Re: Crypto Stats for Other Languages ("Douglas A. Gwyn")
Re: RC4 in Kremlin US version 2.21 to tom st denis ("Douglas A. Gwyn")
How ScramDisk will recover >> My test in container file ... ([EMAIL PROTECTED])
Re: Filters, Superpositions and Entanglements ([EMAIL PROTECTED])
Secretly Obscured Subset ("Gary")
Re: AES cyphers leak information like sieves (Volker Hetzer)
Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: For all lions --- (CoyoteRed)
Re: The 1991 Soviet coup: the role of cryptanalysis (John Savard)
Re: AES cyphers leak information like sieves (Lincoln Yeoh)
Re: AES cyphers leak information like sieves (Lincoln Yeoh)
Re: Where's a good online discription of SHA1 or MD5? TIA (jerome)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Mon, 22 Nov 1999 09:31:33 GMT
Tim Tyler wrote:
> ... One-on-one means that there's a bijection between the input
> and output sets of the compressor.
No, we discussed this previously. That is what "one-to-one"
means, but not what "one-on-one" means. *Any* reversible
compression is "one-to-one", but D.Scott has something more
specific in mind.
> ... readers should note that, in many respects, the *primary*
> point of the property is that it hinders any cryptanalytic attacks
> based on regularities in the compressed files, ...
That has merely been asserted, not demonstrated.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Mon, 22 Nov 1999 09:38:09 GMT
Tim Tyler wrote:
> ... Since diffusion /could/ extend
> to the whole file, why not extend the diffusion to the whole file?
Ooh, another easy question!
Because many, perhaps most, applications of encryption are in
serial communication, where relatively small buffers (1K bits
or so) are tolerable, but not buffers equal to the entire size
of the communication.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Distribution of intelligence in the crypto field
Date: Mon, 22 Nov 1999 09:58:41 GMT
Jim Dunnett wrote:
> Most intelligence comes from more-or-less open sources. I'd wager
> very little indeed comes from cryptanalysis. Pure cryptanalysis,
> that is.
Intelligence is gathered from *many* sources. "Open source" is used
more to provide context than as reliable information in itself.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Nova program on cryptanalysis -- also cipher contest
Date: Mon, 22 Nov 1999 10:06:48 GMT
Sundial Services wrote:
> ... BE WA RE IC EW EA SE LS ...
To be fair, it could instead be .B EW AR EI CE WE AS EL S.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Crypto Stats for Other Languages
Date: Mon, 22 Nov 1999 10:11:14 GMT
"@li" wrote:
> I was wondering where I might look to find statistical data about
> languages other than English. It seems that only english (or at
> least latin) character sets are analyzed. How about languages
> such as hebrew and arabic?
The simple answer is, computers make it almost trivial to compute
the statistics yourself from a large representative sample of
plaintext. Better yet, use the sample to train a HMM.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: RC4 in Kremlin US version 2.21 to tom st denis
Date: Mon, 22 Nov 1999 10:18:05 GMT
Xcott Craver wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > SEAL, RC4, WAKE are all PRNGs where the output is xored with
> > plaintext/ciphertext.
> Even so, this doesn't make all stream ciphers prngs.
> There's no reason why a stream cipher must be restricted in
> this way in order to be a stream cipher.
Indeed, really good stream ciphers do *not* have that property,
because it provides too many opportunities for cryptanalysis.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,comp.security.pgp.tech
Subject: How ScramDisk will recover >> My test in container file ...
Date: Mon, 22 Nov 1999 05:31:22 -0500
How Scramdisk will recover from say :
PC power down with file/s open in container >> power down with container mounted
+ open files in container ?
How 1 bit / 1 byte corruption in container file will affect container >> can
container be mounted / used ?
What is the smallest damage in container that will make container useless [
container can not be mounted = password not accepted ] ?
How change of 1 bit / 1 byte in container file will affect container ability to
mount / accept password ?
How to make sure that container file, say 640 MB will not create any reliability
problems ? >> the conventional drive of this capacity, 640 MB can have say 5,000
files, when 1 file of this 5,000 files will be totally corrupted the rest of the
storage will be very likely not corrupted. How this scenario apply to container
file of 5,000 files in 640 MB ?
How corruption of 1 in 5,000 files in container will render mounting possibility
of this 640 MB od disk space ?
My test in container file, by corrupting 1 byte of random data made my container
USELESS [ could not mount it + did not recognized password ] >> this makes
reliability of container very controversial issue >> corrupting 1 byte affected
640 MB of disk space !!!
The above ratio will theoretically render ScramDisk as useless software, base on
immunity to withstand any data corruption. I see the problem in inability to
MOUNT container, which lead to ALL CONTAINER disk space lost.
--
Thanks, Richard
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Filters, Superpositions and Entanglements
Date: Mon, 22 Nov 1999 12:02:10 GMT
In article <%G_Z3.307$[EMAIL PROTECTED]>,
"karl malbrain" <[EMAIL PROTECTED]> wrote:
>
> <[EMAIL PROTECTED]> wrote in message
news:81950k$ak5$[EMAIL PROTECTED]...
> > Superpositions are not necessarily entanglements.
> >
> > A superposition is what happens at a beam splitter.
> > An entanglement is what happens in a non-linear crystal.
>
> GROUNDS are not active equalizers. THEORETICALLY, you don't need them
in
> communications nor do you need them in energy distribution. However,
> PRACTICALLY, without a ZERO in a communications circuit, eventually
you
> can't distinguish noise from signal, and in the energy distribution
grid you
> need an ABSOLUTE as a safety or security hook-up POINT. When the two
> inter-twine, you get a BRISBANE/SAN MATEO type of result. Karl M
>
What is brisbane/san mateo about ?
Even a pure noise signal is distinguished from
non-noise. That's a sort of paradox making noise
somewhat predictable.
Very similar to a space-heater
which uses a large resistance, rather than a more
_informative_ circuit; it, the heater, provides only the
singular distinction of hot and cold.
Is the ground acting in this manner ?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Secretly Obscured Subset
Date: Mon, 22 Nov 1999 12:53:07 -0000
This public key system relies on a publisher's knowledge of a secret small
subset of very large numbers, with the public using a function generated by
the publisher on the set of all of the very large numbers as a gateway to
the secret set.
Entity 'A' creates a function F mapping 2^N, N bit numbers INTO 2^(N/K), N
bit numbers (K>1). For example with N=160, K=8. All 160 bit numbers are
mapped into a subset with only 2^20 elements. The function is disguised so
that only 'A' knows every element in the small subset. 'A' publishes the
function.
Entity 'B' on receiving the function generates a random N bit number R and
uses the function on it to create R'=F(R). R' will be the secret session key
he wishes to share with 'A'. 'B' one way hashes R' to produce R''=H(R'), and
sends this hash to 'A'.
Since 'A' knows all the one way hashes of the small subset, he can easily
find the R' that hashes to R'', and thus shares the secret R'. For example
with N=160 and K=8, 'A' needs only to search 2^20 hashes.
Choice of the function is difficult, especially if it is to be efficient.
The security of the function is unusual in that we wish the public to go
through all 2^N elements to gain knowledge of the secret subset.
Underlyingly dense (>=1) Knapsack ciphers seem a good choice, but are they?
Are there any systems similar to this?
Gary.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Mon, 22 Nov 1999 14:01:07 +0100
Tim Tyler wrote:
> David's supposed lack of admireres on this newsgroup appears to me to
> have a number of causes:
>
> * He holds extreme views, which don't seem to me to be at all wrong, but
> seem to clash somewhat with much modern orthodoxy.
Like that the NSA has broken PGP?
>
> * He's not terribly articulate - and is more interested in pursuing
> technical goals, than he is on brushing up on his presentation.
To me he gave the impression that he tries to push his encryption stuff
on us at all cost. His favourite argument is to claim that everything
else is garbage. However, he can't prove it.
> As a result, strangers tend to treat him as though his spelling reflects
> his IQ - definitely a mistake, partly because...
I disagree.
>
> * He has a short fuse,
True.
> doesn't tolerate fools gladly,
I don't know about this, but he certainly doesn't tolerate people gladly
that ask him to prove his claims.
> and quickly stoops to telling them where to go.
As a compromise I'd like to attribute this to his laziness when it comes
to explaining his views.
> /Sometimes/ it seem to me that this trait
> extends to telling innocent bystanders where to go, while there's still
> a chance that the disagreement stems from some sort of ambiguity or
> misunderstanding ;-/
Uusually it stems from the fact that serious people don't believe his
claims without some evidence ther than almighty NSA being able to read anything.
Ambiguity has nothing to do with it.
>
> I wish David could curb this trait a little - but to a certain extent I
> understand and even sympathise. Life is short.
So, if he wants us to believe something he says he should stop behaving the way
he does. Because otherwise he will waste a lot of time before he converts
a significant number of people to his views.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES cyphers leak information like sieves
Date: Mon, 22 Nov 1999 14:34:06 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>[ ... ]
>
>> I agree that error recovery is not present in CFB. However it is not
>> clear to me that this implies that very much diffusion of information
>> is going on.
>
>It's irrelevant -- if you look back at the comments to which I was
>replying (the ones David Scott made) they were not directed at the
>diffusion or lack thereof: his comments were aimed specifically at
>showing that the error recovery capability in CBC isn't useful.
>
>His attempt in this direction was fatally flawed in at least two
>obvious ways. First his example was unrelated, second the conclusion
>he drew from his example would have been wrong even if the example
>itself had been correct.
>
The point I have been trying to make which you don't seem to
want to look at. Is that all the 3 letter chaining modes suffer from the
same problem. That is that the information of the plain text is not spread
through the file. If you take you favorite block cipher and encyrpt a
message and reverse that message and use a second or same block
cipher with another key and then chainge a bytes in the middle of the
file. Your can recover all but that area where the mode is. This shows
that the information is not spread through the file. I don't like the term
error recovery for any of these moses. I suspect the term is really
only used to make people comfortable about the weak chaining.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Mon, 22 Nov 1999 14:42:09 GMT
In article <819tco$r03$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> Um, maybe Tim wasn't talking about single blocks?!
>>
>> If you have a suitable quantity of known-partial plaintext - and a
>> known-plaintext attack on the cypher - you can break the cypher using
>> that, recover the key, and then decrypt the rest of the message that
>> was previously unknown to you.
>>
>> This can happen for a string of blocks of any length.
>>
>> You *might* hold the position that there's no theoretical known-
>plaintext
>> attack on modern block cyphers that works any better than brute
>force -
>> but this notion is a theoretical ideal, not known to be attained
>in /any/
>> practical system.
>>
>> If you want to depend on this vagueness, then that's up to you.
>> Personally I'd rather defend against such attacks.
>
>3 x 2^51, 2^53, 2^47, what do those numbers represent? If you can't
>even guess I am wasting my time.
>
>> If you don't believe this, try David's often-explained experiment:
>> Chop off both ends of the encrypted file, decrypt with the /right/
>> key, but the /wrong/ IV and watch (most of) the plaintext flood out.
>
>In CBC if you have the IV wrong you can't decrypt it right... think
>about it...
>
>P = Dk(C) xor IV
>
>if the IV is wrong, so is the P value. Your argument is flawed.
>
Tom why do you act so stupid. Just try the dam example.
Encrypt several blocks in a file using an IV of your choice.
Then decrypt with a different IV and look at the files in hex.
I get tired of telling you this. Since you seem to stuipd to
even test it out. Yeah stupid the first block is wrong when
you decrypt but look at the whole file asshole.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Mon, 22 Nov 1999 14:48:56 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
...
>Actually it's right, and it's nothing new.
>CBC mode isn't p=D(c) xor IV, it's:
>p =D(c) xor c-1, where c-1 is the previous ciphertext block.
>
>While each ciphertext block does depend on the IV, you only need one
>previous ciphertext block to decrypt. This isn't a weakness of CBC
Look that is the party line. How can you say that it is not a weakness
just becasue that is what you have been lead to belive.
>mode, it's designed so that two different messages don't encrypt to
>the same ciphertext, and they won't. It also reduces patterning, in
>that identical blocks within the plaintext will encrypt to different
>values.
But it is designed to do that with the property that if there
is an error in a byte in the middle of the file that error will
not effect all the trailing blocks. Think about it. When one
crates a block cipher they try to make avalanche and diffusion
of the information through out the whole block. And they try
to make block size larger to spread this effect out. Then
thye use chaining to prevent the spread through the rest
of the file..
>
>So the main strength of CBC is to thwart the use of multiple
>ciphertext messages to assist in breaking messages encrypted with the
>same key, and it does this.
>
I disagree!!
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: For all lions ---
Date: Mon, 22 Nov 1999 13:57:12 GMT
Reply-To: this news group unless otherwise instructed!
"mycroft" <ask me and I will email it to you> said...
> ps.pgp is not bad because it is free.
> it is bad because it is only
> Pretty Good Privacy.
> -m
So you are saying that PGP is bad crypto?
You seem to be implying that there are hacker groups that are
routinely breaking know crypto schemes, including PGP.
I would like to know more.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The 1991 Soviet coup: the role of cryptanalysis
Date: Mon, 22 Nov 1999 14:20:27 GMT
On Mon, 22 Nov 1999 04:25:21 -0500 (EST), Mark Adkins
<[EMAIL PROTECTED]> wrote:
>Does anyone know if the Soviet Union even used this method
>(secretaries making up their own numbers on typewriters) to
>create one-time pad keys, much less as late as 1991?
Yes: this is noted in "The Codebreakers" from David Kahn, and it has
been noted again in the recently declassified material concerning
VENONA. They have used that method.
Whether or not it continued into 1991, and whether or not that level
of imperfection in a one-time pad is sufficient for more than the most
limited cryptanalytic breaks, are things I do not know.
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: AES cyphers leak information like sieves
Date: Mon, 22 Nov 1999 14:59:20 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 20 Nov 1999 21:50:34 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>However - notoriously - business is war. Consequently jamming
>or otherwise interfering with transmissions need not be confined
>to out-and-out military situations.
Nah, business is not war, it's a sport maybe brutal but still a sport. If
your competitors are jamming your communications you can usually sic your
lawyers at em.
>Robustness in the face of errors /can/ be important sometimes - but
>there are other ways of dealing with it outisde the later of
>cryptography employed, that it seems to me are satisfactory in
>the vast majority of cases.
Yep. I believe in keeping the two functions separate as far as possible.
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: AES cyphers leak information like sieves
Date: Mon, 22 Nov 1999 15:27:00 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 20 Nov 1999 15:05:38 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>: "SCOTT19U.ZIP_GUY" wrote:
>
>:> Try looking at what happens when you make a minor change in
>:> the encrypted file. Then the plain text comes back with only
>:> a few blocks wrong in the are of the change. This means that
>:> the data is not distribluted through out the file. The encrypted
>:> file is what the attacker looks out or haven't you figured that
>:> part out yet
>
>: The lost chunk of PT is never recovered in your scenario.
>
>You're saying David's experiment *fails*?
>
>Why don't you try it?
The thing is, for a proper implementation of a CBC block cipher if you
encrypt the exact same plaintext you are supposed to get a very different
ciphertext.
So there really isn't a problem.
And if you send a "map" as in a previous example, the attacker won't be
able to tell if you changed a single spot or you sent exactly the same map
again.
That's correct right?
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Where's a good online discription of SHA1 or MD5? TIA
Reply-To: [EMAIL PROTECTED]
Date: Mon, 22 Nov 1999 15:27:30 GMT
md5 is in rfc1321 (www.ietf.org)
sha1 is in fips180-1 (www.nist.gov)
On Fri, 19 Nov 1999 15:30:20 GMT, CoyoteRed wrote:
>
>--
>CoyoteRed
>CoyoteRed <at> bigfoot <dot> com
>http://go.to/CoyoteRed
>PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
>
------------------------------
** 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
******************************
