Cryptography-Digest Digest #16, Volume #14       Mon, 26 Mar 01 17:13:00 EST

Contents:
  Re: Please read. (Paul Rubin)
  Re: Data dependent arcfour via sbox feedback (Ichinin)
  Re: Potential of machine translation techniques? (Marc)
  Re: New stream cipher (Gregory G Rose)
  Re: RC4 test vectors after gigabyte output?. ("Joseph Ashwood")
  Re: Idea - (LONG) ("Joseph Ashwood")
  Re: New stream cipher (Mok-Kong Shen)
  Re: New stream cipher (Frank Gerlach)
  Re: Kill-filter expression for script weenie (I Sent Your Saddle Home)
  Re: Please read. (I Sent Your Saddle Home)
  Here's a fun Rijndael Challenge  ("Michael Vaughn")
  Re: New stream cipher (Paul Rubin)

----------------------------------------------------------------------------

From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Please read.
Date: 26 Mar 2001 12:10:28 -0800

[EMAIL PROTECTED] (John Savard) writes:
> >Someone is pooping in our pool.
> >There is little that can be done.
> 
> Of course there is. The anonymous remailers they are using can be
> notified of the problem. They can then turn around and block the
> offender, and then notify the offender's ISP.

This shows a misunderstanding of how remailers work.  A remailer can't
tell who the offender is or who the offender's ISP is.  Remailers
generally get their input, in encrypted form, from other remailers,
with origin information already removed.  See
  http://www.obscura.com/~loki/remailer/remailer-essay.html
for a description.

In the case of this particular flood, it may be possible to implement
some filtering at the m2n (mail to news) gateway.  A more virulent
attack (remember Hipcrime) is much harder to stop.

This particular attack has been going on in apas
(alt.privacy.anon-server) for months and sometimes gets crossposted to
one or two other newsgroups.  Soc.men gets it sometimes and now
sci.crypt has it.  Apas is taking the brunt and chances are, it will
stay on apas, but go away from sci.crypt after a while.

> There is nothing wrong with anonymous remailers, as long as they
> behave in a responsible fashion, and do not permit themselves to be
> used for any kind of abusive behavior.

Replace "anonymous remailers" with "encryption programs" in that
sentence and you'll begin to understand the problem.

------------------------------

From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Data dependent arcfour via sbox feedback
Date: Sun, 18 Mar 2001 03:45:32 +0100

Henrick Hellström wrote:
> That patent cannot be effective in Sweden, at least not to
it's full extent.

It CAN be, because patent legislation is not the same as it were N
number of years ago, i.e. Merkle and Hellman have suceeded to patent a
knapsack crypto in Sweden. I do not know of IDEA and have not read the
claim. For now, Swedish legislation "just say no" to Software patents.

Alarming is from what i've heard, the.SE patent office is going to
become as corrupt as the Us system in a few months. (i.e. prove prior
art) so now they'll hire any trained monkey that can spell "approved",
just another step in downgrading society to fit in with the E.u.

Ichinin

------------------------------

From: [EMAIL PROTECTED] (Marc)
Subject: Re: Potential of machine translation techniques?
Date: 26 Mar 2001 21:22:26 GMT


>Very good translation is indeed difficult to obtain.

Has anyone of you ever tried to feed a text back and forth several
times through the translator? For example English->German->English->
German->English.  Already at this point the text is not recognizable
anymore with eg Altavista/Babelfish.

I think it is a good indication on how much information is lost during
the translation.  When after 4 passes almost nothing is left, obviously
1/4 must be missing already after the first pass.

------------------------------

From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: New stream cipher
Date: 26 Mar 2001 13:27:10 -0800

>MarinaP wrote:
>> 
>> Hi, all!
>> I would like to analyze a new stream cipher.
>> Where can I find it?
>> Where can I find  RC4-like ciphers?
>> What stream ciphers are used in practice? -RC4, A5, PKZIP ( It is clear.)
>> Thank you.

A5 is extremely insightful, and worth beating your
head on for a while. That is is crippled by a
short key and small state isn't its fault.

There are 6 relatively new stream ciphers in the
NESSIE project http://www.nessiecrypt.org/ . Try
them.

Greg.

-- 
Greg Rose                                       INTERNET: [EMAIL PROTECTED]
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/ 
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

------------------------------

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RC4 test vectors after gigabyte output?.
Date: Mon, 26 Mar 2001 13:05:10 -0800


