Cryptography-Digest Digest #832, Volume #9 Mon, 5 Jul 99 14:13:03 EDT
Contents:
re: AES public comments from the Rijndael Team ([EMAIL PROTECTED])
Re: The One-Time Pad Paradox ("Dr.Gunter Abend")
Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: The One-Time Pad Paradox ("Dr.Gunter Abend")
Re: The One-Time Pad Paradox (Mok-Kong Shen)
Re: I don't trust my sysadmin ([EMAIL PROTECTED])
Re: Why this simmetric algorithm is not good? (Nicol So)
Re: Crypto Books on CD-ROM (John Savard)
Re: Crypto Books on CD-ROM (John Savard)
Re: Why this simmetric algorithm is not good? (John Savard)
Re: Why this simmetric algorithm is not good? (John Savard)
Re: Why this simmetric algorithm is not good? (Francois Grieu)
Re: Crypto Books on CD-ROM (Wil Baden)
Re: Summary of 2 threads on legal ways of exporting strong crypto (Mok-Kong Shen)
Re: Summary of 2 threads on legal ways of exporting strong crypto ([EMAIL PROTECTED])
Re: Standard Hash usage (Keith A Monahan)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: re: AES public comments from the Rijndael Team
Date: Mon, 05 Jul 1999 11:35:38 GMT
One comment they note that only theirs and HPC is suited for hashes
>128 bits. However RC6 is well suited if 64-bit words are available.
I think they should revise their statement to include this. On a ALPHA
for example the 64-bit version would actually be faster then the 32-bit
one...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Dr.Gunter Abend" <[EMAIL PROTECTED]>
Subject: Re: The One-Time Pad Paradox
Date: Mon, 05 Jul 1999 15:51:35 +0200
Reply-To: [EMAIL PROTECTED]
Jim Gillogly wrote:
>
> Dr.Gunter Abend wrote:
> G.A.> The proposed technique of appending some garbage at
> > the beginning of the plaintext in case of an intelligible
> > ciphertext surely weakens the keystring, no matter if it
> > is done automatically or by hand.
>
> Actually, a quantification did just occur to me. Your
> algorithm could be something like "If the ciphertext is all
> ASCII and says something coherent, skip the first OTP bit and
> try again." The cryptanalyst will know or guess that you've
> done this, and immediately has one bit of known data from
> every byte -- the low bit, which is where the 8th bit got
> shifted from the first try.
My idea was: skip one bit of the OTP if the ciphertext
contains more than 10% letter tripletts.
Usually the ciphertext will contain 20% letters, 4% doubletts,
0.8% tripletts, 0.4% tripletts with at least one vowel.
If the whole text contains 10% tripletts of this kind,
it is still not yet readable. Thus, if you automatically
discard ciphertexts with more letter tripletts, you never
transmit readable text. Yet you have to discard a very small
number of all your texts!
*If* the adversary has a realistic reason to assume that the
actual ciphertext was modified in this way, he really knows
about 10% of all low order bits. But he doesn't know, which
ones. If he checks the frequency of any specific bit, he also
*knows* some 10% of these bits because of the non-uniform
distribution of individual bits in plain ASCII texts. He may
easily find out how many lower or upper case letters or digits
are contained in you message.
In order to avaoid this kind of leak of the OTP technique
you should not apply it to ASCII texts, but compress them
beforehand. Usually, the bit frequencies in compessed files
are fairly uniform. But: this amount of "information" which
is inherent to OTP of ASCII texts, is usually not considered
a (theoretical) problem.
> ... Skip the whole damned thing and start over N bytes
> down. You're now back in the dicey business of pre-qualifying
> pads because of perceived patterns, but that's a much lower
> risk than giving away 1/8 of your message.
I don't know which of the two proposed methods will be better.
The last one consumes more of the OTP, thus I would prefer the
first one.
Ciao, Gunter
------------------------------
From: [EMAIL PROTECTED]
Subject: Why this simmetric algorithm is not good?
Date: Mon, 05 Jul 1999 12:01:21 GMT
Hi,
I'm not a experimented cryptanalyst but there is an encryption algorithm
(written in a Pascal-like language).
procedure cipher(Key : uint128 ; plain: file ; cipher : file)
var Kaux: uint128
begin
setRandomSeed(Key);
c = 2^128 - 1
while not EOF(plain)
begin
Kaux := c xor Random(0..2^128-1)
p := getNext128bits(plain)
c := p xor Kaux
writeNext128bits(cipher, c)
end
end
What's wrong with this algorithm, besides the Random function strength?
Gabriel
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Dr.Gunter Abend" <[EMAIL PROTECTED]>
Subject: Re: The One-Time Pad Paradox
Date: Mon, 05 Jul 1999 16:07:00 +0200
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> If I _intend_ to filter keypads, but because my filter criteria
> is fairly wide, never expect to _actually_ filter a pad, then
> I've given the adversay who is aware of my policy some information
> about all of the messages I've sent.
>
> The same issue applies to ciphertext filtration.
[Example of vanishingly small probability snipped.]
> So, my filtration has weakened my security by an amount that
> rounds to zero.
I agree completely: _How_much_ the cipher has been weakened,
depends on the probability of _actual_ filtering. I proposed:
Discard the ciphertext (and repeat the encryption) if it
contains more than 10% letter tripletts with at least one
vowel. Random texts would contain about 0.4% letter tripletts
of this kind. It is *very* unlikely that a long text would
contain more than 10%. The degradation of the secrecy due to
this modification could be calculated. I myself don't know
how to do this calculation, thus I ask the specialists here
in this newsgroup whether they can give me an estimation.
Ciao, Gunter
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: The One-Time Pad Paradox
Date: Mon, 05 Jul 1999 16:08:03 +0200
Patrick Juola wrote:
>
>
> *BUT*, I distrust this reasoning as anything more than a WAG for
> several reasons. First, XOR doesn't necessarily retain all the
> randomness in an English text; in particular, for instance, about
> 20% of the characters are spaces. This means that if you used two dummy
> texts and one true one, about 4% of the time the (true) plaintext letter
> would be passed through unchanged because the two pads were both spaces.
>
> Second, you claim that you can use nine plausible dummy texts. But
> this means that you're not using *unrestricted* English, which means
> in turn that it's less informative than 1 bit/letter, and therefore
> eight dummy texts will be insufficient. In particular, if you are
> using plausible texts, then the recovery of any one text will suggest
> cribs for the other N.
Just a tiny remark: Besides the n plausible messages we also use
one keystream which, though not comparable to the ideal OTP,
can have some 'practical' randomness. Of course, on the other hand,
one should not neglect that the supply of the plausible messages
is an issue. But that can be appropriately dealt with in practice,
I suppose.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: I don't trust my sysadmin
Date: Mon, 05 Jul 1999 11:31:15 GMT
In article <[EMAIL PROTECTED]>,
Eric Hambuch <[EMAIL PROTECTED]> wrote:
> As far as I know, "root" can access everything you type on the console
> ?!
Get a more trust worthy sysadmin :).
When I was co-oping at Nortel I learnt that the sysadmin people are
normally busy with work to snoop around so normally you don't worry
about it.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Why this simmetric algorithm is not good?
Date: Mon, 05 Jul 1999 10:19:01 -0400
[EMAIL PROTECTED] wrote:
>
> procedure cipher(Key : uint128 ; plain: file ; cipher : file)
> var Kaux: uint128
> begin
> setRandomSeed(Key);
> c = 2^128 - 1
> while not EOF(plain)
> begin
> Kaux := c xor Random(0..2^128-1)
> p := getNext128bits(plain)
> c := p xor Kaux
> writeNext128bits(cipher, c)
> end
> end
>
> What's wrong with this algorithm, besides the Random function strength?
What you have is essentially a stream cipher that processes 128 bits at
a time. And you're using a pseudorandom number generator to generator
your key stream. In your cipher, your ciphertext block is the XOR of:
(1) plaintext block, (2) key stream, and (3) previous ciphertext block.
The inclusion of the last element adds no strength to the cipher.
Subtracting (XOR'ing) the previous ciphertext block from the current
ciphertext block reduces your cipher to the more standard form.
The usual observations and caveats about stream ciphers apply.
Nicol
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Crypto Books on CD-ROM
Date: Mon, 05 Jul 1999 14:26:27 GMT
David Parkinson <[EMAIL PROTECTED]> wrote, in part:
>Michael D T Clark <[EMAIL PROTECTED]> wrote:
>: There is indeed a catch. Those of us living outside the USA cannot buy
>: the CD, because it is a restricted export.
>: I would really like to get a copy to compliment the books I already
>: have, but can't get it until the export restriction are lifted.
>Is it? I had no problems at all in buying a copy and
>having it shipped here (UK).
I remember that originally, it was only available in the U.S., and
then a few months later, Canada was added. More recently, the ads
haven't mentioned anything about export restrictions. Presumably
they've gotten new licensing permissions...
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Crypto Books on CD-ROM
Date: Mon, 05 Jul 1999 14:25:10 GMT
[EMAIL PROTECTED] (Bruce Schneier) wrote, in part:
>It's worth buying the new version of the CD-ROM. All the books are in
>pdf format, and the hyperlinking actually works. I found the first
>version almost useless, but I like this version.
I had been putting off getting a copy...this news encourages me to go
ahead now.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Why this simmetric algorithm is not good?
Date: Mon, 05 Jul 1999 14:33:46 GMT
[EMAIL PROTECTED] wrote, in part:
> Kaux := c xor Random(0..2^128-1)
> p := getNext128bits(plain)
Oops, there is something else wrong with it.
Built-in random number generators produce at most 32-bit, and more
commonly 16-bit, random quantities each time. And only the first few
bits are really very random: the last bit has period 2, the
second-last bit has period 4, and so on.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Why this simmetric algorithm is not good?
Date: Mon, 05 Jul 1999 14:31:52 GMT
[EMAIL PROTECTED] wrote, in part:
>What's wrong with this algorithm, besides the Random function strength?
Answer: nothing. (Well, there's the bit-flipping attack: someone
knowing the plaintext can invert ciphertext bits to make the new
plaintext anything he wants.)
Unfortunately, the "random function strength" is normally pretty
lousy. The most common PRNG offered in standard libraries is a mixed
congruential one, which is fairly easy to predict.
So there isn't anything _else_ wrong with it, besides the one thing
that makes it completely unfit for use.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Why this simmetric algorithm is not good?
Date: Mon, 05 Jul 1999 18:36:43 +0200
[EMAIL PROTECTED] wrote :
> (128 bits stream cipher deleted)
>
> What's wrong with this algorithm, besides the Random function strength?
0) The algorithm is probably weak unless the Random function is designed
for crypto
1) someone actively intercepting a ciphertext can flip whatever bit of
plaintext
2) someone managing to get a ciphertext and it's corresponding plaintext
can decipher or forge messages using the same key, of length up to
the intercepted message size
3) someone intercepting several ciphertext enciphered with the same key
can detect that some bits are indentical to previous messages at a
given position; can be usefull if the purprose is to detect something
unusual (e.g. the message starts in "ALERT !!!" instead of "dear sir")
4) there is no provision for messages not a multiple of 128 bits
Francois Grieu
------------------------------
From: Wil Baden <[EMAIL PROTECTED]>
Subject: Re: Crypto Books on CD-ROM
Date: 5 Jul 1999 15:39:13 GMT
[EMAIL PROTECTED] wrote:
> Yesterday I received an interesting solicitation in the mail from
> Dr. Dobb's Journal. They were advertising a bunch of "essential books"
> CD-ROMS.
> One of particular interest to sci.crypt readers is the "Essential
> Books on Cryptography and Security CD-ROM". For less than $100,
> it claims to have complete text for the following books:
I do not have a credit-card. How can i order this?
--
Wil Baden Costa Mesa, California
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Date: Mon, 05 Jul 1999 18:55:56 +0200
[EMAIL PROTECTED] wrote:
>
>
> How is this steganographic technique better than applying ROT-13 to the
> source code?
> If a justice department investigator can apply a simple transform to the
> message and produce a working program capable of strong crypto, he will
> conclude tha the laws have been broken.
Boris Kazak's method is NOT a steganographic technique. It is an
'open' encoding of bits into the English text. Anyone, from justice
department or not, can recover the information. The point is that
English texts are exportable. There is nothing forbidding one's
writing English texts using lower case or upper case. (Would one
be punished if one e.g. occasionally misspells a word in his e-amil?)
M. K. Shen
------------------------------
Date: Sun, 04 Jul 1999 23:54:28 -0400
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Mok-Kong Shen wrote:
>
> I presume that the results todate of discussions in two threads in
> sci.crypt that I recently initiated are of sufficient value and
> significance to justify a summary being given to them.
>
> To export strong crypto, it is surely o.k. if one has one's paper sent
> to a country without crypto laws for placing (by a foreign subject) on
> a server and gives the reference (URL minus the prefix http://) to it
> on one's domestic home page so that any reader can access the content
> of the paper without much effort. Probably providing a link, i.e.
> employing the full URL for mouse click, is also o.k. This needs
> in my humble view to be clarified ín order to to be absolutely sure.
> Using the reference only is, however, conservative and can't get in
> conflict with laws in any case.
>
> The other (much more inconvenient yet do-able) way of exporting strong
> crypto is to use Boris Kazak's method to encode the stuff, i.e.
> taking any text and employing lower case for representing 0 and upper
> case for representing 1, and put the resulting English text directly
> on one's site. In this case the reader has to write a tiny program to
> retrieve the stuff but the author needs no assistance from a foreign
> server. (The tiny program is exportable and can be easily made
> publically available.)
How is this steganographic technique better than applying ROT-13 to the
source code?
If a justice department investigator can apply a simple transform to the
message and produce a working program capable of strong crypto, he will
conclude tha the laws have been broken.
The analogous situation with respect to arbitrary limitations on
communication is the US Mail rules about pornography. If you send
pornographic material through the mail you have broken the rules. The
kind of envelope does not matter. The recording medium does not
matter. Even undeveloped film will count against you.
>
> Thus I conclude that one can indeed manage to export strong crypto
> (now!) irrespective of the ultimate outcome of the Bernstein case.
You can export strong crypto now. You just cannot do so legally.
>
> Of course, we hope that the bureaucrats' attempt for a revision
> wouldn't succeed. I strongly believe that the above could be of some
> significance, should a revision of the case take place.
>
> Finally it may be of value to note as a aside that Boris Kazak's
> method is effective for jamming the WWI if sufficient people on the
> internet regularly encode meaninless random bits into their e-mails
> that way.
>
> M. K. Shen
> ------------------------
> http://www.stud.uni-muenchen.de/~mok-kong.shen/ (Updated: 12 Apr 99)
> (Origin site of WEAK2-EX, WEAK3-EX and WEAK4-EX, three Wassenaar-conform
> algorithms based on the new paradigm Security through Inefficiency.)
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: Standard Hash usage
Date: 5 Jul 1999 17:05:32 GMT
Well what's most important is how Jetico (makers of BestCrypt) did it.
Whether it was secure or not doesn't matter (for the answer to my
problem)
Thanks for the conversation,
Keith
[EMAIL PROTECTED] wrote:
: In article <[EMAIL PROTECTED]>,
: [EMAIL PROTECTED] (David P Jablon) wrote:
: > That function, hash = sha1(P) || sha1(P || sha1(P)), limits the
: > entropy to no more than 160-bits, when P has more than 160-bits
: > of entropy.
: >
: > Keep trying. :-)
: However if the input entropy is much less then it matters not? The
: hash functions guarantees that the output (symmetric key) is
: essentially a random function of the input (password). If you double
: it you get 320 pseudo-random bits.
: Normally passwords are about 15 chars which is an entropy of 15^95 or
: 371 bits. You could then just hash each independantly but you would
: have collisions one the halves (i.e 'aaaaaabbbbbb' and 'bbbbbbaaaaaa'
: would collide on the two halves (for two keys)). Also most passwords
: are badly chosen which facilates dictionary attacks and limited input
: attacks. For example most letters are barely used. If we assume that
: the password is only letters and there are only 15 probable letters we
: limit search to 15^15 or 58 bits (far less then the output of the hash).
: Tom
: --
: PGP key is at:
: 'http://mypage.goplay.com/tomstdenis/key.pgp'.
: Sent via Deja.com http://www.deja.com/
: Share what you know. Learn what you don't.
------------------------------
** 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
******************************
