Cryptography-Digest Digest #776
Cryptography-Digest Digest #776, Volume #13 Fri, 2 Mar 01 05:13:00 EST
Contents:
Re: The AES draft FIPS is out!!! (Paul Crowley)
Re: how long can one Arcfour key be used?? (Paul Crowley)
Re: Rijndael S-box inverse (Paul Crowley)
Re: super-stong crypto, straw man phase 2 (wtshaw)
New web site ("Greg Ofiesh")
Re: RC4 like stream cipher ("Scott Fluhrer")
Re: "RSA vs. One-time-pad" or "the perfect enryption" (Steve Meyer)
Re: The AES draft FIPS is out!!! ("Brian Gladman")
Re: "RSA vs. One-time-pad" or "the perfect enryption" (Nicol So)
Re: "RSA vs. One-time-pad" or "the perfect enryption" (Nicol So)
Re: super-stong crypto, straw man phase 2 (Nicol So)
Re: Urgent DES Cipher source code ! (Frank Gerlach)
How good is the KeeLoq algorithm? (Søren A.Møller)
Re: Keystoke recorder (Frank Gerlach)
ARCFOUR and Latin Squares ("r.e.s.")
Re: = FBI easily cracks encryption ...? (Frank Gerlach)
Re: HPRNG (Frank Gerlach)
Re: How good is the KeeLoq algorithm? (Frank Gerlach)
Subject: Re: The AES draft FIPS is out!!!
From: Paul Crowley [EMAIL PROTECTED]
Date: Fri, 02 Mar 2001 06:32:58 GMT
"Tom St Denis" [EMAIL PROTECTED] writes:
"Volker Hetzer" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Check http://csrc.nist.gov/encryption/aes/ .
Greetings!
Volker
A postscript is available at
http://tomstdenis.home.dhs.org/nist_aes.ps.gz
...since the original is available only in Microsoft Word format.
Thanks Tom!
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
--
Subject: Re: how long can one Arcfour key be used??
From: Paul Crowley [EMAIL PROTECTED]
Date: Fri, 02 Mar 2001 06:32:57 GMT
"Tom St Denis" [EMAIL PROTECTED] writes:
"Scott Fluhrer" [EMAIL PROTECTED] wrote in message
news:97knf5$66h$[EMAIL PROTECTED]...
Agreed. Of course putting ASCII into RC4 directly is a "dumb" idea. It
severely cripples the key generation process.
Do you have a reference to that?
[snip]
No, I don't have an exact attack but I feel better using a hash on ascii
passphrases first. It concentrates the entropy better (in theory) and
avoids the potential weakness.
Interestingly, CipherSaber uses the fact that passphrases are ASCII to
avoid the RC4 weak keys.
I'd say the RC4 key schedule is slightly inadequate no matter how your
key bytes are drawn, but that if you discard 256 bytes of output after
scheduling as is often recommended, you should be OK with ASCII,
binary, or any string with sufficiently high entropy.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
--
Subject: Re: Rijndael S-box inverse
From: Paul Crowley [EMAIL PROTECTED]
Date: Fri, 02 Mar 2001 06:32:58 GMT
I worked out the shifts needed to do the inverse affine transformation
in Rijndael with a simple exhaustive search. Remember to do this
*before* applying the self-inverse S-box, rather than after as with
the forward direction :-)
This definition is in Python because I've been learning it, but Python
looks so much like pseudocode that you're unlikely to have trouble
decoding it if you're familiar with C-style operators like | for "or",
^ for "xor" and "" for "shift left".
def rot1(t):
return ((t 1) | (t 7)) 0xFF
affine_box = [None] * 256
for i in range(0,256):
ri = rot1(i)
ai = i ^ ri
ri = rot1(ri)
ai = ai ^ ri
ri = rot1(ri)
ai = ai ^ ri
ri = rot1(ri)
affine_box[i] = ai ^ ri ^ 0x63
inv_affine = [None] * 256
for i in range(0,256):
ri = rot1(i)
ai = ri
ri = rot1(ri)
ri = rot1(ri)
ai = ai ^ ri
ri = rot1(ri)
ri = rot1(ri)
ri = rot1(ri)
inv_affine[i] = ai ^ ri ^ 0x5
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
--
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: super-stong crypto, straw man phase 2
Date: Fri, 02 Mar 2001 00:23:29 -0600
In article [EMAIL PROTECTED], "Douglas A. Gwyn"
[EMAIL PROTECTED] wrote:
William Hugh Murray wrote:
"Douglas A. Gwyn" wrote:
William Hugh Murray wrote:
In any case, most of us do not worry about keeping secrets from
nation states for a long time.
Well, you should!
I admit that I do like to confound authority.
Another point is that "super strong crypto" ought to mean that
*nobody* can come up with a practical attack; if you allow that
some "nation-state" can successfully attack a given system, then
that demonstrates that that system was not "super strong".
Ciphers can be separated into groups according to my scale founded on
Shannon's unicity concept. The groups are trivial, wea
Cryptography-Digest Digest #776
Cryptography-Digest Digest #776, Volume #12 Tue, 26 Sep 00 04:13:00 EDT
Contents:
Re: A Different Kind of Quantum Computer (SCOTT19U.ZIP_GUY)
Re: Tying Up Loose Ends - Correction (SCOTT19U.ZIP_GUY)
Re: Question on biases in random numbers decompression (SCOTT19U.ZIP_GUY)
Re: NTRU question (actually truncated modular polynomial question) (Scott Contini)
Re: Tying Up Loose Ends - Correction (Guy Macon)
Re: Encryption Project ("kihdip")
Test for weak keys in 3DES ("kihdip")
Re: On block encrpytion processing with intermediate permutations (Bryan Olson)
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: A Different Kind of Quantum Computer
Date: 26 Sep 2000 03:46:00 GMT
[EMAIL PROTECTED] (John Savard) wrote in
[EMAIL PROTECTED]:
On Mon, 25 Sep 2000 15:37:42 -0700, "A. Melon"
[EMAIL PROTECTED] almost wrote, in part:
Quantum computers can only solve problems in BQP, which is not thought
to include NP-complete problems. Now there is a new type of quantum
computer being proposed:
http://xxx.lanl.gov/abs/quant-ph/9910073
The paper claims this could solve NP-complete and sharp-P-complete
problems.
No, this isnt the End Of Cryptography As We Know It (EOCAWKI). Even if
the claims are true, it may be impossible to actually build. Even if
it is possible to build, it will be easy to make ciphers that defeat
it.
For example, make a random, public, invertible, 27x27 sbox, and
distribute it on CD-ROM. Encrypt a block by applying AES, then passing
it through the sbox (in groups of 27 bits), then applying AES again.
The sbox is only 432MB, so it is easy to distribute.
Oh, dear. I have visions Scott27u now.
Well actually I know I did 4 8 16 and then 19.
I am quite happy with prime numbers for the future
ones so lets wait a few years till floppies
commonly hold several gigs and leap to scott29u
The quantum computer
would need millions of qbits to crack it.
I wonder. There might be a meet-in-the-middle attack. Because the
quantum computer's copy of the CD-ROM would *not* have to be in qbits,
since the CD-ROM is fixed and public; the number of qbits only has to
be the length of the secret key. But the non-qbit size of the problem
might still create problems in avoiding decoherence or something.
Your correct John you have been reading more than Enigma
that is what I haver read also. Most systems to be modeled you
need only enough qbits to match the key length. But since most
still don't believe quantum computers exist. You may be wasting
your time telling those in this group.
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: Tying Up Loose Ends - Correction
Date: 26 Sep 2000 04:00:43 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in [EMAIL PROTECTED]:
Mok-Kong Shen [EMAIL PROTECTED] wrote:
: BTW, could you answer my question of whether Scott's
: 1-1 scheme can deal with arbitrary boundaries, since
: you are apparently fairly familiar with that?
I believe David found that Matt Timmerman's scheme could be simply
adapted to allow for abritrary block boundaries. IIRC David advised
Matt of this, and Matt implemented it. I might be making all this up,
though ;-|
Anyway, on http://members.nbci.com/ecil/compres5.htm David has code that
bijectively goes to and from Matt's finitely odd files - i.e. binary
strings that end with a 1 followed by an infinite zero tail.
The code...
Converts to/from files made of any number of bytes;
Converts to/from even byte length files;
Converts to/from odd byte length files;
Converts to/from 8 bytes multiple file.
I don't know if David's used other types of granularity. I figure he
knows how to do it if he wants to.
His original compression programs only worked with byte-oriented files.
I don't know if this has changed since I last looked at them.
You could probably chain their output through the "finitely odd"
convertors, if you wanted other types of granularity.
Your correct Tim. Thanks for anwsering Mok. I guess he is not the
kind of person I can communicate with so I think its best I stop answering
his posts. We never get anywhere I am left with the feeling that he never
gets any closer to understanding what I have done. I think Matt got his
idea of file endings from my huffman endings. But his is different and
there seems to be several ways to look
Cryptography-Digest Digest #776
Cryptography-Digest Digest #776, Volume #11 Mon, 15 May 00 08:13:00 EDT
Contents:
Re: S-BOX Construction Tutorial? (Mok-Kong Shen)
Re: Definition of "Broken" Cipher (Mok-Kong Shen)
Re: S-BOX Construction Tutorial? (Terry Ritter)
Re: Notes on the "Vortex" block cipher (Terry Ritter)
Re: How does one test an encryption algorithm? (Runu Knips)
Re: Using TEA in one-way hash function ("adam pridmore")
Re: Notes on the "Vortex" block cipher (Tom St Denis)
Re: S-BOX Construction Tutorial? (Tom St Denis)
Re: Encryption of graphics by transposition (Tom St Denis)
Q: Searching for multiparty authentication protocols (=?iso-8859-1?Q?Tom=E1s?=
Perlines Hormann)
Re: Unbreakable encryption. (Paul Waserbrot)
Re: Unbreakable encryption. (Runu Knips)
Re: AES Comment: the Hitachi patent (Runu Knips)
Re: Q: Searching for multiparty authentication protocols (Tom St Denis)
Re: Unbreakable encryption. (Mok-Kong Shen)
Re: Notes on the "Vortex" block cipher (Runu Knips)
Re: Unbreakable encryption. (Mok-Kong Shen)
Re: Unbreakable encryption. (Tom St Denis)
Re: Unbreakable encryption. (Tom St Denis)
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 08:07:31 +0200
Scott Fluhrer wrote:
Mok-Kong Shen [EMAIL PROTECTED] wrote:
Another cost of having key dependant sboxes is key agility. If you either
are using a different key to encrypt each different message, or if you use
so many different keys that it is impractical to save the expanded key
schedules, then how long it takes to set up for a particular key is
important. And, having to compute what the S-boxes look like each time is a
serious hit.
Although, I must say that Twofish took an interesting approach. Perhaps
other cipher designers should examine it.
Computing the random S-boxes can certainly be a substantial cost
that is to be counted on the negative side of that approach. On the
other hand, if one chooses to use fixed S-boxes, then I am of the
humble opinion that one should have different ones in different rounds.
M. K. Shen
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Definition of "Broken" Cipher
Date: Mon, 15 May 2000 08:29:46 +0200
Tom St Denis wrote:
It's quite simple. You don't say your car is broken because of a dent
in the fender right?
It depends. Gates might change his car. On the other hand, there is a
good business in Europe buying cars that nobody wants to have and
selling these to some developing countries. Whether a cipher is good
to use depends on the application and your (more or less subjective)
judgement, I believe. Single DES is e.g. yet good enough for a fairly
wide range of applications.
M. K. Shen
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: S-BOX Construction Tutorial?
Date: Mon, 15 May 2000 06:31:38 GMT
On Mon, 15 May 2000 04:31:57 GMT, in [EMAIL PROTECTED],
in sci.crypt [EMAIL PROTECTED] (John Savard) wrote:
On Mon, 15 May 2000 02:09:39 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
What are you talking about?
Every enciphering has some key. Any opponent might just try that key
at random. Does that make the cipher weak? Does that make the
keyspace non-flat?
Similarly, if we construct S-boxes such that they are a "random"
selection from among the universe of such S-boxes, does the fact that
one of these is the "identity transformation," others are close, and
many are somewhat linear make any difference at all (assuming the
universe of possible S-boxes is "large enough")?
Actually, the fact that some S-boxes are close to being linear, while
others are not, does mean that some keys are "better" than others in a
way that is not applicable to a cipher like DES. (Although DES does
have weak keys for another reason.)
Sure. And if we consider opponents who always start brute force
keysearching with the same key, then our use of that key will be weak.
But we don't know which key the opponents will start with, and we are
forced to use *some* key. Nevertheless, one of the keys in the
universe of all possible keys -- in fact whole groups that the
opponents will search -- will be "weak." In that sense cipher
keyspaces are *always* non-flat, and we accept that.
I think it would make sense to object to a probabilistic design if
provably secure designs existed. But since they do not, I think we
find that any alternative to a probabilistic design is worse.
This has been used as a reason - or as an excuse - for not using
key-dependent S-boxes in ciphers.
Given a reasonable amount of known plaintext, if a cipher is designed
so that its security depends on having S-boxes that are random, but it
happens that the key being used has produced
Cryptography-Digest Digest #776
Cryptography-Digest Digest #776, Volume #10 Tue, 21 Dec 99 03:13:01 EST
Contents:
Re: DES as pseudo random number generator (UBCHI2)
Re: An attack on the WTLS SHA_XOR_40 MAC algorithm (Markku-Juhani O. Saarinen)
How do you know if you found a key? (Greg)
Re: RST discovers defective crypto in Netscape mail password saver (Ken Lamquist)
Re: AES and MATTS COMPRESSION ("Matt Timmermans")
Re: Q: transcendental pad crypto ("dls2")
Re: Q: transcendental pad crypto ("Trevor Jackson, III")
Re: How do you know if you found a key? (David A Molnar)
WEBPAGE UPDATED (SCOTT19U.ZIP_GUY)
Re: compression encryption (Ken Lamquist)
Re: Keystrokes monitored/encryption useless (Guy Macon)
firmware encryption? ([EMAIL PROTECTED])
Re: US Patent Office: How Stupid? Look Here... (Anthony Stephen Szopa)
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Re: DES as pseudo random number generator
Date: 21 Dec 1999 02:11:00 GMT
It's not a bad idea at all. Just run your fingers randomly over the keyboard.
Then encrypt with des. Then you pull out the numbers out of the encrypted text
and use those as a one time pad. Neat Idea
--
From: Markku-Juhani O. Saarinen [EMAIL PROTECTED]
Subject: Re: An attack on the WTLS SHA_XOR_40 MAC algorithm
Date: 21 Dec 1999 02:18:15 GMT
David Hopwood [EMAIL PROTECTED] wrote:
David Wagner wrote:
Good catch. Yeah, I agree: the so-called WTLS 'XOR MAC' is seriously
flawed, and definitely should be eliminated with all possible haste.
Submitting your result to WAP might be useful, to keep them honest.
I have done; I'll also point them to Saarinen's paper and outline your
repeated ciphertext attack.
The WAP security group is aware of the results presented in my paper [1].
I have received the usual telecom-industry "doesn't work in practice" type
of note regarding the results presented in my paper :-)
Has anyone checked whether the elliptic curves that do not have seeds given
for them are of any special form, BTW?
They appear to be ok as far as I can tell. My guess that they were
actually computed by Certicom (Certicom is selling a WTLS toolkit).
I am currently updating and expanding the original paper [1]. Now that WAP
and WTLS implementations are becoming available (Nokia, Siemens, Microsoft
/ Benefon, etc.) the issue of security bugs resulting from implementation
detail is an interesting one.. I hope that I can get some funding for that
line of research.
- mj
Markku-Juhani Saarinen [EMAIL PROTECTED] University of Jyväskylä, Finland
[1] Markku-Juhani Saarinen, "Attacks Against the WAP WTLS Protocol,"
Secure Information Networks: Communications and Multimedia Security
'99, Kluwer Academic Publishers, Boston, 1999, pp. 209--215
--
From: Greg [EMAIL PROTECTED]
Subject: How do you know if you found a key?
Date: Tue, 21 Dec 1999 04:15:08 GMT
If you take random data, and you encrypt it with DES, then
you search for the key using any and all known attacks, how
do you know when you found the right key?
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Ken Lamquist)
Subject: Re: RST discovers defective crypto in Netscape mail password saver
Date: 21 Dec 1999 04:32:52 GMT
Gary McGraw writes that "the encryption algorithm used by Netscape to
scramble [E-mail] passwords is exceptionally weak." Encryption normally
refers to encoding data in such a way that it is computationally
infeasible to decode the data unless you know a secret key. Netscape
does not do this with E-mail passwords. It does use a form of
security through obscurity: the way that E-mail passwords are stored
on disk is not documented. If security through obscurity worked
perfectly in this case, it would mean that people would only be able
to use the E-mail password by running netscape. Accessing E-mail
using the password would still be trivial. Actually getting the
password would be harder. Allowing for the inevitable MS Windows
crash, it might take a pair of knowledgeable people a few hours to run
netscape and capture the E-mail password it sends out.
"Security through obscurity" is insecure, so McGraw's report that it
took a pair of people eight hours to figure out how netscape stores
E-mail passwords on disk is no big surprise. Since this is longer
than the expected time to obtain the password just by running the
program, it appears that in this case, security through obscurity has
provided the (minimal) level of security expected of it.
According to the RST web
Cryptography-Digest Digest #776
Cryptography-Digest Digest #776, Volume #9 Fri, 25 Jun 99 17:13:03 EDT Contents: Re: Kryptos article (Jim Gillogly) Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (DJohn37050) Re: one time pad (AllanW) Re: Bytes of "truly random" data for PRNG seed. (Terry Ritter) Re: RC4 Susectability ([EMAIL PROTECTED]) Re: DES-NULL attack ([EMAIL PROTECTED]) sha-1 C/C++ source code ([EMAIL PROTECTED]) Re: one time pad (AllanW) Re: Tough crypt question: how to break ATT's monopoly??? ([EMAIL PROTECTED]) How does 3DES work? ([EMAIL PROTECTED]) Re: Converting arbitrary bit sequences into plain English texts (wtshaw) Re: Kryptos article (Jim Gillogly) Re: Bytes of "truly random" data for PRNG seed. (David A Molnar) Re: "Breaking" a cipher ([EMAIL PROTECTED]) Re: one time pad (John Myre) Re: Converting arbitrary bit sequences into plain English texts (wtshaw) Re: DES-NULL attack ([EMAIL PROTECTED]) Re: Converting arbitrary bit sequences into plain English texts (wtshaw) From: Jim Gillogly [EMAIL PROTECTED] Subject: Re: Kryptos article Date: Fri, 25 Jun 1999 12:16:32 -0700 Lincoln Yeoh wrote: http://www.odci.gov/cia/information/tour/krypt.html Is that a hole on the lower right? And is that where we're supposed to dig or look inside? It's a pool of water. I suspect if you stand a bit closer it would reflect the Vigenere table that's cut through the copper panels on the right; we're seeing them reversed, so presumably the pool will straighten them out for us. Is there another pool on the concave side of the cipher panels? -- Jim Gillogly 2 Afterlithe S.R. 1999, 19:14 12.19.6.5.10, 1 Oc 18 Zotz, Second Lord of Night -- From: [EMAIL PROTECTED] (DJohn37050) Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? Date: 25 Jun 1999 19:05:12 GMT Here is an advantage of ECC over other methods, the domain parameters are public, so one can use a Koblitz curve with a random curve as a backup. Note that this may entail NO change to the key generation code, if it allows selection of domain parameters. So one can get the benefits of Koblitz today, and if someone somehow finds out they are weaker than now thought, can switch to a random curve. Don Johnson -- From: AllanW [EMAIL PROTECTED] Subject: Re: one time pad Date: Fri, 25 Jun 1999 18:35:43 GMT [EMAIL PROTECTED] (Terry Ritter) wrote: Were it possible to tell whether sequence s + '0' was more random than s + '1', we could produce the one sequence which was most random. But everybody would know that sequence so it would be useless for cryptography. Heh heh, I like that. It's kind of like, "Give me a list of all well-known patterns, and then find the one that is least well-known!" The answer depends on the quality of the first list. The whole point of crypto random is the hope that it is not possible to know what the sequence will be. Right. Common RNG tests wouldn't be of any use, if they didn't check for known problems that make the next character in a sequence too easy to guess. For instance, we use frequency graphs to prove that each possible output byte is generated approximately the correct number of times. If we found that the byte value '0' was output only half as often as the odds predict it should be, we would call that a weakness because an attacker would rarely guess 0. -- [EMAIL PROTECTED] is a "Spam Magnet," never read. Please reply in newsgroups only, sorry. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. -- From: [EMAIL PROTECTED] (Terry Ritter) Subject: Re: Bytes of "truly random" data for PRNG seed. Date: Fri, 25 Jun 1999 18:38:20 GMT On Fri, 25 Jun 1999 12:49:24 GMT, in [EMAIL PROTECTED], in sci.crypt "Douglas A. Gwyn" [EMAIL PROTECTED] wrote: fungus wrote: The Blum Blum Shub I mentioned earlier is supposed to be "provably good" but I have to confess I don't know much about the algorithm or how the proof works. It's just iterated squaring (starting with a random seed) modulo a product of two large primes (each of which is congruent to 3 mod 4). The claim that BBS is "cryptographically strong" is based on the difficulty of factoring, which of course is a field that has seen rapid progress.. Actually, there is more to a real BBS system. See: 20. Blum, L., M. Blum and M. Shub. 1983. Comparison of Two Pseudo-Random Number Generators. Advances in Cryptology: CRYPTO '82 Proceedings. Plenum Press: New York. 61-78. 21. Blum, L., M. Blum and M. Shub. 1986. A Simple Unpredictable Pseudo-Random Number Generator. SIAM Journal on Computing. 15: 364-383. One issue is that BBS primes are "special." Another issue is that t