"Luis Yanes" <[EMAIL PROTECTED]> wrote in message
news:Gmm=OprxeTRMB6aiCoo1ryPJG7bV@wingate...
> I readed that good implementations discards 2**(8+1), although 2**8 seems
> enought to avoid the key mix problem. Where these numbers came from?.

Well there's more theories than proof on this. We know for a fact that there
is a notable correlation in the first byte, so that needs to be thrown away.
Because ARCFOUR (RC4) is so fast it is fairly normal to add a bit of
paranoia, and throw away the first 256, 512, or more bytes. It's easily
accomodated paranoia so it's become a convention.

> The gigabyte test would last a
> couple of days!.

Then your implementation is massively slow, you should be able to manage
<<<<<< 50 clocks a byte, which would put 1GB at under a minute (assuming a
1GHz machine). Even assuming a 100 MHz maching it should take less than an
hour.
                    Joe



------------------------------

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Mon, 26 Mar 2001 13:00:09 -0800

I'm sorry but there's this pecky little proof that you have to deal with. It
proves one very simple thing, to have unbreakable security you MUST have a
key at least as long as the plaintext (I believe it was Shannon that proved
this). You really do need to read something, otherwise this pesky thing
called math will keep making a mockery of your statements.
                Joe

"amateur" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Skip the first step of Cesar and you will understand that my idea is
> nothing more than a version of OTP with great advantage : using a short
> key.
> Even if I used a short key of 12 digits, it's hard to solve.
> With a key of 100 hundreds digits it's unbreakable.
> Try just to code two bits with odd and even
> First communication
> 01 = 23 it could 47 or 89 or even odd ......
> Mask them with a key 63
> Let M= a - k => a = M + k = 23 + 63 = 86
> I send a = 86
> Second communication
> 11 = 37
> same key 63
>
> I send b
>
> b = 100
>
> You have a difference -14.
>
> -14 = 100 - 86 =
>
> How could you retrieve m1 and m2?
>
> You want to use a known plain-text attack?????
> Every plain-text gives you a billions of encrypted texts??????
> Just try to understand that it is a version of of OTP with short key and
> the possibility of reusing the key.
>
>
>
>
> "John A. Malley" wrote:
> >
> > amateur wrote:
> > >
> > > Don't forget that with my idea the same clear could produce multiple
> > > cyphertext.
> > > Schneier is defining restricted algorithm when algo is kept secret.
> > > That's not my case.
> > > All my algo is public. The secret who is to find and distinguish two
> > > categories of symbols is not secret at all.
> > > But the sender has the freedom to imagine any kind of two categories
> > > before encrypting.
> > > This secret is disclose if the recipient has the key.
> > > All modern cryptography is based on power of computing.
> > > What I'm proposing is to found a new cryptography based on the
inability
> > > of computer to analyse a text trying to distinguish two categories.
> >
> > Humans write programs.  Algorithms employed by humans to decide
> > something can be transcribed to a computer program (encoded as binary
> > numbers.)  A human recognizes the symbols in the ciphertext correspond
> > to one or another category. The ability of a human to spot patterns can
> > be encoded as an algorithm acting on the data.  So a computer program
> > can be written to do the same thing.
> >
> > Computers sort through data faster than humans. That's the advantage of
> > a computer.
> >
> > > Computer has no this attribute.
> >
> > Computers are glorified adding machines. We tell them to add, subtract,
> > multiply and divide numbers. We encode information as numbers and
> > manipulate information as numbers. No program "means" anything to a
> > computer. Computers do literally what we tell them to do with a program.
> >
> > For a time the word  "computer" meant a person who carried out
> > particular numerical calculations. "Computers" did not necessarily know
> > what they were working on or what the calculation results meant.
> >
> > > So the cryptanalist even if he use the
> > > computer is helpless. The only strategy for him is to try to guess
what
> > > a sender has choosen to encrypt every bit.
> > > And this domain is infinite.
> >
> > So you encode binary-represented ciphertext with members of two set of
> > symbols, each set with the same number of elements. The two sets differ
> > in one property - one set has the property, the other set does not. The
> > absence and presence of the property corresponds to binary 0 or 1.
> >
> > This "encoded" ciphertext is human-readable - it must be, or how can a
> > human decode it?  So a computer program can be written to recognize it
> > same as a human did.
> >
> > This "encoded" ciphertext is program-readable if a program is written to
> > generate the "encoded" ciphertext to send it electronically or to print
> > it onto paper. And that which is generated by a program is recognized by
> > a program.
> >
> > I read the "idea" post and the proposed cipher. A human cryptanalyst
> > *can* figure out which symbols correspond to 0 and 1 no matter what
> > symbols are used, due to the statistics of the plaintext as exposed in
> > the ciphertext.
> >
> > How! you ask...
> >
> > Well, (1) the first thing the cipher does it apply a Caesar substitution
> > to a fixed length of plaintext message.
> >
> > OK. This preserves the frequencies of occurrence of every letter,
> > digraph
> > and trigraph in the plaintext message. And the structure of every
> > sentence. And the order of every plaintext word.
> >
> > Next, (2) convert each character in the substitution output into its hex
> > equivalent, and then to binary (0 and 1.)
> >
> > OK.  This preserves the frequencies of occurrence of every letter,
> > digraph and trigraph in the plaintext message. And the structure of
> > every sentence. And the order of every plaintext word.
> >
> > All (2) does it substitute a binary string for each character in the
> > output of (1). That's why all the salient statistical information in the
> > plaintext comes sailing on through.
> >
> > Now here's a interesting fact:
> >
> > The number of 1s and 0s in the resulting binary string produced in the
> > output of step (2) are NOT equal.  There are either more 1s than 0s or
> > there are more 0s than 1s.
> >
> > Why?
> >
> > Well, some characters in the plaintext occurred far more often than
> > others. And after the substitution cipher in step (1), their ciphertext
> > character equivalents occur far more often than the ciphertext
> > equivalents of the others.  And after (2), the binary string
> > representations of the ciphertext character equivalents occur far more
> > often than the binary string equivalents of the ciphertext equivalents
> > of
> > the others.
> >
> > So what comes next?
> >
> > In step (3) of your idea, form two sets of symbols, each set with equal
> > numbers of elements.  Take the binary string representation output of
> > step (2) and substitute an element out of one set selected uniformly at
> > random for a 0 and a substitute an element out of the other set selected
> > uniformly at random for a 1.
> >
> > OK.  But remember, the number of 1s and 0s in the binary string
> > representation are NOT equal! So symbols from one set appear more often
> > than symbols from the other set.  And the symbols selected from a set
> > are selected uniformly a random. For a quantity of ciphertext encrypted
> > this way, every symbol from the set corresponding to  1 should appear
> > the same number of times and every symbol from the set corresponding to
> > 0 should appear the same number of times.
> >
> > This information allows a cryptanalyst to determine which symbols
> > correspond to which of the two sets representing 0 and 1.
> > It can be determined by frequency count of each symbol in the encoded
> > ciphertext.  Half of the symbols in the "encoded" ciphertext will occur
> > with the same frequency, f_a, and half of the symbols in the "encoded"
> > ciphertext will occur with the same frequency f_b, and f_a will NOT
> > equal f_b.   Which set corresponds to 1 and 0?  It's one or the other -
> > but a clever cryptanalyst knows already what the binary coding of
> > characters is, so therefore already knows if 1s or 0s occur with more
> > frequency in the binary representation of the plaintext alphabet.
> >
> > So in step (3) the 0s are represented with {0,1,2,3,4} and 1s are
> > represented with {5,6,7,8,9}.
> >
> > Again, the number of 0s, 1s, 2s, 3s, 4s will tend to be equal and the
> > number of 5s, 6s, 7s, 8s, and 9s will tend to be equal but the number of
> > 0s will not equal the number of 5s, #1s will not equal #5s, etc.
> >
> > In Step (4) a further Caesar substitution (? there's no modulo operation
> > though, it's just addition) is done by adding a constant key value to
> > the numerical result
> > of Step (3).
> >
> > Does this hide the fact that the number of 0s and 1s in the binary
> > representation output of step (2) are not equal?
> >
> > No.
> >
> > In fact, take any two message blocks encrypted with this cipher (using
> > your notation, E1' + K and E2' + K,  and just subtract one from the
> > other to get E1' - E2'.
> >
> > No key involved here now. It's possible for the cryptanalyst to examine
> > the statistics of the plaintext directly. What are the statistics of the
> > differences between plaintext binary representations - they show up
> > directly in the ciphertext.
> >
> > The addition of a fixed constant (key) in step (4) will not change the
> > statistics of the underlying plaintext as revealed by the substituted
> > ciphertext in step (2).
> >
> > Once a cryptanalyst determines which symbols represent 0s and 1s in a
> > manner like the described, he replaces the symbols with 0s and 1s and
> > gets the binary string equivalent to the Caesar substitution on the
> > original plaintext (output of step 3.) Then all the known tools for
> > cracking simple substitution ciphers apply to rapidly crack this cipher.
> >
> > The attack is even quicker and easier with known plaintext! Try it
> > yourself and see. :-)
> >
> > In summary, here's the core of the attack:
> >
> > Homophonic substitution of the 0s and 1s of the binary string
> > equivalents of the ciphertext output of a simple substitution cipher
> > keeps the statistics of the plaintext (and its binary string equivalent
> > ) intact.  Any bias in the number of occurrences of 0s and 1s shows up
> > in the frequencies of the symbols used to encode 0s and 1s.
> >
> > Hope this helps,
> >
> > John A. Malley
> > [EMAIL PROTECTED]
> >
> >
> >
> >
> > > You have multiple combinations using only the characters of ASCII
table.
> > > If using others codes, you have to understand thas it's quite
impossible
> > > to attack.
> > >



------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: Mon, 26 Mar 2001 23:37:52 +0200



Gregory G Rose wrote:
> 

> There are 6 relatively new stream ciphers in the
> NESSIE project http://www.nessiecrypt.org/ . Try
> them.

I got Error 400 on access.

M. K. Shen

------------------------------

From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: Mon, 26 Mar 2001 23:38:00 +0200

Paul Pires wrote:

> Frank Gerlach <[EMAIL PROTECTED]> wrote in message 
>news:[EMAIL PROTECTED]...
> > MarinaP wrote:
> > >
> > > Hi, all!
> > > I would like to analyze a new stream cipher.
> > > Where can I find it?
> > > Where can I find  RC4-like ciphers?
> > > What stream ciphers are used in practice? -RC4, A5, PKZIP ( It is clear.)
> > > Thank you.
> > try google.com
> >
> > A5 and PKZIP are erm, not "military-strenght" :-)
>
> Your probably not going to take this well but.....
>
> "military-strenght" or "military-strength" are meaningless terms.
> If you don't know the answer, wait for someone else to answer
> instead of posting less than helpful or non-responsive replies.
>
> Paul

