Cryptography-Digest Digest #61, Volume #14 Mon, 2 Apr 01 12:13:01 EDT
Contents:
Re: Avoiding bogus encryption products: Snake Oil FAQ ("Henrick Hellstr�m")
Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K Kohler?)
(those who know me have no need of my name)
Re: AES VS. DES ("Latyr Jean-Luc FAYE")
GCHQ turned me away...(we didn't think they understood) (Keill Randor)
Re: Diceware Passwords ("Brian Hetrick")
Re: GCHQ turned me away...(we didn't think they understood) (John Savard)
Re: WinZip and other Zip Archivers (Philipp Engel)
Re: Data dependent arcfour via sbox feedback (John Savard)
Re: Data dependent arcfour via sbox feedback (John Savard)
Re: AES VS. DES (John Savard)
Re: dumb question 47 ("Bas Bloemsaat")
Re: AES VS. DES (Paul Schlyter)
Re: AES VS. DES ("Brian Gladman")
Re: Idea - (LONG) (Mok-Kong Shen)
Re: Data dependent arcfour via sbox feedback (Mok-Kong Shen)
How to do RSA Problem to avoid exponentiation overthrow? ("Raymond Lee")
unicity distance of DES ("Raymond Lee")
Chosen Plain Text Attacks in DES ("Raymond Lee")
----------------------------------------------------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Avoiding bogus encryption products: Snake Oil FAQ
Date: Mon, 2 Apr 2001 13:05:58 +0200
"C Matthew Curtin" <[EMAIL PROTECTED]> skrev i meddelandet
news:9a939m$1kc$[EMAIL PROTECTED]...
> URL: http://www.interhack.net/people/cmcurtin/snake-oil-faq.html
> So, most cryptographic software will convert a passphrase into a key
through
> a process called ``hashing'' or ``key initialization.'' Avoid
cryptosystems
> that skip this phase by using a password directly as a key.
This doesn't make sense. If the attacker knows the method of key
initialization, the hash function will normally not add any entropy
whatsoever, but only (a) increase the effort of a brute force attack on the
password by a linear factor since each guess has to be hashed, and (b)
possibly be necessary to make the key fit a legal key size. It is also
possible that the key set up scheme of the cipher makes it extremely
vulnerable to differential analysis, meaning that it is easier to extract
the key from known plain text than to guess and hash passwords. But such a
cipher should, for obvious reasons, not be used. Hence, hashing passwords as
part of the key initialization process _does not_ make each key equally
probable and does normally not increase security. On the contrary, such a
claim is a snake-oil warning sign.
However, passwords should always be one-way transformed before they are
stored externally, but that's another issue.
[snip]
> It's important to understand the difference between a new cipher and a new
> product. Engaging in the practice of developing ciphers and cryptographic
> products is a fine thing to do. However, to do both at the same time is
> foolish. Many snake oil vendors brag about how they do this, despite the
> lack of wisdom in such activity.
I see the point, but on the other hand I guess that a significant portion of
the cryptographers who once developed reputable ciphers were at the time
employed by a commersial company. Should we not trust RC4, IDEA etc?
The problem is not that people do too many things, but that they don't do it
good. The recommendation ought to be: Don't trust a cipher unless you are an
experienced cryptographer or you know for sure that a majority of
experienced cryptographers trust it. Period.
[snip]
> There are no restrictions on importing crypto products into the US, so a
> non-US vendor can legally offer a single, secure version of a product for
> the entire world.
Not necessarily. A non-US vendor might offer a product that makes use of
technology patented in the US, but refuse to pay the license fee. In such
case the US version of the software might be crippled to make it legal in
the US.
[snip]
> Beware of products that are designed for a specific task, such as data
> archiving, and have encryption as an additional feature. Typically, it's
> better to use an encryption utility for encryption, rather than some tool
> designed for another purpose that adds encryption as an afterthought.
Perhaps, but doesn't this exclude the PGP and SSH commersial products that
add a lot of non-cryptographic functionality? Typically, contemporary
security products are designed for a specific task other than just
encryption, because no ordinary user is prepared to interact directly with a
raw encryption utility. (So the user has be beware of _any_ security
product, yes, that's true of course.)
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K
Kohler?)
Date: Mon, 02 Apr 2001 11:50:43 -0000
[froups trimmed]
<[EMAIL PROTECTED]> divulged:
>I would also prefer Latex syntax. However, the standard
>group has chosen another approach. Now, one is likely
>to have a browser to process mathml. But not everyone
>is likely to take the trouble to install a Latex system.
"a standards group" -- you mean the one that is concerned with the www?
it's certainly not paying any attention to netnews. they defined a
couple of methods, and a few rules, and that's it.
almost anyone should be able to read the latex markup. trying to follow
mathml is a pita, i.e., a "browser" would be virtually required. and at
times the environment needed for a browser capable of groking mathml
might not be readily available, e.g., when reading news over low speed
lines just waiting for all the markup, much less the rendering, makes
using netnews more painful, and that's not such a good thing.
--
okay, have a sig then
------------------------------
From: "Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
Date: Mon, 2 Apr 2001 14:11:35 +0100
>> Latyr Jean-Luc FAYE wrote:
> > The first time, I got a nice answer of someone on the NG with a link
> > to his page about AES and I learnt lot of stuff.
>Benjamin Goldberg wrote :
> Perhaps John Savard's crypto site?
> http://home.ecn.ab.ca/~jsavard/crypto.htm
> To go directly to his rijndael page, use this url
> http://home.ecn.ab.ca/~jsavard/crypto/co040801.htm
> If it isn't one of the ones I gave, then try using a search engine.
Thanks a lot it was this one (John Savard's Crypto site) !!!
Regards
Latyr
--
Latyr Jean-Luc FAYE
http://faye.cjb.net
------------------------------
From: Keill Randor <[EMAIL PROTECTED]>
Subject: GCHQ turned me away...(we didn't think they understood)
Date: Mon, 02 Apr 2001 12:35:15 +0000
My encryption system was not offered to them simply because we thought they could use
it. (Which is what they assume).
It was offered to them to stop anyone else from using it. (Against them)....
(If they think they can beat it, then so be it - but my friend and I know otherwise -
He's got the program (better than what I told them), so he KNOWS how good it is.....).
If they want to see my friends PROGRAM, (not just my system), in the public domain,
then they've gone the right way about it............
As I said, it was a test - and they FAILED.........
Keill Randor
[EMAIL PROTECTED]
_______________________________________________
Submitted via WebNewsReader of http://www.interbulletin.com
------------------------------
From: "Brian Hetrick" <[EMAIL PROTECTED]>
Subject: Re: Diceware Passwords
Date: Mon, 2 Apr 2001 09:29:48 -0400
"Marc" <[EMAIL PROTECTED]> wrote...
> Imagine that the words on the list have 8 bits of entropy on
> average, viewed under the established common opinion that english
> words have only 1-2 bits per letter and that the list is compiled
> from short english words.
Because the Diceware password is not English, although it uses English
words. English _text_ has a certain number of bits of entropy -- the
trick with Diceware is that "bleat," "cackle," "icon," "june," and
"sulky," for example, all have the _same_ probability of occurrence
in a passphrase. This is not true of English text. Much of the
redundancy in English comes from the linguistic context. In the
phrase "I have a Dilbert ca," for example, the next few letters are
almost certainly "lendar." In the Diceware phrase "uncle gem p,"
however, there are 436 ways the next few letters can go, all equally
likely.
It is not that English words have 1-2 bits of entropy per letter. It
is that the English _language_ has 1-2 bits of entropy let letter.
See also http://www.geocities.com/tnotary/spcphrase.html.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: GCHQ turned me away...(we didn't think they understood)
Date: Mon, 02 Apr 2001 13:37:13 GMT
On Mon, 02 Apr 2001 12:35:15 +0000, Keill Randor
<[EMAIL PROTECTED]> wrote, in part:
>It was offered to them to stop anyone else from using it. (Against them)....
>If they want to see my friends PROGRAM, (not just my system), in the public domain,
>then they've gone the right way about it............
>As I said, it was a test - and they FAILED.........
Ah, well, they didn't fail too badly. You see, there are already
plenty of pretty much unbreakable codes out there. As far as
secret-key cryptography is concerned, making a system complicated
enough to be truly unbreakable is trivial (although it's funny that
almost no one really wants to bother).
Now, if you had come up with a way to improve the sorry state of
public-key cryptography (that's an unfair way to say it: it's a
miracle the thing can even be done at all, and by using larger primes
and the like, one can improve security a bit) that would be exciting.
Anyhow, although there are those who think program code is the big
thing, a clear explanation of the system is more useful - and many
people can write code.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Philipp Engel <[EMAIL PROTECTED]>
Subject: Re: WinZip and other Zip Archivers
Date: Wed, 28 Mar 2001 15:47:41 +0200
Hi everyone,
I'm the author of FilZip (http://www.filzip.com)
> Zip encryption is week (although it's better than just xoring)
> there is known plaintext attack that requires only known 13 bytes
> and then it can be broken in few hours
>
> but there are some other archivers that use better crypto
Which encryption method would you prefer? I'm thinking about including
some stronger encryption to secure zip files. What do you think about a
pgp plugin?
Philipp
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 14:00:32 GMT
On 1 Apr 2001 15:45:16 -0700, [EMAIL PROTECTED] (Gregory G Rose) wrote,
in part:
>CBC (Cipher Block
>Chaining) is nothing like a stream cipher.
It isn't one of those stream ciphers where the plaintext is XORed with
the output of a PRNG, no.
But any cipher where the encipherment changes from one part of the
message to the next is a stream cipher. So a rotor machine produces a
stream cipher, even though instead of (like a Hagelin machine)
producing merely successive displacements of the alphabet, it actually
produces different scramblings of the alphabet. Thus, CBC _is_ a
stream cipher, although what it produces is different scramblings of
whole blocks from one block to the next.
You have just inspired me to suggest a Triple-DES mode that is
*really* stream-cipher like.
Plaintext
| |
| |
--------- ---------
| DES1 | | DES1 |
--------- ---------
| |
------>XOR -------->XOR
| | | |
| --------- --------- ---------
| | DES2 | | DES3 | | DES2 |
| --------- --------- ---------
| | | |
- |---------- |-------
| |
Ciphertext
Of course, with an enormous (2^32 blocks, birthday paradox) amount of
known plaintext, one finds two equal ciphertext blocks, and then one
can do a meet-in-the-middle attack on the blocks which follow them.
(test for E(P1,K1) xor E(P2,K1) = D(C1,K2) xor D(C2,K2), since the XOR
quantity in the middle is equal for both) So, although this seems
nice, it's actually weak.
The problem is that the XOR quantity in the middle is partly known: it
is known when two blocks have the same quantity.
To solve this, and retain good error propagation, just XOR the input
(or output) of DES3 with the output of a good PRNG. Doing the same
with the input to DES1 and the output of DES2 increases the kinds of
substitutions that the cipher can generate, and is the next possible
improvement.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 14:09:50 GMT
On Mon, 02 Apr 2001 06:34:44 GMT, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote, in part:
>The patent does not apply to the proposed cipher, but for an entirely
>different reason than the one Bryan Olson claimed.
>
>The proposed variant combines one single input stream of data with the
>internal state of a cryptographic object, and produces as output one
>single stream of data (and modifies the object's state).
>
>The Dynamic Substitution patent covers combining two input streams with
>each other and with the state of a cryptographic object, and producing
>one single output stream (and modifying the object's state).
>
>The difference between the proposal and the patent is the number of
>input streams, one versus two.
>
>Here's the proposed modified RC4:
>
>byte x, y, z, sbox[256];
>encipher(byte data) {
> x = (x + 1) & 255;
> y = (y + sbox[x]) & 255;
> swap( sbox[x], sbox[y] );
> data ^= sbox[(sbox[x] + sbox[y]) & 255] ^ z;
> z ^= sbox[data];
> return data;
>}
The first three lines implement the RC4 PRNG or something like it.
Data is now being XORed, not only with the quantity produced by the
RC4 PRNG, but with z, which is the previous ciphertext, substituted
for in the S-box.
So what we have is a straightforwards autokey. It does indeed lack the
principal innovation of Terry Ritter's Dynamic Substitution.
That would have been: swap( sbox[...], sbox[data] ). One is simply
using the modified S-box to carry out a conventional autokey, one is
not modifying the S-box based on a plaintext or ciphertext related
quantity. However, that means it isn't a "data dependent arcfour" as
billed.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES VS. DES
Date: Mon, 02 Apr 2001 14:11:04 GMT
On Sun, 1 Apr 2001 08:22:12 +0100, "Latyr Jean-Luc FAYE"
<[EMAIL PROTECTED]> wrote, in part:
>The first time, I got a nice answer of someone on the NG with a link to his
>page about AES and I learnt lot of stuff.
Was that me?
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Bas Bloemsaat" <[EMAIL PROTECTED]>
Subject: Re: dumb question 47
Date: Mon, 2 Apr 2001 16:44:39 +0200
> I'm guessing that if the machine is intel running
> linux, you can't tie it to a specific machine ?
> (without a dongle)
Why not? There are lots of unique numbers in an intel machine:
- harddisks all have a serial number
- mac addresses of network cards
- bios serial number
This is why I couldn't understand all the fuss about the serialnr in the
pentium 3. The numbers above are all unique, and the combination even more
so.
"Yechuri" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What's a free way to protect software on say a Sun
> Sparc running either solaris or linux, using both
> RSA and the hostid of the processor.
>
> I'm guessing that if the machine is intel running
> linux, you can't tie it to a specific machine ?
> (without a dongle)
>
> Also, is RSA really free to use i.e. I heard the patent
> expired but is there any fine print about what you
> can't do with the algorithm
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: AES VS. DES
Date: 2 Apr 2001 16:30:51 +0200
In article <HGXx6.5181$I5.10267@stones>,
Brian Gladman <[EMAIL PROTECTED]> wrote:
> "Pascal Junod" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>> On Sun, 1 Apr 2001, Brian Gladman wrote:
>>
>> [snip]
>>
>>> DES is still a very good cipher that has not been broken but increases
>>> in ... [snip]
>>
>> Do you ever read about linear cryptanalysis, differential cryptanalysis ?
> > I'm not quite sure one can claim that DES is "unbroken"...
>
> The issue here is one of definition.
>
> In principle all keyed block ciphers can be attacked by undertaking an
> exhaustive search of their key space so it makes limited sense to claim that
> an algorithm is broken if it is vulnerable to this form of attack.
>
> But I agree that you can choose to use this as your definition of 'broken'
> if you so wish.
>
> But I choose a different definition - namely that an algorithm is broken if
> it is possible, on average, to recover the plaintext without the key with
> significantly less effort than would be expected in a brute force key
> search.
>
> And it in this sense that I claim that DES is unbroken.
By that definition, a simple XOR cipher where each byte of the
plaintext is XOR'ed with one constant value - the 1-byte key - isn't
"broken" either, since the fastest way to break it is to do an
exhaustive search of the 256 possible different keys....
If an exhaustive key search is computationally feasible, then the
cipher has too small a key space, and is broken becuase of that.
1-DES is on the limit of being broken in this respect: while an
exhaustive key search within a reasonable time is possible, it
requires a lot of resources. The fix (for now at least) is to use
3-DES instead.
Therefore a (symmetric) cipher isn't broken if both these conditions
apply:
1. The key space is large enough to make exhaustive search
computationally infeasible within a reasonable amount of time.
2. No other method is known which breaks the cipher significantly
faster than an exhaustive key search.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
Date: Mon, 2 Apr 2001 16:54:02 +0100
"Paul Schlyter" <[EMAIL PROTECTED]> wrote in message
news:9aa2er$ojh$[EMAIL PROTECTED]...
> In article <HGXx6.5181$I5.10267@stones>,
> Brian Gladman <[EMAIL PROTECTED]> wrote:
> > "Pascal Junod" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> >> On Sun, 1 Apr 2001, Brian Gladman wrote:
> >>
[snip]
> > And it in this sense that I claim that DES is unbroken.
>
> By that definition, a simple XOR cipher where each byte of the
> plaintext is XOR'ed with one constant value - the 1-byte key - isn't
> "broken" either, since the fastest way to break it is to do an
> exhaustive search of the 256 possible different keys....
agreed.
> If an exhaustive key search is computationally feasible, then the
> cipher has too small a key space, and is broken becuase of that.
> 1-DES is on the limit of being broken in this respect: while an
> exhaustive key search within a reasonable time is possible, it
> requires a lot of resources. The fix (for now at least) is to use
> 3-DES instead.
>
> Therefore a (symmetric) cipher isn't broken if both these conditions
> apply:
>
> 1. The key space is large enough to make exhaustive search
> computationally infeasible within a reasonable amount of time.
As I said in my previous post, you can choose this as part of your
definition of 'broken' if you wish.
But I use a different definition of the term.
Brian Gladman
>
> 2. No other method is known which breaks the cipher significantly
> faster than an exhaustive key search.
>
> --
> ----------------------------------------------------------------
> Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
> Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
> e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
> WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Mon, 02 Apr 2001 17:46:10 +0200
Nicol So wrote:
>
> It's actually quite simple. Consider a source that outputs a sequence of
> 8-bit characters of even parity. Now a message of N characters consists
> of N*8 bits, but the amount of entropy needed to transmit the message
> with perfect secrecy is only N*7 bits. You don't need to expend 8 bits
> of shared randomness to perfectly mask a plaintext symbol--you can use
> an random even-parity character with only 7 bits of randomness.
>
> The point is: source characteristics affect the amount of key entropy
> required for perfect secrecy.
Suppose a message has some standard header, say, the name
of the sending and receiving station, the time, etc. that
need not be concealed to the opponent (he knows it anyway),
then one could but obviously need not encrypt the header
part with any entropy. One can presumably come up with
a large number of such special cases. On the other hand,
if the opponent knows in your example that the leading bit
of a byte is always zero, then expensing entropy to encrypt
that bit is always a waste. But how about the case where he
doesn't have that knowledge? Does it help anything in
security? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 17:59:27 +0200
Terry Ritter wrote:
>
> I claim as my invention:
>
> 1. A mechanism for combining a first data source and a second data
> source into result data, including:
>
> (a) substitution means for translating values from said first
> data source into said result data or substitute values, and
>
> (b) change means, at least responsive to some aspect of said
> second data source, for permuting or re-arranging a plurality of the
> translations or substitute values within said substitution means,
> potentially after every substitution operation.
> "
>
> Notice the absence of the term "encryption method." All that is
> necessary for this patent to apply is that the stated things exist in
> the relationship described in at least one claim. And it doesn't
> matter how much other stuff is around.
>
> This is a "mechanism" -- a machine claim. The patent covers the
> described machine, wherever it exists, as hardware or software or any
> other implementation technology. That is quite similar to many other
> patents for digital logic systems.
The problem with at least non-professinals of patents is,
I believe, that such a claim like the above is so general
that it appears to cover even stuffs like DES. Could
someone explain why DES is NOT covered by that claim?
Thanks.
M. K. Shen
------------------------------
From: "Raymond Lee" <[EMAIL PROTECTED]>
Subject: How to do RSA Problem to avoid exponentiation overthrow?
Date: Mon, 02 Apr 2001 16:02:44 GMT
I have a simple RSA problem that I couldn't figure out
Give p=29, q=53, e=103, plaintext M=199 in the RSA algorithm, calculate d,
and the ciphertext C.
Here's my calculations:
n = p*q = 1537
(p-1)*(q-1) = 1456
103d = 1 mod 1456
I figure out d=311 by writing a program
C=M^e mod n
= 199^103 mod 1537
=634
to double check the answer, I put C=634 to find M, to see if M=199
M=C^d mod n
= 634^311 mod 1537
= 1178, not 634
please tell me which part I go wrong, I really appreciate your help, I guess
I ran overthrow in the calculations.
Please tell me how to do this problem correctly, please let me know.
Thanks
------------------------------
From: "Raymond Lee" <[EMAIL PROTECTED]>
Subject: unicity distance of DES
Date: Mon, 02 Apr 2001 16:03:28 GMT
Unicity distance = H(K)/D, D=redundancy of the language
My question is to compute the unicity distance of DES with the following
cases:
a) If the keys used consisit only of the letters A-Z(upper case only), and
are 8 letters long and are equally likely.
b) If the keys used have 25% probability consisting of the 8 letters from
A-Z (upper case only) with also values equally likely and 75% probability
consisting of 6 letters from A-Z following by 2 digits (0-9) with all values
equally likely.
In fact, I am quite confuse how to apply this equation into practice. If you
can give me some hints, i really appreciate.
Thanks
------------------------------
From: "Raymond Lee" <[EMAIL PROTECTED]>
Subject: Chosen Plain Text Attacks in DES
Date: Mon, 02 Apr 2001 16:04:05 GMT
It has been said that a brute force attack on DES requires searching a key
space of 2^56 keys.
My question is:
How does the DES complements weakness " DES(X, k)=Y implies DES(X', k')=Y' "
(where X' is the bitwise complement of X) do better than 2^56 keys searching
with chosen plain text attacks?
I mean, what's the relation here between DES complements weakness and chosen
plain text attacks?
In fact, I am quite confused what is "Chosen Plain Text Attacks?"
Thanks
------------------------------
** 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
******************************
