Cryptography-Digest Digest #447, Volume #10 Mon, 25 Oct 99 10:13:03 EDT
Contents:
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Mok-Kong
Shen)
Re: Note on Feistel Ciphers (Mok-Kong Shen)
Re: some information theory (very long plus 72K attchmt) ("Mattias")
Re: Some humble thoughts on block chaining (Mok-Kong Shen)
Re: Character Frequencies Tables for languages other than English (Eric Hambuch)
How to use CBC w/ RC4? (Tom)
Re: Some humble thoughts on block chaining (Bo Dömstedt)
RC 4: security & law ([EMAIL PROTECTED])
Re: How to use CBC w/ RC4? (Tom St Denis)
Re: compression and encryption (Tom St Denis)
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E (Tom St Denis)
Re: Posting Anonymously (Steve K)
Re: NAI version of PGP no secure? ("Sergey Kuznetsov")
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 10:06:22 +0200
[EMAIL PROTECTED] wrote:
>
> Now if the attacker *does* know which cipher has been used for each
> ciphertext block, then he can attack the ciphertext encrypted by the
> weakest cipher. Consider this: even though we in the public don't know
> the lower bound of security of the individual ciphers we must assume
> that a powerful attacker does know. We also can assume that these lower
> bounds vary a lot - it would be strange indeed if different ciphers
> were very similar in their lower bound of security. So in a pool of
> four ciphers it is quite probable that one (the "lemon") is orders of
> magnitude weaker than the others and that the attacker knows this. Let
> us assume the lemon falls to a known plaintext attack that requires a
> small number of known plaintexts. It is true that the attacker will now
> have to collect four times more data for the lemon, but this quantity
> will be a trifle compared to the plaintext that must be known for
> attacking any of the other three ciphers. Therefore the attacker will
> easily break 25% of the communications recovering almost all
> intelligence. Instead of using this method, we would be better off
> choosing one cipher by chance sticking to it.
A tiny remark: Using variable keys as proposed by me in another
thread, such attacks presumably have to be considered in a different
perspective.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Note on Feistel Ciphers
Date: Mon, 25 Oct 1999 10:06:11 +0200
[EMAIL PROTECTED] wrote:
>
> Mok-Kong Shen wrote:
> > [EMAIL PROTECTED] wrote:
> [...]
> > > The Feistel structure is already powerful enough to
> > > induce any bit permutation. The point is not that we
> > > might actually want to implement a permutation as
> > > Feistel rounds, but that the separation of the left
> > > and right halves that one might intuitively suspect in
> > > the Feistel structure does not in fact exist.
> >
> > Whether one can realize an arbitrary permutation with Feistel
> > construct is not my concern. My point was that adding in a
> > permutation step could render analyisis schemes that somehow exploit
> > the seperation unworkable.
>
> My point is that your concern, attacks that exploit
> a separation between the halves in Feistel ciphers,
> is of no concern at all. The separation is only in
> the process of computation; it is known not to limit
> the resulting dependencies. What does the
> realization of arbitrary bit-permutations within the
> Feistel construct prove? That any weakness that can
> be repaired by adding bit-permutations is not
> characteristic of Feistel ciphers.
>
> > Adding permutations certainly contribute some complexity.
>
> In the sense that adding most anything key-dependent
> contributes some complexity to most any secret-key
> cipher. The relevant point to a "Note on Feistel
> Ciphers" is that Feistel ciphers already cover
> bit-permutations.
I guess that probably you wanted to use the last sentence above in an
other than normal sense. Anyway, I am afraid that this sentence
together with your previous sentence
The Feistel structure is already powerful enough to
induce any bit permutation
can generate something very misleading for the reader. Using the
context of mine, which considers the input and output of two
rounds taken together, did you mean that there exists a key, such
that the output bit sequence (whole block) is any prescribed
permutation of a given input? I am not sure that it is simple (or
even generally possible) to show that there are two subkeys (since
two rounds are involved here) that do that for a given Feistel
design. In the mathematical argument given in your previous post:
L ^= R & K
R ^= L & K
L ^= R & K
you used the SAME symbol K in the three equations. That means that
the round functions operated on (the always current) L and R under
three subkeys are to be the SAME value K. Note in particular that
these subkeys have to be derived from one and the same key by a
given key schedule. I don't exclude that I gravely misunderstood
your presentation because of my poor knowledge. But anyway some
additional explanations from you seem required.
M. K. Shen
=============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Mattias" <[EMAIL PROTECTED]>
Subject: Re: some information theory (very long plus 72K attchmt)
Date: Mon, 25 Oct 1999 10:16:59 +0200
Hi
An alternative way to look on the question:
Defs:
E() - encode in the crypto
D() - decode
Comp() - compress
DeComp() - decompress
Now we add the additional definitions:
E'(P) = E(Comp(P))
D'(C) = DeComp(D(C))
Clearly E',D' can be seen as defining a crypto in its
own right. The question now reduces to
"Is the crypto defined by E'&D' more secure
than the one defined by E&D ?"
Generally speaking (without knowing anything more
about E,D,Comp,DeComp and the domain of the plaintext
P) this is clearly impossible to answer. Especially since
defining the security of a crypto in any formal sense
is problematic at best.
Could we agree on that the fact that E',D' as well as
E,D is 1 to 1 (ie no information loss) is NOT enough
to prove that the two cryptos are equally secure?
Otherwise this argument would easily generalize to
saying that ALL cryptos are equally secure which is
clearly absurd (Right?).
(This would include such "cryptos" as E=D=I where
I is the identity function which is fairly easy to
break).
If we can agree on this then we can start the discussion
in which cases E'&D' is a more secure crypto.
-- Mattias
Anton Stiglic wrote in message <[EMAIL PROTECTED]>...
>Mattias wrote:
>
>> Facts
>> =====
>>
>> F1. (Anton's main claim) For any data P the information in P and
>> Comp(P) is the same.
>>
>> F2. (Refutation of Anton's secondary claim) F1 does NOT imply that
>> it is as easy for an attacker - having acces only to the
>> cypher-text - to decrypt E(P) as E(Comp(P))
>
>F2 us clearly wrong. Just answer me this simple question, if p in P has
>some redundancy, and Comp(p) looses *information* about this
>redundancy, how is it that DeComp(Comp(p)) gives you back p? Is
>it by magic? Oh, it just comes back by magic. No, it's because the
>information is still there.
[snip]
*sigh*
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some humble thoughts on block chaining
Date: Mon, 25 Oct 1999 10:39:29 +0200
[EMAIL PROTECTED] wrote:
>
> Mok-Kong Shen ([EMAIL PROTECTED]) wrote:
> : But the whitening e.g. in DESX is supposed to add some security, I
> : suppose. Is there any clear ground that DES shouldn't be combined
> : with a stream encipherment, excepting the belief
>
> which, of course, is now known to be false
To make my original post clearer, I like to add that in my personal
opinion chaining mainly serves the whitening purpose (using a
variable value). (It can also serve to detect lost blocks etc. but
that's a two-sided knife, for it could be argued to be a disadvantage
in certain applications.)
> It might also be noted that the statelessness of a block cipher means that
> its key size is genuinely bounded; a stream cipher might have a short key,
> but a large internal state, and admit of being used in a nonstandard way
> that would increase the key size to that of the internal state.
I am afraid that the second half of the above sentence could be
misleading. Since the internal state is derived from the key,
then there can exist no 'effective key' that is larger than the
real key, for all the entropy must come from that anyway. One can
however devise to use an arbitrarily long key and thus be able to
provide some very large internal state. I did that in my design of
a compound PRNG, see my web page.
M. K. Shen
=======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: Character Frequencies Tables for languages other than English
Date: Mon, 25 Oct 1999 11:12:51 +0200
JTong1995 wrote:
>
> >I am looking for character frequency tables for european and other
> >languages. Does anyone know where these are available?
>
Online for German and English on:
http://wwwirf.ira.uka.de/redundanz/vortrag01/
Eric
------------------------------
From: [EMAIL PROTECTED] (Tom)
Subject: How to use CBC w/ RC4?
Date: Mon, 25 Oct 1999 12:38:45 GMT
Reply-To: [EMAIL PROTECTED]
As I understand it, using RC4 without an IV or feedback to encrypt
multiple messages with the same key makes a known plaintext attack
trivial, as you just xor the known plaintext with the ciphertext to
recover the key stream.
My question is, wouldn't using CBC mode with only one byte of
feedback, even with a long IV, also be extremely easy to break, as
there would be a 1/128 chance of identical key streams?
If this is true, can RC4 be used, assuming a psuedo-random IV, with
some CBC mode that wouldn't be vulnerable to a known plaintext attack?
------------------------------
From: [EMAIL PROTECTED] (Bo Dömstedt)
Subject: Re: Some humble thoughts on block chaining
Reply-To: [EMAIL PROTECTED]
Date: Mon, 25 Oct 1999 11:17:46 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
Your suggested feedback mode never became a DES
standard. It is published in [1] though. Even more interesting
is the fact that, when using feedback from both plaintext
and ciphertext, there is a published note on a DES weakness,
when combining the two using XOR. Instead 64 bit carry add
is recommended. The details of this DES weakness has never
been openly published, as far as I know.
==== sci.crypt repost ====
Bo Doemstedt wrote:
The four basic feedback modes for DES are:
ECB, CBC, CFB and OFB.
There exist one more feedback mode for the DES, more secure
than the four "standard" modes above, as described
by Meyer and Matyas in their book [1].
"Block Chaining Using Plaintext and Ciphertext Feedback"
(page 69; Figure 2-16 on page 70)
Assume Y(i) ciphertext; X(i) plaintext:
Y(i)=Encrypt(X(i) xor U(i)), i>=1
X(i)=Decrypt(Y(i) xor U(i)), i>=1
and
U(i) = { Z if i == 1,
h(X(i-1),Y(i-1)) if i > 1}
This feedback mode converts the DES into a General Block Cipher
(Equ. 2-19a and 2-19b on page 68)
Note that h(A,B) is not selected as h(A,B) = A xor B,
as this scheme has some weakness (middle of page 101),
when used with the DES. Instead h(A,B) = (A add B) mod (2^64),
U(i) = (X(i-1) add Y(i-1)) mod (2^64) (if i > 1)
(page 361(bottom)+363(top), and [2]).
Different feedback modes are compared with each other
on pages 110-111 (figure 2-41 and 2-42).
Reference
[1]
Meyer, Carl H., Matyas Stephen M.
"Cryptography: A New Dimension in Computer Data Security"
755 pages, John Wiley and Sons 1982
ISBN 0-471-04892-5
[2]
Jueneman, Robert R.
"Analysis of Certain Aspects of Output Feedback Mode"
pages 99-127
Advances in Cryptology
Proceedings of Crypto 82
Chaum, David (ed)
Rivest, Ronald L. (ed) and Sherman, Alan T. (ed)
Plenum Press 1982
Bo Doemstedt
Chief Cryptographer
Protego Information AB
IDEON,Lund,Sweden
Truly random keys and I.V.s with the SG100:
http://www.protego.se/sg100_en.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: RC 4: security & law
Date: Mon, 25 Oct 1999 11:17:31 GMT
Please Help
I.
Is there any attack against RC 4 that is better than
Brute Force.
II.
What about the U.S. Export Regulation. I think it is
allowed to export cryptogrphic product from U.S. if
the key isn't longer than 56 Bit. If it is longer, than
you need permission from an "office/authority".
Netscape CC 4.x is able to use 40-bit and 128-bit encryption
in the SSL(based an RC4). What version CC 4.x uses in other
states than the U.S.
Where can i find law text about this regulation.
III.
The algorithm RC-4 is widespread. If i know the algorithm
i am able to make an hardware/software implementation.
If i call the product xxx is it legal to use the product
commercial. In my opinion i have not to pay any fees to
RSADSI, because there is not existing a patent who protects
the algorithm RC4.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: How to use CBC w/ RC4?
Date: Mon, 25 Oct 1999 11:43:41 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> As I understand it, using RC4 without an IV or feedback to encrypt
> multiple messages with the same key makes a known plaintext attack
> trivial, as you just xor the known plaintext with the ciphertext to
> recover the key stream.
>
> My question is, wouldn't using CBC mode with only one byte of
> feedback, even with a long IV, also be extremely easy to break, as
> there would be a 1/128 chance of identical key streams?
>
> If this is true, can RC4 be used, assuming a psuedo-random IV, with
> some CBC mode that wouldn't be vulnerable to a known plaintext attack?
>
I don't know where you are going with this, your question is moot. You
never use the same key twice for any message, no matter what cipher you
use.
CBC mode is only used replay attacks harder where the same key (but
different initial IV) are used.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: compression and encryption
Date: Mon, 25 Oct 1999 11:48:46 GMT
In article <7uvg4e$upm$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Patrick Juola) wrote:
> That's because standard LZSS and LZW aren't *headerless* compression
> schemes.
Um if I am not mistaken, LZSS and LZW are not in the same family (77
and 78 respectively). LZSS uses a prefix bit to denote literal or
<index, length> code words. There is no such thing as an invalid LZSS
code. It might seem odd to read farther into the window then your
current stream positition (say the first codeword is an index to 30
bytes ago), but this is certainly legal if you use a pre-built window.
LZW on the otherhand has illegal codewords. If I am not mistaken it's
<index, literal> code words. If you use an index that has no value yet
this would be matching against a null string...
At anyrate neither have 'headers'. They are adaptive methods not
static.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
Date: Mon, 25 Oct 1999 11:57:02 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> You have the software?
>
> I don't recall sending you the software. So I looked through my
> entire SENT file and I have determined that I did not send you any
> software. Although I said I would if you asked, you never asked for
> the software.
>
> I did send you a paper on the basic theory.
>
> Well, if you do have a copy then it should be no problem for you to
> cite an instance in the theory or use that supports any of your
> critiques of OAP-L3. Let's hear some? Quit talking about the web
> site. You have the software, right? Then give us some software
> examples.
>
> We are not idiots. Why have you not used your knowledge of the theory
> and software to provide examples of why you think the software is
bogus?
>
> I'll tell you why: you are just blowing smoke. And everyone knows
> it.
>
You know what, do whatever the $#@! you want. I am tired of arguing
with the dumbest dolts in this group. I stated a long time ago I am no
genius. Yes I can't break OLP-3 or whatever it is called for two
reasons:
1) I don't have the required know-how to. I am not even done
highschool.
2) I don't have the time nor the inclination to attack some homebrew
piece of crap hacked together to look pretty while peddling million bit
key ciphers. I goto school, work and only have minimal time to
actually use the computer at home.
So keep peddling your million bit cipher. Most people (hopefully) will
see thru it.
Why don't you describe your cipher a little clearer (which is something
I recall asking you) post it as a .PS on your website and people will
look at it. But insane ramblings in a .doc file do not constitute
documented math.
Another thing I realized is the dumbest dolts (ok you and Mr. Scott)
always peddle stupidness, but never document it. Why don't you prove
your method is secure, or at least provide reasonable conjecture as to
why it should be thought of that way, instead of rambling on and on
arguing and bickering. You know real work. Also compare it to modern
ciphers in security, speed and compactness. After you do that
objectively you will see why most people see you as a snake oil peddler.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Posting Anonymously
Date: Mon, 25 Oct 1999 12:09:46 GMT
On Sun, 24 Oct 1999 22:27:36 -0400, "entropy"
<[EMAIL PROTECTED]> wrote:
>How do people post anonymous messages to alt.anonymous.messages? Looking at
>the header, they come from nym.alias.net. How do I set up an account with
>nym.alias.net? (everything I've found has been in German) Are there other
>(free) services that post anonymously?
>
>Thanks
>:::entropy:::
>ktheory.com
>
http://lycaeum.org/~sunny/SimpleAnonymity.html
One of the better introductions.
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
------------------------------
From: "Sergey Kuznetsov" <[EMAIL PROTECTED]>
Subject: Re: NAI version of PGP no secure?
Date: Mon, 25 Oct 1999 16:02:49 +0400
Gurripato <[EMAIL PROTECTED]=NOSPAM> wrote in message
> On Mon, 25 Oct 1999 08:06:31 +0400, "Sergey Kuznetsov"
> <[EMAIL PROTECTED]> wrote:
>
> >
> >Adam Durana <[EMAIL PROTECTED]> wrote
> >
> >> think of the NSA, an institution with a lot of computing power maybe
even
> >> the institution with the most computing power in the world.
> >
> >Good example of how wasting people's money american goverment. What for
NSA
> >needs computing superpower, if they cannot to break even 128-bit key.
And
> >in order to read messages encrypted with PGP, not needed any
supercomputer.
> >
> "Even to break a 128-bit key" is an enormous task, don´t
> underestimate it. And remember that many people do not use 128 bits.
> If people are still fool enough to use RC4-40 bits or DES, the NSA
> will be deligthed to prove them wrong (without telling them, of
> course).
Those who using RC4-40 bits do not have anything to hide frome NSA. I did
want to say, that NSA either can easy read "encrypted" messages without any
supercomputer (messages encrypted with, for instance, RC4-40 or PGP), or
they cannot read encrypted messages at all even with thousand
supercomputers(messages encrypted with more serious means).
Regards,
Sergey Kuznetsov.
------------------------------
** 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
******************************
