Cryptography-Digest Digest #36, Volume #14 Thu, 29 Mar 01 11:13:01 EST
Contents:
Re: Breaking a DES encrypted code. (Frank Gerlach)
Re: Newbie wants to shuffle... ("Frog2000")
Re: Breaking a DES encrypted code. (William Hugh Murray)
Re: WinZip and other Zip Archivers ("Christian Schindler")
Re: Clarification about the Czech attack to PGP (John Savard)
Re: Breaking a DES encrypted code. (William Hugh Murray)
Re: Breaking a DES encrypted code. (William Hugh Murray)
Re: Idea - (LONG) (SCOTT19U.ZIP_GUY)
Re: Newbie wants to shuffle... (SCOTT19U.ZIP_GUY)
Re: WinZip and other Zip Archivers (William Hugh Murray)
Re: rc4 ("John L. Allen")
----------------------------------------------------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Breaking a DES encrypted code.
Date: Thu, 29 Mar 2001 16:44:51 +0200
Who knows what SETI@home *really* does ?
Mok-Kong Shen wrote:
> William Hugh Murray wrote:
> >
>
> > What is more, we use the otherwise unused cycles on the desktop. The
> > cost of these cycles approximates zero. That is to say, if we had not
> > used them for cryptanalysis, we would not have used them at all.
>
> Long time ago, I learned of projects to utilize the power
> of a network of computers left latent by the ones at the
> terminals. For most commercial firms, that power could
> be fairly substantial, expecially at night. Does anyone
> happen to know whether this is in vogue? (I don't mean
> projects of internet computing for factoring numbers, etc.)
>
> M. K. Shen
------------------------------
From: "Frog2000" <[EMAIL PROTECTED]>
Subject: Re: Newbie wants to shuffle...
Date: Thu, 29 Mar 2001 09:54:49 -0500
--
http://welcome.to/speechsystemsfortheblind
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> "SCOTT19U.ZIP_GUY" wrote:
> >
>
> > I know I am late in this thread. But shuffling is a lot
> > like creating a single cycle look up table. My code both
> > scott19u and scott16u have to use a large shuffling of the
> > file. If you want to check the method I used. You can look
> > at the source code.
>
> Sorry to say something that I hesitated very long to say.
> I was asking something about the math of proving that
> the two algorithms are equivalent. And you jumped in
> to praise the merit of your codes, which is not relevant
> to my question as such. From what I saw in other threads,
> you seem to be very diligent in making that publicity.
> Too much publicity could have a negative effect in my
> humble view. My apology for expressing my minds directly.
>
> M. K. Shen
I must apologize. 1st, I was a bit late, and must have missed something.
2nd, I obviously misunderstood something, or I wouldn't have bothered to
post a totally irrelevent piece of code.
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Breaking a DES encrypted code.
Date: Thu, 29 Mar 2001 14:57:12 GMT
Mok-Kong Shen wrote:
> William Hugh Murray wrote:
> >
> > John Savard wrote:
> >
>
> > > Either you know the original plaintext - a "known-plaintext" attack -
> > > or you have partial knowledge of it. For example, the plaintext might
> > > be uncompressed ASCII characters. In that case, have, say, seven
> > > blocks of ciphertext, and for each key, decrypt as many of them in
> > > turn as needed until you find the MSB of any byte equal to 1; if all
> > > are zero, you may have found the right key.
> >
> > Which is why it is bad practice to encrypt a message with a strong and obvious
> > patter like ascii characters. One should always hide any exploitable pattern in
> > the plaintext before encrypting it.
>
> On the other hand, to eliminate the patterns before
> encryption does involve cost. It seems to be the opinion
> of many that, if one has a sufficiently strong cipher,
> one needn't care that.
Enigma was, and is still, a strong cipher. What was exploited in Ultra was poor use
of the cipher. One specific use that was of aid in ultra was the encryption of
standard headers. It is not at all clear that strengthening Enigma would have raised
the cost of attack nearly so much as improving the way that it was used.
Of course, cost was the issue for the Germans. However, today we use very cheap
computer cycles to perform these tasks. Most implementations, for example, PGP and
S-MIME perform these operations. Most encryption of interest is done at the desktop
or the laptop using very low-cost cycles. It uses cycles that simply would have been
thrown away if not used for code conversion. Code conversion is what computing is all
about. If one is going to the trouble of converting from public codes to secret
codes, one might as well do it right in the first place. We spend more money making
the decision to encrypt than encryption costs us.
>
>
> M. K. Shen
------------------------------
From: "Christian Schindler" <[EMAIL PROTECTED]>
Subject: Re: WinZip and other Zip Archivers
Date: Thu, 29 Mar 2001 17:10:18 +0200
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]...
> Could you name one/some? (BTW, an archiver that has apparently
> quite nice functionalities and is free is Powerarchiver,
> though I know nothing about its crypto feature.)
Look at http://www.filzip.com oder http://www.filzip.de (If you are German!)
!
A great and free packer, which supports very much formats (.rar ; .ace ,
.zip ,.tar and many other Unix and Windows formats)
And it looks very similar to WinZip!!
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Clarification about the Czech attack to PGP
Date: Thu, 29 Mar 2001 14:56:47 GMT
On Thu, 29 Mar 2001 11:05:44 +0200, Volker Hetzer
<[EMAIL PROTECTED]> wrote, in part:
>Email encryption without network capabilities and for one user?
>So, it was envisioned that the typical user would send encrypted emails to himself
>on his local machine only?
Ideally, if one is really serious about security, one ought to run PGP
on a separate machine, and then use a floppy disk to carry the
encrypted files to your machine that is connected to the Internet, on
which you don't put any sensitive stuff that needs to be encrypted.
After all, computers connected to the Internet are not terribly
secure. Encryption, on the other hand, can achieve enormous levels of
security - so in this case, they're mostly going to waste.
Surely lots of us have an old 386 SX in the basement that can run PGP.
Well, at least the older versions. Red/black separation for the common
man.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Breaking a DES encrypted code.
Date: Thu, 29 Mar 2001 15:10:39 GMT
"Douglas A. Gwyn" wrote:
> William Hugh Murray wrote:
> > Which is why it is bad practice to reuse keys ...
>
> yada, yada -- it's not like the Germans had much choice.
Agreed. However, because we use automatic, rather than manual, key
management, we do have a choice.
> DES key *is* generally reused -- for subsequent blocks
> in the same session. Therefore even though it might
> appear that nothing was gained by cracking the first
> block using known plaintext, it is *only* for the first
> block that the plaintext needed to be known, and all the
> unknown plaintext later in the same session is the payoff
> for the attack.
Agreed. This is the reason why one uses an initialization vector when
using DES at the session layer.
The assumption has always been that getting known plaintext is a trivial
exercise. One need only dupe the adversary into sending a message that
one already knows under the key in question. However, in session layer
encryption this is usually difficult to do. In fact, it is so difficult
that if one enjoys the necessary privileges do it, one probably is
privileged to read the cleartext in the first place.
The residual risk, is why in its proposal for key management in
secureIP, IBM recommends a mode in which keys are changed (an arbitrary)
multiple of times in a session.
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Breaking a DES encrypted code.
Date: Thu, 29 Mar 2001 15:13:08 GMT
Mok-Kong Shen wrote:
> William Hugh Murray wrote:
> >
>
> > What is more, we use the otherwise unused cycles on the desktop. The
> > cost of these cycles approximates zero. That is to say, if we had not
> > used them for cryptanalysis, we would not have used them at all.
>
> Long time ago, I learned of projects to utilize the power
> of a network of computers left latent by the ones at the
> terminals. For most commercial firms, that power could
> be fairly substantial, expecially at night. Does anyone
> happen to know whether this is in vogue? (I don't mean
> projects of internet computing for factoring numbers, etc.)
>
> M. K. Shen
Well, it is certainly being used for SETI. Has been used for brute force
attacks against DES challenges. In order to paricipate, one need only click
on an icon or two. It is almost that simple.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Idea - (LONG)
Date: 29 Mar 2001 15:11:58 GMT
[EMAIL PROTECTED] (John A. Malley) wrote in
<[EMAIL PROTECTED]>:
>
>"SCOTT19U.ZIP_GUY" wrote:
>
>> So at the very least try to get Shannon
>> correct. In his defination of "Perfect encryption" where an enemy
>> gains no more knowledge about a possible message than he knew before
>> it was sent. The key should have at least as many possible values as
>> the number of possible messages.
>
>Shannon called this "perfect secrecy", achieved with the number of keys
>equal to the number of messages. For perfect secrecy, the probability
>that the plaintext = X given the ciphertext = Y is the same as the
>probability that the plaintext = X.
Your right. Going back to the Journal his
Communication Theory of Secrecy Systems
on P-659 use term "perfect secrecy" thanks for clarifying.
>
>Exactly as you said, the enemy gains no knowledge from the ciphertext
>intercepts.
>
>> In what Shannon refers to as an "ideal system" He goes on to state
>> that it is possible to construct encryption system where one only
>> has a finite number of keys. So that even with infinite amount of
>> cipher text. There still is not enough INFORMATION in the cipher
>> text to know what the solution is.
>
>According to Shannon's paper, in an ideal system the number of
>cryptograms, the number of messages and the number of keys are all
>equal (and finite.) Each key is equiprobable. No two keys ever map the
>same message to the same cryptogram - or stated another way, each
>message m_i is
>mapped to each cryptogram c_i by exactly one key.
>
>The amount of information in a message is at most log(n) where n is the
>number of possible messages. This information can be concealed
>completely only if the key uncertainty
>is at least log(n).
>
>Mr Scott is right, the key length does not need to be
>the same as the message length - the uncertainty of the key must be
>equal or greater than the uncertainty of the messages.
>
>Here's an interesting example of a perfect system per Shannon's
>definition where the key length in bits is shorter than some of the bit
>lengths of messages, and the perfect system is not an OTP:
>
>There are four messages in the set M = { m1, m2, m3 , m4 } and P(m1) =
>1/2, P(m2) = 1/4, P(m3) = P(m4) = 1/8 where P(m_i) means probability of
>occurrence of m_i.
>
>The uncertainty of M, H(M), is
>
>H(M) = - ( - 1/2 * 1 - 1/4 * 2 - 1/8 * 3 - 1/8 *3 ) = 1.75 bits.
>
>Encode the messages as these bit strings
>
>m1 = 0
>m2 = 10
>m3 = 110
>m4 = 111
>
>Perfect secrecy requires the uncertainty of the key be equal to or
>greater than the uncertainty of the messages - so we need a key 1.75
>bits or longer. Each key value must be equiprobable. That points to a
>2 bit key to encrypt this set of messages with perfect secrecy:
>
>k1 = 00 selects this mapping:
>
>m1 = 0 <-> c1 = 0
>m2 = 10 <-> c2 = 10
>m3 = 110 <-> c3 = 110
>m4 = 111 <-> c4 = 111
>
>k2 = 01 selects this mapping:
>
>m1 = 0 <-> c1 = 10
>m2 = 10 <-> c2 = 110
>m3 = 110 <-> c3 = 111
>m4 = 111 <-> c4 = 0
>
>k3 = 10 selects this mapping:
>
>m1 = 0 <-> c1 = 110
>m2 = 10 <-> c2 = 111
>m3 = 110 <-> c3 = 0
>m4 = 111 <-> c4 = 10
>
>k4 = 11 selects this mapping:
>
>m1 = 0 <-> c1 = 111
>m2 = 10 <-> c2 = 0
>m3 = 110 <-> c3 = 10
>m4 = 111 <-> c4 = 110
>
>
>Alice and Bob chose a secret key (00, 01, 10 or 11) and exchange it only
>between themselves.
>Alice and Bob send messages m1, m2, m3 and m4 to one another as
>ciphertext c1, c2, c3 and c4. They decode them according to the
>appropriate mapping as a function of the secret key value.
>
>Eve knows Alice and Bob exchange messages in the set M and she knows
>their relative frequencies (or a priori probabilities.) Eve intercepts
>ciphertexts c_i. What more can she learn about which messages m_i were
>sent given that intercepted ciphertext? Can she figure out if its more
>probable particular m_i was sent given she sees a particular c_j?
>
>The conditional probability that the m_i message was sent given the c_j
>ciphertext is seen is
>
>P( m_i | c_j ) = P( m_i ) * P( c_j | m_i ) / P( c_j ) = P( m_i ) when
>there is perfect secrecy.
>
>
>Let's calculate the probability the message is m1 given we see the
>ciphertext 10.
>
>The probability of seeing 10 in the ciphertext is
>
>P( k = 00 )*P( m2) + P( k = 01)*P(m1) + P( k = 10 )*P(m4) + P( k =
>11)*P(m3) =
>
>1/4 * 1/4 + 1/4 * 1/2 + 1/4 * 1/8 + 1/4 * 1/8 = 1/4.
>
>The probability of ciphertext 10 given message m1 is the probability of
>key k2 = 1/4.
>The probability of message m1 is 1/2.
>
>So P( m1 | 10 ) = ( 1/2 * 1/4 ) / 1/4 = 1/2 = P( m1).
>
>When Eve sees 01 she knows it has a 50% chance of corresponding to the
>plaintext message 0, 25% chance of corresponding to 10, 12.5% chance of
>corresponding to 110 and 12.5% chance of corresponding to 111. In fact,
>no matter what cryptograms she sees (00, 01, 10, 11) she only knows that
>each intercepted ciphertext has a 50% chance of corresponding to the
>plaintext message 0, 25% chance of corresponding to 10, 12.5% chance of
>corresponding to 110 and 12.5% chance of corresponding to 111.
>
>The ciphertext tells Eve nothing more than what she already knows - the
>relative frequencies of m1, m2, m3 and m4.
>
>This holds for other specific messages and specific cryptograms as well
>:
>
>P( m_i | c_j ) = P( m_i ) for all i, j for this example cipher.
>
>This cipher gives perfect secrecy with a 2 bit key even when some of the
>plaintext is 3 bits long and some of the plaintext is just 1 bit long.
>
>This perfect system is not an OTP. The mappings 00, 01, 10 and 11 are
>permutations on the message set M.
>
>
>Later in his paper, Shannon addresses infinite sources:
>
>"The situation is somewhat more complicated if the number of messages is
>infinite. Suppose, for example, that they are generated as infinite
>sequences of letters by a suitable Markov process. It is clear that no
>finite key will give perfect secrecy. We suppose, then, that the key
>source generates key in the same manner, that is, an infinite sequence
>of symbols. Suppose further that only a certain length of key L_k is
>needed to encipher and decipher a length L_m of message. Let the
>logarithm of the number of letters in the message alphabet be R_m and
>that for the key alphabet K_k. Then, for the finite case, it is evident
>that perfect secrecy requires
>
>R_m * L_m <= R_k * L_k .
>
>This type of perfect secrecy is realized by the Vernam system."
>
>- "Communications Theory of Secrecy Systems", Bell Systems Technical
>Journal, 1949, pp. 682.
>
>This is the ultimate source of the popular rule of thumb that the "key
>must be as long as the message."
>
>
>John A. Malley
>[EMAIL PROTECTED]
>
Thank you for the excerts from his paper. I still think its interesting
that in the 40's Shannon felt long keys were needed. Yet today in the
computer age. Most cyrpto systems limit there selves to very short keys.
At least in the public domain. I doubt the NSA for there own internal
secret encryption would so blatently violate Shannon's insights about
crypto.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Newbie wants to shuffle...
Date: 29 Mar 2001 15:16:31 GMT
[EMAIL PROTECTED] (Frog2000) wrote in <3ac34c6d$[EMAIL PROTECTED]>:
>>
>> Sorry to say something that I hesitated very long to say.
>> I was asking something about the math of proving that
>> the two algorithms are equivalent. And you jumped in
>> to praise the merit of your codes, which is not relevant
>> to my question as such. From what I saw in other threads,
>> you seem to be very diligent in making that publicity.
>> Too much publicity could have a negative effect in my
>> humble view. My apology for expressing my minds directly.
>>
>> M. K. Shen
>
>I must apologize. 1st, I was a bit late, and must have missed something.
>2nd, I obviously misunderstood something, or I wouldn't have bothered to
>post a totally irrelevent piece of code.
>
No need to apologize Moks insults and hate were directed at me
not you. We don't get along to well sorry you felt it was aimed
at you.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: WinZip and other Zip Archivers
Date: Thu, 29 Mar 2001 15:26:21 GMT
Moritz Voss wrote:
> These have a password function, as people might know.
This is far and away the preferred attack.
> Is the encryption anything close to "secure" or is this just some 'cheap',
> 'keep dummies out ofr a while' algorithm like just xoring a few plaintext
> characters...
The encryption is just barely strong enough to make an attack against the
password the preferred attack. Even if one does it wholesale, one would still
prefer the attack against the password. One can go through the entire English
language, several other languages, and three or sweet lists in minutes to
hours. This will open all but a vanishingly small number of files.
>
>
> --
> --
> Moritz "Thygrrr" Voss
> Client-Server & OpenGL Developer
> http://www.optionoverkill.com
------------------------------
From: "John L. Allen" <[EMAIL PROTECTED]>
Subject: Re: rc4
Date: Thu, 29 Mar 2001 15:07:09 GMT
Edmond Ho wrote:
> Could someone point me to an authentic version of RC4 C source code? I
> currently have two compiled versions that are imcompatible (ie, the
> ciphertext from one does not decrypt properly with the other). The source
> code that I currently have is from
> http://www.cypherspace.org/~adam/rsa/rc4c.html (the first one) and
> http://www.cypherspace.org/~adam/rsa/rc4.c. Thanks in advance.
They are both compatible for me. keep in mind that you have to pass in
the key as a valid hex string, eg., if the key is "foobar", you need to pass
666f6f626172.
I did find that the second version of rc4 in C on the rc4c.html page would
no longer produce valid results for me. Since I am partly responsible for
this code, I feel obliged to post a "fix". Here it is:
#define S,t=s[i],s[i]=s[j],s[j]=t /* rc4 key <file */
unsigned char s[256],i,j,t;main(c,v)char**v;{++v;while
(++i)s[i]=i;while(j+=s[i]+(*v)[i%strlen(*v)]S,++i);for
(j=0;c=~getchar();putchar(~c^s[t+=s[i]]))j+=s[++i]S;}
It's still pretty fragile C code though :-)
And note that the key here is passed as-is: "foobar", instead of in hex.
John.
------------------------------
** 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
******************************