I didn't want to call it CRAP from my employer's account.



------------------------------

From: [EMAIL PROTECTED] (I Sent Your Saddle Home)
Subject: Re: Kill-filter expression for script weenie
Date: Mon, 26 Mar 2001 21:54:21 GMT
Reply-To: [EMAIL PROTECTED]

On 26 Mar 2001 10:02:37 GMT, [EMAIL PROTECTED] (filterguy) wrote:

>A filter expression that kills the Script Kiddie posts:
>
>for (Forte) Agent:
>
>subject: (love*|need*|ask*|require*|uses*|want*|used) and from:
>(anonymous|melon|frog2|remailer|steeleye|nescio)

Kind of a large net to catch a small fish, don't you think?
This is precisely what FloodBoy wants.
Block ALL posts sent from anonymous remailers.
And he is smart enough to know that using the remailers for the flood
is his best protection from getting caught. The height of hypocracy.

His goal is silence anonymous speech by taking down the remailers
It may be what your group wants as well. You decide.
-
Saddle

------------------------------

From: [EMAIL PROTECTED] (I Sent Your Saddle Home)
Subject: Re: Please read.
Date: Mon, 26 Mar 2001 21:54:27 GMT
Reply-To: [EMAIL PROTECTED]

On 26 Mar 2001 12:10:28 -0800, Paul Rubin <[EMAIL PROTECTED]>
wrote:

