Cryptography-Digest Digest #590, Volume #10 Fri, 19 Nov 99 09:13:03 EST
Contents:
Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
Re: NSA should do a cryptoanalysis of AES (Doug Stell)
Re: AES cyphers leak information like sieves (Jerry Coffin)
Re: Group English 1-1 all file compressor (William Rowden)
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: Backdoor Tactic (Johnny Bravo)
Re: more about the random number generator (Scott Nelson)
Re: Backdoor Tactic (Guy Macon)
Re: AES cyphers leak information like sieves (Volker Hetzer)
A Random Key Cipher Machine (Mark Adkins)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 19 Nov 1999 05:02:37 GMT
In article <812dar$p0q$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <811eqh$39q$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
> >In article <811236$2ija$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote
> >> are you a complete fool where did you get such a rediculus
number.
> >> Are you stuoid enough to think that the number 26 is a binary
number.
> >> You really are full of shit Mr Tom. Each wheel is a specail
arrangement
> >> of 26 characters and don't forget the plug borad in the front of
machine.
> >
> >
> >Let's do some math review for the newbie here. 26 positions per wheel
> >gets you 26^x = 2^128, therefore x = log26(2^128) = ~28
> >
> >Sorry if this is too complex for the mastermind behind scottu
ciphers...
> >
> >Tom
> >
>
> Well Tom I have to admit I have no idea what you are trying to do.
> Maybe you can tell me how big my key should have been for scott4u
> which is like wiring up a wheel with only 16 character instead of the
> 26 as in an engima wheel. Maybe you found something. But I doubt it.
I messed up the math. Sorry. [see my post 'rotors'].
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Thu, 18 Nov 1999 23:52:40 GMT
On Thu, 18 Nov 1999 13:23:51 GMT, [EMAIL PROTECTED] wrote:
>I think one of the issues relating to this is trust. When Clipper was
>announced by the NSA and they tried to make people use it, did anybody
>really trust it? No. If the NSA were to create an algorithm and enter
>it in AES, I think everyone would be wary.
Perception counts for a lot.
The Clipper algorithms, SKIPJACK and KEA, are held in suspect, because
of how Clipper used them. However, SKIPJACK is probably a good
algorithm, because it is used in other Type 2 applications when its
strength is expected to be consistent with its key length. Likewise,
the corresponding key agreement algorithm, KEA, is a perfectly sound
algorithm and is used in similar circumstances, often along with
SKIPJACK
For two decades, we seriously wondered if NSA strengthened or weakened
DES by their involvement. We now know that they made it as strong as
it can be, given the key size they imposed upon it.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: AES cyphers leak information like sieves
Date: Thu, 18 Nov 1999 23:10:07 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> I'm not certain, but I have difficulty in imagining a "chaining mode"
> of a block cypher that produces very much diffusion of information
> between blocks. If using a fixed size, small block block cypher, you
> should probably applu diffusion to your message first.
Keep in mind that ScottXXu (for one example) is really a block cipher
with quite a small block size, the uses a chaining mode to get the
effect of treating the entire file as a single large block (in at
least some respects).
[ ... ]
> Hell, if it's really important, *and* there's no chance to retransmit it,
> *and* the channel is really noisy, *and* the bandwidth is so limited you
> can apply little error correction,
[ ... ]
Let's face reality: you're ultimately talking about one fairly
specific situation, while AES isn't. You're basically talking about
how to design a complete secure system for use almost exclusively in a
single set of circumstances: sending messages over the Internet. If
it makes you happy to hear somebody say that using AES, (or any AES
finalist) all by itself is insufficient to ensure secure
communications in this environment, and that it's possible to improve
on that, I (for one) have no hesitation in agreeing.
At the same time, I'll ask that YOU keep in mind that AES is intended
to be one (relatively small) piece in a relatively large puzzle. AES
is intended purely and only as an encryption algorithm, nothing more.
In some situations, (as I've said before) it makes sense to use it
without a chaining mode (I.e. in ECB mode). In most situations, it's
preferable to use a chaining mode. Along with the solicitation for
algorithms, if you'd bothered to read through the AES web page, you'd
have noticed that the NIST is also actively seeking comments about
chaining modes. They've listed off the chaining modes approved for
use with DES, give a link to the FIPS pub describing them in more
detail, and ask for comments suggesting whether others should be
added, etc. If you (for example) think a chaining mode should be
added that's similar (or identical) to David Scott's wrapped PCBC
mode, I'm sure they'd welcome a comment to that effect.
At the same time, please at least attempt to remain aware that it's
unlikely to EVER be the sole chaining mode approved or in use. There
are simply too many situations in which it's completely unusable for
it to become anywhere close to universal. I've already given one sort
of situation in which its use in contraindicated. Another obvious
area is in things like network cards that work with data streams
instead of relatively high level constructs such as files. At most,
these could using chaining between the blocks of a single frame. In a
minimum Ethernet or ATM frame (for a couple of VERY widely used
examples) they'd have to add padding to even have TWO blocks to chain
together.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: William Rowden <[EMAIL PROTECTED]>
Subject: Re: Group English 1-1 all file compressor
Date: Fri, 19 Nov 1999 07:08:20 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Tim Tyler <[EMAIL PROTECTED]> wrote:
> : SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> : : As for Tim rules about strings I think he is correct but one
> : : could use multiplu dictionarys.
[snip]
> "this is his head" would never compress very well, using a type
> of dictionary with trailing punctuation - the type I believe will
> work best.
>
> However, if you allow multiple passes, the problem vanishes ;-)
>
> Dictionary 1: "this " <--> "#"
> Dictionary 2: "his" <--> "^"
> Dictionary 3: "is " <--> "@"
>
> ...produces:
>
> "this is his head" -1-> "#is his head" -2-> "#is ^head" -3-> "#@^head"
IIRC, David's concept of a "1-1" compressor means that every file is a
valid compressed file. The idea is to make it impossible to
decompress, recompress, and compare to the original file as a way of
eliminating invalid plaintexts. Right? A side benefit would be
efficient use of the compression function's codomain.
The example above does not have this property: "t^" decompresses to
"this" but recompresses to "#". The other example had the same
problem. Did David change his mind in a thread I haven't read? Perhaps
you could point me to the pertinent posts.
--
-William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 19 Nov 1999 02:33:09 GMT
On Fri, 19 Nov 1999 01:15:18 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> Obviously I know more about it that you no wonder you don't
>know shit about crypto.
>
>David A. Scott
You're the moron who attacked someone because you couldn't figure
you that 28 wheels with 26 positions for each had more than 2^128
starting states. Then you state
" Well Tom I have to admit I have no idea what you are trying to do."
If you had no idea what he was talking about, why did you feel the
need to attack him in that manner. Your lashing out against anything
you don't understand explains much of your conduct on this newsgroup,
and against other crypto systems. It is apparent you don't understand
much.
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 19 Nov 1999 03:03:45 GMT
On Fri, 19 Nov 1999 00:59:10 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>> The standard version (at least at first) used 3 of 5 wheels, each
>>with 26 settings, that's a total initial setting of 1054560 possible
>>positions or just about 20 bits exactly.
>> Near the end of the war (naval enigma) they were up to 4 out of 8
>>wheels for about 29.5 bits worth of starting positions.
>> A standard desktop computer can decrypt an enigma message in less
>>than 15 mins due to properties of the cipher itself (like no letter is
>>ever encrypted as itself for example).
>>
>> Best Wishes,
>> Johnny Bravo
>>
> Dear Johnny what you have caluculated is based on fixed wheels
Rewiring the wheels would not change the number of settings that the
machine could be set to. I said nothing about the total number of
variations possible, though it would be trivial to calculate but
useless, as the Germans did not provide the ability for the users to
rewire the wheels. They just added more wheels to the set (it ended
up at eight for the navy), then added the plugboard, which is
esentially a programmable wheel to the mix, though it was commonly
used with only 20 letters switched, leaving 6 letters the same.
>You are not considering the possible variations of the Wheel itself.
I didn't bother to calculate them as it wasn't used in the Enigma.
But for the 3 wheel army Enigma allowing for the plugboard (and
allowing for unswitched letters), the 60 possible wheel orderings, and
the 17,576 initial states of the three wheels; the standard plugboard
Enigma had about 1.59e20 possible initial states, which is still only
over 67 bits. The naval version by the end of the war with 4 wheels
out of a set of 8, and the plugboard had about 1.15e23
states that only brought the total up just over 76.5 bits.
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Backdoor Tactic
Date: Fri, 19 Nov 1999 03:28:04 GMT
On 19 Nov 1999 00:43:42 GMT, [EMAIL PROTECTED] (UBCHI2) wrote:
>Anyone ever wonder why the commercial encryption programs always leave a tag on
>the messages. They also won't permit you to decipher a message unless the tag
>stays attached. Examples
>
>Encrypted with PGP v6.0 or Encrypted with Norton For Your Eyes Only.
>
>I challenge the readers of this message to identify a single commercial
>encryption product that does not leave a plaintext tag or one that permits you
>to decrypt without the tag.
It is possible in PGP to cut off the header, stick a stock header on
at the far end and decrypt the message. Otherwise steganography would
be pretty useless if you have a readable PGP header hidden in your
.wav file. Why bother to use a commercial product if you are that
paranoid?
Write your own instead, if you have even rudimentary programming
skills (you have to look up a statement to print to the screen) you
should be able to pound it out in under a week. If you have fair
skills (you have to look up the statements to print to a file), make
that a day. If you know your programming stuff, you should be able to
do it in less than 15 minutes. For your work you get 440 bit
encryption with a proven track record, you can up that to 1968 bits if
you add one looping statement to the program.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: more about the random number generator
Reply-To: [EMAIL PROTECTED]
Date: Fri, 19 Nov 1999 09:07:57 GMT
On Thu, 18 Nov 1999 15:54:37 GMT, William Rowden <[EMAIL PROTECTED]>
wrote:
>In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]>
>wrote:
>> Tom St Denis wrote:
>[snip]
>> > Serial correlation coefficient is 0.001254 (totally uncorrelated =
>> > 0.0).
>>
>> This looks like the test that checks the number of d-grams. Can
>> someone comment?
>
>I assumed this was a simple autocorrelation statistic for a shift of d =
>1, if that's what you mean. Perhaps Scott Nelson, who has examined the
>source, could verify this. If my guess is correct, the program would
>probably sum the result of XOR on bits separated by some d less than 1/2
>the total number of bits (maybe 1). Has anyone looked at this portion
>of the code?
>
Looks like Ent's "serial correlation" is derived from;
N = number of values
scct1 = sum (val[i] * val[i+1]) for i=1 to N ;val[N+1] = val[1]
scct2 = square ( sum (val[i]) for i=1 to N )
scct3 = sum (val[i] * val[i]) for i=1 to N
scc = (N * scct1 - scct2) / (N * scct3 - scct2)
I don't recognize the formula, but it's range seems
to be between -1 and 1. If the values were random
and the sample was large, scc would be very close to 0.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Backdoor Tactic
Date: 19 Nov 1999 01:03:21 PST
In article <812cvt$p0q$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
wrote:
>
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(UBCHI2) wrote:
>>Anyone ever wonder why the commercial encryption programs always leave a tag on
>>the messages. They also won't permit you to decipher a message unless the tag
>>stays attached. Examples
>>
>>Encrypted with PGP v6.0 or Encrypted with Norton For Your Eyes Only.
>>
>>I challenge the readers of this message to identify a single commercial
>>encryption product that does not leave a plaintext tag or one that permits you
>>to decrypt without the tag.
>
> Well scott16u and scott19u leave no tags or traces you even have
>the option of encryption without the file size changing.
>
>>
>>This insures the cryptanalyst that even if you superencipher your message, he
>>will have known plaintext. In the worst possible case for the truly paranoid,
>>the tags insure that the snoopers know which basket of keys to use depending
>>upon product.
Although "security by obscurity" is a poor way to protect data, it
seems to be a worthwhile addition to an already strong system.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Fri, 19 Nov 1999 10:25:23 +0100
Tim Tyler wrote:
> I would say that (at least in the case of CBC mode chaining) it does
> change the security. The failure to distribute the information in the
> plaintext throughout the cyphertext allows types of analysis which would
> otherwise be impossible. For example, a partial plaintext may offer
> complete knowledge about a number of blocks of cyphertext. This would
> never happen if proper diffusion had taken place - unless the entire
> plaintext were known.
Okay, let's try a different approach:
Assume CBC.
Assume, the best way to find the key, given a plaintext/ciphertext pair is brute
forcing the underlying block cipher.
Assume, you've got knowledge of the first block (the IV).
Now, does this knowledge help you to find an attack better than brute force on
the first message block?
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
Date: Fri, 19 Nov 1999 07:13:03 -0500 (EST)
From: Mark Adkins <[EMAIL PROTECTED]>
Subject: A Random Key Cipher Machine
Here's an idea for a random key scheme applicable to
cryptographic machines.
First, all cipher machines (which are to be compatible) must
be equipped with their own independent, secure, and reliable
electrical sine wave generators, with appropriate backups and
safeguards to insure that the waves generated are not
corrupted beyond specified tolerances.
When an operator types a plaintext key for conversion into
ciphertext, several things happen. The amplitude of the sine
wave at that moment is sampled. A device built into the
machine takes this sampled amplitude and compares it to a
preexisting table implemented electronically in the device.
This table, which is programmable, divides the amplitude
range of the sine wave generator into 26 discrete
sections. Each section corresponds in the programmable table
to one of the 26 letters of the Roman alphabet. (If the
amplitude is too close to a border region at the time of
initial sampling a second sample is immediately taken (within
microseconds). Note that the speed of the sine wave amplitude
changes is designed to preclude consecutive keystrokes from
corresponding to consecutive sample sections. In fact, if
the frequency of the sine wave generator were sufficiently fast,
even the smallest variations in keystroke rhythms (by a single
operator) would be randomized.
This provides a random key letter which is then used
automatically to encode the plaintext letter typed and
thus to generate a ciphertext letter.
At the same time, the particular amplitude sampled for
this letter is recorded according to some predetermined
(but also programmably variable) digital code.
When the ciphertext is transmitted, the sequence of digital
codes indicating the amplitudes corresponding to each letter
is also transmitted. (Note that this digital code sequence
might be shortened by using a compression algorithm.) The
digital codes for the amplitudes would be woven into the
transmitted ciphertext signal in an arbitrary but standardized
fashion common to all cipher machines of this model. (This
standardization could accomodate a wide variety of weaving
schemes, however, provided the transmitting device appended
a digital code indicating to the receiving device which
scheme was used.)
The machine at the other end used for deciphering will unmix
the two elements of the signal according to the standard scheme,
and then use the programmed table (which can be changed as often
as desired) to convert the digital amplitude codes into key
letters, which are then used to recreate the plaintext message
from the ciphertext. Note that the sine wave generator is used
only for encipherment and that the two generators (at the
encrypting and decrypting ends) therefore need not be
synchronized.
Ideally both the ciphertext and the amplitude codes should
be digitally recorded (e.g., on a recordable CD) automatically
as the plaintext message is typed into the cipher machine by
an operator. When done, the machine would take these and
generate a hash code (also appended to the message to be
transmitted) which would insure that the message received was
the same as the message sent.
The actual transmission of the final cipher should also be
automatic: simply put the CD into the radio transmission
device and press a button. The receiving device would first
generate the hash code from the received message according to
the same scheme. If this did not match the hash code sent with
the ciphertext, the message would be resent, but with the
following twist: the transmitting device would automatically
reencipher the ciphertext according to a straightforward
prearranged scheme. This fact would be indicated to the
receiving device by an appended digital code (included in
every transmitted message and thus reflected in the hash
code) indicating how many previous transmission attempts
had occurred for this message.
The radio receiving device would then apply the appropriate
second-level decipherment algorithm to the successfully received
message (assuming that the second sending was successful) before
the first-level encrypted ciphertext was passed on to the
operator of the cipher machine for deciphering. (Decipherment
would occur simply by inserting the CD created by the radio
receiver device into the decryption device and pushing a button.)
--
Posted for my own amusement, since you are all figments.
Mark Adkins ([EMAIL PROTECTED])
------------------------------
** 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
******************************
