Cryptography-Digest Digest #771
Cryptography-Digest Digest #771, Volume #12 Mon, 25 Sep 00 15:13:00 EDT
Contents:
Re: Why is TwoFish better than Blowfish? (Paul Schlyter)
Re: Big CRC polynomials? ("Kasper Pedersen")
Letter substitution decoder (mls)
Re: Software patents are evil. (Jerry Coffin)
Re: Software patents are evil. (Jerry Coffin)
Re: CDMA tracking (was Re: GSM tracking) (mls)
Re: 128-bit Secure LFSR ("Cristiano")
Re: What am I missing? ("Joseph Ashwood")
sigh, AES (dbt)
Re: Tying Up Loose Ends - Correction (Bryan Olson)
Re: sigh, AES (Quisquater)
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Why is TwoFish better than Blowfish?
Date: 25 Sep 2000 19:08:05 +0200
In article [EMAIL PROTECTED],
SCOTT19U.ZIP_GUY [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Runu Knips) wrote in
[EMAIL PROTECTED]:
Tom St Denis wrote:
In article [EMAIL PROTECTED],
Albert Yang [EMAIL PROTECTED] wrote:
"David C. Barber" wrote:
TwoFish is newer, and I would think better, than BlowFish (unless
the AES requirements required a worse cipher), but I've never see
n a list of reasons just why.
In fact, the main reason why Twofish is better than Blowfish is NOT
improved security. Blowfish is a pc cipher, and Twofish is a general
cipher. Twofish offers key agility, while Blowfish doesn't. Twofish
can be implemented in relatively slow resource environments, while
Blowfish always require 4KB of key schedule data.
Having known people who know the man who designed blow fish or
two fish leads me to believe both ciphers are most likely broken by
the NSA before they were introduced to the public. At least these
are my feelings about these fishy ciphers. It seems like NSA humour
to give both ciphers FISHY names.
But since the idea of a cipher is security. It is plain stupid to
say Twofish is better than Blowfish becasue Blowfish is a PC cipher.
If one has a PC and is sending messages to someone with a PC then why
use a cipher that could becasue of its ability to be run on many machines
would ecpoxe it to more attacks.
If you don't want the cipher to be exposed, you should definitely not
implement it on PC's, since they are around everywhere. The number of
PC's in the world is only somewhat smaller than the number of computers
of any kind.
Also: designing a piece of software to be non-portable is generally
not a good idea.
Even if they algoritmically had
the same level security which can't be proved anyway.
--
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se orpaul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pauschhttp://welcome.to/pausch
--
From: "Kasper Pedersen" [EMAIL PROTECTED]
Subject: Re: Big CRC polynomials?
Date: Mon, 25 Sep 2000 20:23:35 +0200
"Scott Fluhrer" [EMAIL PROTECTED] wrote in message
news:8qnm41$a56$[EMAIL PROTECTED]...
Errr, no. As I demonstrated on another thread (I'll restate the proof if
you're interested), no CRC-like algorithm that has a finite output, and
works on arbitrarily long inputs can catch all 2 bit errors.
"will always catch n errors within a window of length m"
I did not state that m could be arbitrarily large. Of course, when your
message size (specifically the size of the payload that can contain errors)
exceeds m of the chosen polynomia, you're in the weeds.
Again: A properly chosen example polynomia can detect 2 errors within a 64
bit window with 100% certainty, and any number of errors within an 8 bit
window.
A bytewise XOR sum can detect any number of errors within a 8 bit window
too, but not always 2 errors within a 64 bit window.
I DO NOT claim that any CRC will catch all 2 bit errors in an arbitrarily
sized window.
/Kasper
--
From: mls
Subject: Letter substitution decoder
Date: Mon, 25 Sep 2000 18:34:24 GMT
No, not Captain Marvel, but am looking for a program that will try all
possible letter substitution combinations, with small library of
plaintext for matching. Maybe even in BASIC.
Assumes that the text to be decrypted is simple substitution and not
one time pad.
Anyone know of such an .exe? (Oakland is down, winfiles has
nothing...)
Thanx,
m shannon
mls at fusionsites dot com
--
From: Jerry Coffin [EMAIL PROTECTED]
Subject: Re: Software patents are evil.
Date: Mon, 25 Sep 2000 12:30:36 -0600
In article 8qlr47$5j7$[EMAIL PROTECTED],
[EMAIL PROTECTED] says...
In [EMAIL PROTECTED] Darren New [EMAIL PROTECTED] writes:
Then you need to read my post again. We were selling the product for three
years. Then someone else applied for a patent, and it was cheaper to license
than fight. That, I would say, is br
Cryptography-Digest Digest #771
Cryptography-Digest Digest #771, Volume #11 Sun, 14 May 00 16:13:01 EDT
Contents:
Re: UK issue; How to determine if a file contains encrypted data? (wtshaw)
Re: Patentability of an innovation ... ("C. Prichard")
Re: Notes on the "Vortex" block cipher (Bruce Schneier)
Re: Notes on the "Vortex" block cipher ("Scott Fluhrer")
Re: Encryption of graphics by transposition (wtshaw)
Re: Encryption of graphics by transposition (Tom St Denis)
Hello All Mathamatics Question (Nemo psj)
Re: About Hardware RNG (Guy Macon)
Notes on the Pikachu cipher ([EMAIL PROTECTED])
Re: Notes on the "Vortex" block cipher ([EMAIL PROTECTED])
Re: AES Comment: the Hitachi patent (Mok-Kong Shen)
Re: Question regarding authentication implementation (Abid Farooqui)
Re: Notes on the Pikachu cipher (Tom St Denis)
Re: Hello All Mathamatics Question (Tom St Denis)
Re: Notes on the "Vortex" block cipher (Tom St Denis)
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: UK issue; How to determine if a file contains encrypted data?
Date: Sun, 14 May 2000 09:43:49 -0600
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Beyond the UK, in countries where the simple possession of an
encryption app might result in incarceration or even torture without
trial, I suspect an app that is itself hidden would be a decided
advantage. Especially since with the growing complexity of OSs, use
of caches, registry keys, etc etc, it is getting beyond the capacity
of all but the most sophisticated users to hide or remove all traces
of an app. and its use.
I love it...in frustration of not knowing all about how an OS works, you
see that bad turns to worse, sour moves to bitter, but you don't have to
be subject to undue complications to do a simple thing like hiding a
program. Actually, if all the tools of knowledge about an OS are
available, countless ways to do unlimited creative things are possible;
trivial hiding is easy then, if you choose that route. Don't get bought
off by threats of terminal mismanagement and pleas to justify darkness and
snoopervision by people whose greatest mission is to keep you as a dumb,
begging sucker, ...and, their calloused succor.
--
Secrets that are told or availabe are not secrets anymore, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
--
From: "C. Prichard" [EMAIL PROTECTED]
Subject: Re: Patentability of an innovation ...
Date: Sun, 14 May 2000 16:28:40 GMT
FYI:
The 'CipherText' U.S. patent application is claiming that the use of an =
LRC-like checksum that involves all characters of the key to control its =
modified key rotation, is a novel innovation in cryptology. Serious =
implementation of the feature will likely see straight added sum and LRC =
values combined, however an LRC value seems to work well.
CipherText is a pseudo blocking cipher that has a data-dependent shift =
and has been optimized for Page Tag Encryption. It now exists in a Perl =
class module and has a new ASCII filter feature.
Thanks for the research Bruce.
Regards,
Charles Prichard
www.greentv.com
Bruce Schneier [EMAIL PROTECTED] wrote in message =
news:[EMAIL PROTECTED]...
I just sent this comment to NIST:
=20
Bruce
=20
=20
Hitachi has two U.S. patents, numbers 4,982,429 and 5,103,479, each of
which is purported to cover "any" encryption system using rotations.
These patents were filed in 1988. All of the five AES candidates use
some kind of rotation, including Rijndael's ShiftRow operation.
However, for what it's worth, it should be noted that Twofish can be
implemented as a "straight Feistel cipher plus a final permutation,
with rotations applied only within the round function, not in the
Feistel XOR path.=20
=20
The authors of Twofish were unaware of these patents until recently,
but the notion that such a broad claim could be valid seems quite
ludicrous. he following well-known pieces of prior art would seem to
at least dramatically limit the scope (if not completely invalidate)
any such claims.
=20
1) FEAL (1987) uses a rotation in its round function.
=20
2) Madryga (1984) uses a variable rotation in its round function.
=20
3) DES (1977) uses a rotation in each round of its key schedule.
=20
4) DES (1977) uses a bit permutation (of which rotations are a
special case) in every round.
=20
5) GOST (1989) applies a bit permutation (that is a rotation) in
each round after performing its S-box lookup
=20
6) The very words "rotor" and encryption have been linked for a long
time (e.g., the Caesar cipher, and Enigma)
=20
The concept of rotation in encryption was clearly neither novel nor
unobvious at time thes
Cryptography-Digest Digest #771
Cryptography-Digest Digest #771, Volume #10 Mon, 20 Dec 99 01:13:01 EST
Contents:
Re: S-Box evolution (lordcow77)
Re: compression encryption (lordcow77)
Re: S-Box evolution (Scott Fluhrer)
I was wrong and I apologize (Was: SRP - a secure alternative for authentication
Nice reading) ("rosi")
Re: S-Box evolution (Scott Fluhrer)
Re: Keystrokes monitored/encryption useless (molypoly)
simple rng idea (Tom St Denis)
Re: simple rng idea (Tom St Denis)
Re: Cryptanalysis (David Hopwood)
From: lordcow77 [EMAIL PROTECTED]
Subject: Re: S-Box evolution
Date: Sun, 19 Dec 1999 20:12:35 -0800
In the version of sbox.c that I have (last modified June 2 1998) found
on the original AES CD, the min is initialized to an absurdly high
value (ie. 1) considering that it should represent the single-bit
correlation of the S-box. Later, in the segment
new = correlation(sbox,tests);
if (new min) {
if (!fail(sbox,tests)) {
memcpy((char *)best, (char *)sbox, sizeof(best));
memcpy((char *)besttests, (char *)tests,
sizeof(besttests));
*if (min .55) /* I changed this */
showbest(j+1,failures,j,best,besttests);
min = new;
The comparison in line marked by the stars is incorrect and can never
fire before min is ABOVE some other absurdly high number 100. I'll
have to dig up the code if you want more details. Rather odd.
In article 83k52u$6po$[EMAIL PROTECTED],
[EMAIL PROTECTED] (David Wagner) wrote:
In article [EMAIL PROTECTED],
lordcow77 [EMAIL PROTECTED] wrote:
Flaw detection isn't unfeasible if the S-box is reasonably
large. The
AES candidate MARS has a program for generating and testing 8x32
S-boxes, although it does take quite a long time to find one and
there
are some bugs in the code.
Can you say anything more about the bugs in the MARS S-box testing
code?
Any details, descriptions of the buggy cases, etc. would be very
interesting.
Thanks!
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
--
From: lordcow77 [EMAIL PROTECTED]
Subject: Re: compression encryption
Date: Sun, 19 Dec 1999 20:15:58 -0800
Show me a modern block cipher so throughly broken that one can use
known-plaintext characteristics of the first two bytes of the block to
reduce the keysearch space and I'll show you a block cipher that one
should never use. Or better yet, give me an ACTUAL EXAMPLE of such an
"attack" on any reasonable block cipher construction, even a badly
broken one like FEAL-4.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
--
From: Scott Fluhrer [EMAIL PROTECTED]
Subject: Re: S-Box evolution
Date: Mon, 20 Dec 1999 04:54:34 GMT
In article [EMAIL PROTECTED],
Tim Tyler [EMAIL PROTECTED] wrote:
Doing things dynamically with your s-boxes /may/ mean too much work
at runtime - given the set of constraints s-boxes usually have to
operate under.
And it depends a bit on the design of the rest of the cipher. If
the design is such that a straight-forward implementation of the
sbox is a simple array is practical, then tweaking it on the fly
may be workable.
(To the OP): Remember, however, that changing the sbox also takes
time which needs to be included when computing the time-to-encrypt.
So, you need to show (or assume) that having a dynamically varying
sbox allows you to simplify (speed up) the cipher enough to justify
adding in the modify-sbox code
/Perhaps/ cycling through a predetermined list would be enough for
whatever security benefits you're trying to obtain.
Actually, this strikes me as even worse than having a single fixed
(well chosen) one -- the attacker can attack all of them in parallel,
and so the strength of the cipher is the strength of your *weakest*
sbox.
--
poncho
--
From: "rosi" [EMAIL PROTECTED]
Subject: I was wrong and I apologize (Was: SRP - a secure alternative for
authentication Nice reading)
Date: Mon, 20 Dec 1999 00:10:11 -0500
(Please see NOTE at end, if interested, for reason why
this is not attached to the appropriate thread)
Dear Tom,
Thank you very much for the post.
My reply has six parts:
1. Apologies
2. A few words about my confusion
3. Questions concerning the patent status of SRP
4. Mind your s's and v's
5. EZK
6. Seeking interest in Quasi-Public Keying
Of the 6, only 1 is relavent. Others are for other purposes
(lumped in one post instead of several due to lazy habit :)).
1. Apologies
First and foremost, I apologize for my confusion which
must have confused many others. As you pointed out
Cryptography-Digest Digest #771
Cryptography-Digest Digest #771, Volume #9 Fri, 25 Jun 99 09:13:05 EDT Contents: Cryptography FAQ (06/10: Public Key Cryptography) ([EMAIL PROTECTED]) Cryptography FAQ (07/10: Digital Signatures) ([EMAIL PROTECTED]) From: [EMAIL PROTECTED] Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers Subject: Cryptography FAQ (06/10: Public Key Cryptography) Date: 25 Jun 1999 13:04:08 GMT Reply-To: [EMAIL PROTECTED] Archive-name: cryptography-faq/part06 Last-modified: 94/06/07 This is the sixth of ten parts of the sci.crypt FAQ. The parts are mostly independent, but you should read the first part before the rest. We don't have the time to send out missing parts by mail, so don't ask. Notes such as ``[KAH67]'' refer to the reference list in the last part. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, sci.answers, and news.answers every 21 days. Contents: 6.1. What is public-key cryptography? 6.2. How does public-key cryptography solve cryptography's Catch-22? 6.3. What is the role of the `trapdoor function' in public key schemes? 6.4. What is the role of the `session key' in public key schemes? 6.5. What's RSA? 6.6. Is RSA secure? 6.7. What's the difference between the RSA and Diffie-Hellman schemes? 6.8. What is `authentication' and the `key distribution problem'? 6.9. How fast can people factor numbers? 6.10. What about other public-key cryptosystems? 6.11. What is the `RSA Factoring Challenge?' 6.1. What is public-key cryptography? In a classic cryptosystem, we have encryption functions E_K and decryption functions D_K such that D_K(E_K(P)) = P for any plaintext P. In a public-key cryptosystem, E_K can be easily computed from some ``public key'' X which in turn is computed from K. X is published, so that anyone can encrypt messages. If decryption D_K cannot be easily computed from public key X without knowledge of private key K, but readily with knowledge of K, then only the person who generated K can decrypt messages. That's the essence of public-key cryptography, introduced by Diffie and Hellman in 1976. This document describes only the rudiments of public key cryptography. There is an extensive literature on security models for public-key cryptography, applications of public-key cryptography, other applications of the mathematical technology behind public-key cryptography, and so on; consult the references at the end for more refined and thorough presentations. 6.2. How does public-key cryptography solve cryptography's Catch-22? In a classic cryptosystem, if you want your friends to be able to send secret messages to you, you have to make sure nobody other than them sees the key K. In a public-key cryptosystem, you just publish X, and you don't have to worry about spies. Hence public key cryptography `solves' one of the most vexing problems of all prior cryptography: the necessity of establishing a secure channel for the exchange of the key. To establish a secure channel one uses cryptography, but private key cryptography requires a secure channel! In resolving the dilemma, public key cryptography has been considered by many to be a `revolutionary technology,' representing a breakthrough that makes routine communication encryption practical and potentially ubiquitous. 6.3. What is the role of the `trapdoor function' in public key schemes? Intrinsic to public key cryptography is a `trapdoor function' D_K with the properties that computation in one direction (encryption, E_K) is easy and in the other is virtually impossible (attack, determining P from encryption E_K(P) and public key X). Furthermore, it has the special property that the reversal of the computation (decryption, D_K) is again tractable if the private key K is known. 6.4. What is the role of the `session key' in public key schemes? In virtually all public key systems, the encryption and decryption times are very lengthy compared to other block-oriented algorithms such as DES for equivalent data sizes. Therefore in most implementations of public-key systems, a temporary, random `session key' of much smaller length than the message is generated for each message and alone encrypted by the public key algorithm. The message is actually encrypted using a faster private key algorithm with the session key. At the receiver side, the session key is decrypted using the public-key algorithms and the recovered `plaintext' key is used to decrypt the message. The session key approach blurs the distinction between `keys' and `messages' -- in the scheme, the message includes the key, and the key itself is treated as an encryptable `message