>> There is nothing wrong with anonymous remailers, as long as they
>> behave in a responsible fashion, and do not permit themselves to be
>> used for any kind of abusive behavior.
>
>Replace "anonymous remailers" with "encryption programs" in that
>sentence and you'll begin to understand the problem.

Excellent point.


------------------------------

From: "Michael Vaughn" <[EMAIL PROTECTED]>
Subject: Here's a fun Rijndael Challenge 
Date: Mon, 26 Mar 2001 22:02:48 GMT

Hi,
For those of you who, like me, love the challenge of solving complicated
math problems (yes, I have no life), here is a Rijndael implementation that
I conjured out of code that impresses the hell out of me :)

I am so confident that this is uncrackable that I am giving you the
password!

The message is my phone number and a word. If you can solve this please call
me collect and tell me what the word is.

This was made with a 256-bit key, and the password used to generate the key
is: 12345678901234567890123456789012

And here is the cyphertext:

474A47801C2491E06406820F4AC2D7BA
674AD96644FF666D05F50EE509A6193A
C48F754420557C2D52E946CD623EE51D
EAE36871182418EE9EAE86289B3126EA
87B76B8ADF5A2C79D229739B653AD850
7DEFCD7ADC532B1ED50AB760D6B0D02A
3749E31FD57BE92A7C22C2EBAE7D4EFF
BECF11419B424C6004BC36E7AE9B8AC3
A88EEDDB28A1200DBE1B71B362DFC535
9118FABA15357ECA71315703C296C69C
1F1CEB5255A8EEB179133B8EDBAD18CA
6DFFDEBEB63C9F5D81138362C323FBCD
1406FD6D8AB9C12F1616DE6F49D03B47
4796FF852615C79059AC965B534A9A7D
38E6D53E1B37606FA1C4C565CD3E2A88
0E91C5687F37017EC57531DD87EA842B
3380C27039993E5B0FBDBEAC92CC8393
CD612F218DF53AD3F6FFB0A7ACEDD039
CBA477420732740D1EF41C5DD7444886
5239BA6462D403A9AADFF08CF251469D
284EBE102BB9201F14737223380AC8A5
54AC5048A836DB282DD87BE4C45447F1
B3B240013AF61259145BB2191AA0ED3F
B85C7917F0B84E4A11DD47D8772A15ED
9A41AA7CEF5CAB006013E61AFD4EE8C3
0EF49CB71DB095FE62293A0938282785
0EAB6C751205F2725CE3DAB67926E517
35C60E386A9C6BFD00B5DE219BF409A5
73D905F487B8C418BA53B167AD26F49E
B064175BB17E2B3593AE8F50EDF1B170
F85D3D5EE7F618CA7983721D6492687F
FBBF73E4318FF349C50C2D95E2BD8584
ED54A5E3FCC666ACCDCA6DD0175D81AE
0C2ED22A6E3387EDC41930EDE3E4FE5D
2B901D3FCD1F44725F821ABA1197C934
4F218F99D7CA08DD3DCE9A0683EDAD50
36FF12B40C7D7976175F8743697FA086
96BE33153D654D7D93267B8A40D50B23
52F05FAA52C3AE5C924604D0E1F474D3
D157735FFEA06D6DAB6548BF4FA598A2
20CDB797C68F8A72E33CB5DCADF4DFD4
157799B52742EC9187DCE7047E1C2496
CA904B1052703B381818DC02CE3D722C
530DC071121EB5F8C182897EC8291F6C
FA56E96C0134A1BEF9B7EA567EB13663
1709D826795FD348216E7B1B1DAE66C4
77EAC177296C196B1B79D44F7C9E1DFA
A6ACB65680600111D5C116F335824F94
4553F21D6FF1CB3F5389166C08764D94
1D98DF904BD36B0F920F168F55196DA0
69D9F1517A200B2E03F64AD5824E24D5
3BA5E2EF7067C302653F15A4180A8291
96D4CE597C68782AF924658014BE8D19
114AC3EEB6DE33C2FCCBEC8FF3230227
77DDAA389FA2EDF4884B15069F892A68
5DE9383DCDE5A702A9BF2D2EB4679042
CF0FB65B65D9B452FCE2725678E67D20
E24273A8493D42194145674538222255
26DF10CD7B73D29D2A504B58F6A227E9
9B7D6541D5E4E91D5EFAC20987064F4E
744BBA04994E970FCAFD51F9CCD7189D
12124FA57AFA41D6797F1AC25F6D0536
1585A549496E0D1BBE74A8CDF8F1FE2B
BD4B75A6BDFB47F4D22329A6FEC7D02F
736C0ED1838753132A98AC224A1D340C
DF63C69F660756BD7D2C78156D517F0B
8DCE56FED746EBA450C3BDC26DC33D82
A8C7B1D7404D19E7DFDF5DCB0B86BE6D
27862B86C879854B2A34E4B8FA585A88
2AC03BB95EB74EB00B871046B755BD4E
43610213D17AA16BB99B720CB8EBD9D2
A5D7F07BA9963F82B5DC98E2CC487E63
E24273A8493D42194145674538222255
A8FD5A9568663E264CAFA7A29ED0F1FA
612A5F7D50DC71262327FCB3D24C8A8C

[EMAIL PROTECTED]
Remove the XXX to email me.




------------------------------

From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: 26 Mar 2001 14:03:29 -0800

[EMAIL PROTECTED] (Gregory G Rose) writes:
> There are 6 relatively new stream ciphers in the NESSIE project
> http://www.nessiecrypt.org/ . Try them.

I think you mean www.cryptonessie.org.  But I don't immediately see
the stream ciphers there.


------------------------------


** 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
******************************

Reply via email to