Cryptography-Digest Digest #658, Volume #10 Wed, 1 Dec 99 13:13:01 EST
Contents:
Re: The Code Book - Part 4 (jerome)
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: High Speed (1GBit/s) 3DES Processor (Sander Vesik)
Re: How safe is Mobile Phone ? (Markus Peuhkuri)
Re: VIC cipher strength? (UBCHI2)
Encrypting short blocks (Markus Peuhkuri)
Re: Elliptic Curve Public-Key Cryptography ("Roger Schlafly")
Re: Encrypting short blocks (Anton Stiglic)
Re: Verication - Anyone? (Anton Stiglic)
Re: compact encryption in javascript (Bill Lynch)
Re: Elliptic Curve Public-Key Cryptography ("Roger Schlafly")
Generate a key pair from a user-entered key file? ([EMAIL PROTECTED])
Re: Paradise shills?? (James Felling)
Re: Decyption proof cellphones in Europe? [x3] (Bruce Schneier)
Re: Elliptic Curve Public-Key Cryptography (Bruce Schneier)
Re: Elliptic Curve Public-Key Cryptography (Bruce Schneier)
Re: AES cyphers leak information like sieves (Volker Hetzer)
Re: Decyption proof cellphones in Europe? [x3] (Ian Goldberg)
Re: NSA should do a cryptoanalysis of AES (Keith A Monahan)
Re: digraph frequencies ([EMAIL PROTECTED])
Re: What part of 'You need the key to know' don't you people get? (Volker Hetzer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: The Code Book - Part 4
Reply-To: [EMAIL PROTECTED]
Date: Wed, 01 Dec 1999 14:14:21 GMT
yes
On Wed, 01 Dec 1999 11:26:29 GMT, Andreas wrote:
>Hello,
>
>Because I can't speak that language (french) after I had decoded it I
>can't get the keyword from the text. Anyone who can help with
>translation?
>
>Regards
>/Andreas
>
> o o
> O o
> o_/|\_, Student of Computer Science
> | Luleå University of Technology
> Juggler Sweden
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: 01 Dec 1999 14:32:10 GMT
Yes, portions of it were encrypted in a substitution cipher, actually a Caesar
cipher, in that my touch typing fingers were off position by one when I was
correcting an earlier typo.
Don Johnson
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: 1 Dec 1999 14:38:33 GMT
In sci.crypt Jerry P <[EMAIL PROTECTED]> wrote:
> No market research needed.
> 3DES at a 1 Gigabit/sec, like anti-gravity, free desalination,
> non-polluting engines, and ADSL, is obviously a billion-dollar
> winner. NSA can do 3DES at 1 Gigabit/WEEK with Cray computers.
See Chris Eilbecks mail in the same thread.
---
Sander
There is no love, no good, no happiness and no future -
these are all just illusions.
------------------------------
From: Markus Peuhkuri <[EMAIL PROTECTED]>
Subject: Re: How safe is Mobile Phone ?
Date: 01 Dec 1999 16:40:15 +0200
>>>>> "David" == David Wagner <[EMAIL PROTECTED]> writes:
David> confidence in their product, so why should we believe the
David> Sectra folks?
Because "Sectra is the leading developer and manufacturer of
information security products for the Swedish Armed Forces."
(as noted on every page on that web site; I'll leave jokes
about Swedish "Armed" "Forces" as this is not
rec.humor.funny.true_stories).
I _would_ imagine that the phone uses some efficient voice
coding and some suitable block encryption and transmits voice
over GSM data connections (originaly 9.6 kbps, some operators
provide now 14,4 kbps, the speed is lower if newtwork coverage
is poor).
This requires that the other end has also indentical device
to communicate, but that might not be much a problem for
organizations requiring secure communications. Another
problem is that connection setup is slower as many operators
do not have ISDN gateways for communications but use modems
(30 second delay for setup).
The GSM is not sufficient for military grade communications,
I'm not sure about big business. For private communications
it is strong enough (my opinion).
--
Markus Peuhkuri ! [EMAIL PROTECTED] ! http://www.iki.fi/puhuri/
========================================================================
Never underestimate the power of human stupidity
... and don't forget you are a human too.
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Re: VIC cipher strength?
Date: 01 Dec 1999 14:58:51 GMT
Looking at the VIC Cipher, it appears that many of the steps leading up to the
straddling checkerboard are quite unecessary. Why not just start with a
predeterminded straddling checkerboard and then perform the rest of the
encipherment.
------------------------------
From: Markus Peuhkuri <[EMAIL PROTECTED]>
Subject: Encrypting short blocks
Date: 01 Dec 1999 16:55:36 +0200
Is there an encyprion algorithm that can be used for short
blocks (variable from ~10 to 24 bits) _and_ the result is same
length as original data. The key may be much larger (128, 256,
...).
Also one-way function with similar properties would be
suitable for my purposes.
Could some existing algorithm be changed to work like that?
Thanks for any hints.
--
Markus Peuhkuri ! [EMAIL PROTECTED] ! http://www.iki.fi/puhuri/
========================================================================
Never underestimate the power of human stupidity
... and don't forget you are human too.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: Wed, 1 Dec 1999 06:47:40 -0800
DJohn37050 <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >There are other differences to consider, too. Checking elliptic curve
> >signatures is still a big pain compared to checking RSA signatures.
>
> * This is an overbroad generalization that is simply false. And it
depends
> greatly on what might be causing the pain.
No, it is a fair statement. Checking elliptic curves signatures is a bigger
pain just about any way you want to measure it. It is slower, more
complicated, requires more code, requires more data if you
include system parameters, is not as well standardized, does not
have commercial certificate authorities, etc.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Encrypting short blocks
Date: Wed, 01 Dec 1999 10:24:49 -0500
Markus Peuhkuri wrote:
> Is there an encyprion algorithm that can be used for short
> blocks (variable from ~10 to 24 bits) _and_ the result is same
> length as original data. The key may be much larger (128, 256,
> ...).
If you just want private key encryption, you might want to use a one-time
pad. Or maybe some block cipher that works on 64 bits or something and
use padding.
Anton
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Verication - Anyone?
Date: Wed, 01 Dec 1999 10:33:08 -0500
If you work on a unix or linux system, you most probably have
a command called 'bc' which allows you to do BN math. As the
other replies, I get
bc 1.05
Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation,
Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
65537^9
22303807926762253812938859060411589043224577
65537^9 % 976234876234812734876124246346
477376334740716679392684972971
Anton
------------------------------
From: Bill Lynch <[EMAIL PROTECTED]>
Subject: Re: compact encryption in javascript
Date: Wed, 01 Dec 1999 09:42:17 -0600
MD5 implemented in JavaScript:
http://cw.oaktree.co.uk/crypt/md5.html
http://www.geocities.org/SiliconValley/7116/jv_md5.html
could someone verify the correctness of these implementations?
--Bill
Paul Rubin wrote:
>
> In article <821bki$13ea$[EMAIL PROTECTED]>,
> Eike Kock <[EMAIL PROTECTED]> wrote:
> >Paul Rubin wrote:
> >> Implementing secret-key ciphers like RC4 in javascript is very easy.
> >> Is that good enough for your application?
> >
> >Yes. Is there a site I can find a RC4 cipher in js?
>
> I don't know of a public one. I've written one but unfortunately
> can't distribute it. However, it took just a few minutes, and I'm
> sure you could do one very quickly too if you're familiar with RC4
> and with Javascript. RC4 is ridiculously simple.
--
The best JavaScript reference:
http://developer.netscape.com/docs/manuals/js/client/jsref/index.htm
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: Wed, 1 Dec 1999 07:02:25 -0800
Bruce Schneier <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> My recommendation is that if you're working in a constrained
> environment where longer keys just won't fit -- smart cards, some
> cellphones or pagers, etc. -- consider elliptic curves. If the choice
> is elliptic curves or no public-key algorithm at all, use elliptic
> curves.
Agreed.
> If you don't have performance constraints, use RSA.
This would be a reasonable conclusion if RSA had the best security
but poor performance. But if you really don't have any performance
constraints, then use can use huge keysizes to get whatever security
you please from any of the methods. The choice of methods will
be based on other considerations.
> If you are concerned about security over the decades
> (almost no systems are), use RSA.
>
> Realize, though, that someday -- next year, in ten years, in a century
> -- someone may figure out how to define smoothness, or something even
> more useful, in elliptic curves. If that happens, you will have to
> use the same key lengths as you would with conventional discrete
> logarithm algorithms, and there will be no reason to ever use elliptic
> curves.
Always possible, but you have to compare that against the
possibility of a big advance in factoring. There might also be
a big advance in solving the RSA problem without factoring.
Advances that have already taken place have invalidated
a lot of keys.
I'd go with elliptic curves if you need security for decades.
The elliptic curve DL problem seems to be much more
intrinsically difficult than the RSA problem. Elliptic curve
systems also give better protection against Moore's Law.
If you accept the Lenstra-Verheul analysis, then you need
to use 3000-bit keys with RSA, and almost no one is
doing that.
------------------------------
From: [EMAIL PROTECTED]
Subject: Generate a key pair from a user-entered key file?
Date: Thu, 02 Dec 1999 00:32:59 +0800
Hi
Does anyone know how I could obtain a key pair from the contents of a
user-entered text file or how I could extract a key pair from such a
file?
Thanks
Greg
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Paradise shills??
Date: Wed, 01 Dec 1999 10:52:17 -0600
"Douglas A. Gwyn" wrote:
> James Felling wrote:
> > ... they in no way discuss the source/algorithim for their RNG.
> > ( Just because it is 2016 bits in size does not
> > mean anything unless the underlying algorithim is also sound.
>
> Actually, under reasonable assumptions it means that one needs at
> least 2016 bits of the generated sequence in order to completely
> recover the generator parameters. That's not considered a lot
> of "ciphertext" by cryptanalytic standards.
Upon re-reading the page(I believe it has been updated of recent), they
are somewhat subject to malicious client attacks( If I am using a
subverted client I can specify some of the data going into that pool,
and potentially with enough shills I could sumbit a substanbtial portion
of the base entropy for the pool, and possibly to timing based attacks(
though that may be less likely). They should probably do some hashing so
that even if they are fed fixed data, the only thing that that does is
allows the "fixed" bits to be known fixed, and not to be specified.
I am not very familiar with the "Berkley" PRNG mentioned( perhaps by
annother name? perhaps I just havent bumped into it? i am aware of a
few PRNGs originating from there or from people in that area, but none
called "Berkley")
and thus cannot comment in re: it.
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Crossposted-To: alt.2600,alt.privacy
Subject: Re: Decyption proof cellphones in Europe? [x3]
Date: Wed, 01 Dec 1999 16:58:38 GMT
On 1 Dec 1999 06:56:21 -0000, [EMAIL PROTECTED] (The Watchman) wrote:
>Yesterday I heard a news commentary by Daniel Schorr of NPR
>criticizing some of the technical failings of the US intelligence
>community in the face of advances and developments throughout the rest
>of the world (e.g. NSA failed to decrypted Indian communications that
>would have tipped us off to their pending nuclear tests because of
>their use of strong encryption).
>
>He also made a passing comment that "North Koreans are using
>decyption-proof cell phones readily available in Europe...." That
>caused me to raise my ears. My understanding was that the A5 algorithm
>basic to GSM encryption had been broken by a bunch of amateurs a
>couple of years back. Anybody know what he's refering to here?
>
>PS: For those interested, the entire commentary can be heard at:
>http://www.npr.org/ramfiles/atc/19991129.atc.03.ram
This sounds like an audio summary of Seymour Hersh's excellent New
Yorker article on the same topic, which can be found at:
http://cryptome.org/nsa-hersh.htm
It's really interesting reading.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: Wed, 01 Dec 1999 17:08:19 GMT
On 30 Nov 1999 19:40:27 GMT, [EMAIL PROTECTED] (DJohn37050) wrote:
>* I guess if I had said what you said in your discussion, in referring to
>Lenstra's website, I would have clarified that the Counterpane newsletter
>discussion disagreed with (some of) Lenstra's conclusions. An innocent reader
>might think that Lenstra is saying similar things as you did, when he is not.
Certainly Lenstra agrees with what I said in my essay. I made sure of
that by sending him a draft before publishing it. The paper I pointed
to is not on the same topic as my paper.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: Wed, 01 Dec 1999 17:11:03 GMT
On 30 Nov 1999 11:05:51 -0800, [EMAIL PROTECTED]
(David Wagner) wrote:
>I think we can all agree that
>ECC has some apparent advantages over RSA (key size; signature size;
>performance on small devices), and RSA has some apparent advantages over
>ECC (performance of encryption & signature verification; RSA has been around
>longer). So there are tradeoffs. Right?
I don't necessarily agree. This assumes an EC setup with shared
parameters. In other setups the key size difference can be minimal.
I've seen small devices that are excellent for RSA, but extremely poor
for EC; the statement on small device performance is too general.
I avoid small values of e with RSA, but RSA is probably stiff faster
than comparable EC algorithms for e's up to about 64 bits.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Wed, 01 Dec 1999 18:11:31 +0100
wtshaw wrote:
> > Why?
> > You want to recognise a known block. So you need that block in storage.
>
> Bits? OK, if that is the nature of the beast. If the keyspace is larger
> than the message space, you will need more than one block; it could be
> many, not just two.
AFAIK a dictionary attack means "I know what a certain ciphertext block means.
If I recognise that ciphertexzt block (in ECB mode) then I know what message was
sent."
Of course, if you want to derive a key from the mapping, then you are right.
You might have to match several blocks.
However, there could be certain tradeoffs.
What about storing only partial blocks and partial keys?
Then you could store more different blocks of known plaintext.
> An algorithm may be comprised of other algorithms. A complex algorithm may
> involve a rather lengthy key. If properly done, analysis is devilishly
> compounded.
Yes. And, if the algos don't form a group you need to find out many keys.
> If much material need be solved for verification of a
> message, surely the algorithm might be said to be stronger in one sense
> than one that requires a lesser amount.
Yes.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Crossposted-To: alt.2600,alt.privacy
Subject: Re: Decyption proof cellphones in Europe? [x3]
Date: 1 Dec 1999 17:15:44 GMT
In article <[EMAIL PROTECTED]>,
Gurripato <[EMAIL PROTECTED]=NOSPAM> wrote:
>On 1 Dec 1999 06:56:21 -0000, [EMAIL PROTECTED] (The Watchman) wrote:
>>He also made a passing comment that "North Koreans are using
>>decyption-proof cell phones readily available in Europe...." That
>>caused me to raise my ears. My understanding was that the A5 algorithm
>>basic to GSM encryption had been broken by a bunch of amateurs a
>>couple of years back. Anybody know what he's refering to here?
>>
> Well, the "amateurs" worked at Berkeley. But you´re right, I
>heard the same. However, I just visited the Smartcard Developers´
>Association, and they have just released a new A5/1 algorithm,
>supposedly stronger; see it at http://www.scard.org/gsm/. Whether it
>is really secure is still to be proven; at least they have released
>the source code (learning from the past?).
You're confusing a couple of things, here. The SDA didn't _make_ the
A5/1 and A5/2 and COMP128 algorithms; they just reverse-engineerend and
published the source (which the GSM people have been unwilling to do).
We at Berkeley (David Wagner and myself) then cryptanalysed the
algorithms. They all suck. The one that sucks least is A5/1, which
seems to have ~40-bit workfactor. (The A5/1 work wasn't done by us; see
the links below.) A5/2 sucks surprisingly hard, with a 16-bit
workfactor (i.e. real time break).
Dave was also involved in the cryptanalysis of cellphone encryption
algorithms for US-based (not GSM) digital systems.
A summary of the GSM stuff is below.
- Ian
* The four core GSM cryptographic algorithms are:
* A3 authentication algorithm
* A5/1 "stronger" over-the-air voice-privacy algorithm
* A5/2 "weaker" over-the-air voice-privacy algorithm
* A8 voice-privacy key generation algorithm
*
* In April of 1998, our group showed that COMP128, the algorithm used by the
* overwhelming majority of GSM providers for both A3 and A8 functionality
* is fatally flawed and allows for cloning of GSM mobile phones.
*
* Furthermore, we demonstrated that all A8 implementations we could locate,
* including the few that did not use COMP128 for key generation, had been
* deliberately weakened by reducing the keyspace from 64 bits to 54 bits.
* The remaining 10 bits are simply set to zero!
*
* See http://www.scard.org/gsm for additional information.
*
* [May 1999]
* One question so far unanswered is if A5/1, the "stronger" of the two
* widely deployed voice-privacy algorithm is at least as strong as the
* key. Meaning: "Does A5/1 have a work factor of at least 54 bits"?
* Absent a publicly available A5/1 reference implementation, this question
* could not be answered. We hope that our reference implementation below,
* which has been verified against official A5/1 test vectors, will provide
* the cryptographic community with the base on which to construct the
* answer to this important question.
*
* Initial indications about the strength of A5/1 are not encouraging.
* A variant of A5, while not A5/1 itself, has been estimated to have a
* work factor of well below 54 bits. See http://jya.com/crack-a5.htm for
* background information and references.
*
* With COMP128 broken and A5/1 published below, we will now turn our
* attention to A5/2.
*
* [August 1999]
* 19th Annual International Cryptology Conference - Crypto'99
* Santa Barbara, California
*
* A5/2 has been added to the previously published A5/1 source. Our
* implementation has been verified against official test vectors.
*
* This means that our group has now reverse engineered the entire set
* of cryptographic algorithms used in the overwhelming majority of GSM
* installations, including all the over-the-air "voice privacy" algorithms.
*
* The "voice privacy" algorithm A5/2 proved especially weak. Which perhaps
* should come as no surprise, since even GSM MOU members have admitted that
* A5/2 was designed with heavy input by intelligence agencies to ensure
* breakability. Just how insecure is A5/2? It can be broken in real time
* with a work factor of a mere 16 bits. GSM might just as well use no "voice
* privacy" algorithm at all.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: 1 Dec 1999 17:34:51 GMT
Kenneth,
My concern is that if they DID break one of the algorithms and
didn't tell us(or NIST) about it. I don't know how likely that
is, but it is certainly a possible case.
It wouldn't be _as_ bad as if the NSA broke it, told us about it,
but didn't tell us how. That would still keep me wondering, but
at least we'd know the cipher isn't secure. Even without telling
us how they did it, we might be able to draw some conclusions about
ciphers of that same nature. Or we might focus our attention on
that one cipher to try to find what they found. I think we could
at least assume perhaps ciphers that have this type of key schedule
or that type of Feistel network, etc might be insecure.
Everyone agree, disagree?
Keith
Kenneth Almquist ([EMAIL PROTECTED]) wrote:
: My guess is that the information from the NSA which influences the
: AES selection will be made public, because as you point out, keeping
: the information secret would be difficult. On the other hand, some
: of the information that we would like to know might be classified.
: For example, if the NSA breaks one of the finalists, the fact that
: the encryption algorithm had been broken would rule it out of
: consideration. The specific attack used to break the algorithm
: would not matter to NIST. So I would expect us to learn that the
: algorithm had been broken, but not necessarily how.
: Kenneth Almquist
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: digraph frequencies
Date: Wed, 01 Dec 1999 17:25:22 GMT
Thanks for the table, it should come in handy.
jeff
In article <822csb$nim$[EMAIL PROTECTED]>,
William Rowden <[EMAIL PROTECTED]> wrote:
> In article <81ktar$it1$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> > Can anybody provide me with a table of frequencies for two-letter
> > combos in the englis language? (digraphs)
>
> Courtesy of O. Phelps Meaker via Helen Fouche Gaines, a chart showing
> frequencies of English digrams ("actual count made on 10,000 letters
of
> literary text"--find the missing letter) is below. The format is
> comma-separated values, ready for importing into your favorite
> spreadsheet or text program. (Watch out for line wrap; lines
> generally begin with a comma and a letter.) The request didn't
specify
> which type of digrams; the values below must be without regard to word
> breaks (since the rows and columns are equal). Now go buy
> _Cryptanalysis: a study of ciphers and their solution_ so Dover
> Publications, Inc. doesn't hunt us down.
>
> ,,First Letter,,,,,,,,,,,,,,,,,,,,,,,,,,
> Second,,A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,Total
>
Letter,A,1,8,44,45,131,21,11,84,18,,,34,56,54,9,21,,57,75,56,18,15,32,3,
> 11,,804
> ,B,32,,,18,11,2,2,1,7,,,7,9,7,18,1,,4,13,14,5,,,,11,,162
> ,C,39,,12,4,64,9,1,2,55,,,8,1,31,18,,,14,21,6,17,,3,5,10,,320
> ,D,15,,,10,107,1,1,1,16,,,28,2,118,16,,,16,6,9,11,,4,,4,,365
>
,E,,58,55,39,39,25,32,251,37,2,28,72,48,64,3,40,,148,84,94,11,53,30,1,12
> ,5,1231
> ,F,10,,1,12,23,14,3,2,27,,,5,,8,94,,,6,13,5,1,,1,,3,,228
> ,G,18,,,2,20,1,1,,10,,,1,,75,3,,,6,6,1,12,,,,5,,161
> ,H,,,46,3,15,6,16,5,,,,,1,9,3,7,,3,30,315,2,,48,,5,,514
>
,I,16,6,15,57,40,21,10,72,,,8,57,26,37,13,8,,77,42,128,5,19,37,4,18,2,71
> 8
> ,J,,2,,1,1,1,,,,,,1,,3,,,,1,,,,,,,,,10
> ,K,10,,8,,2,,,,8,,,3,,3,5,,,11,2,,,,,,,,52
> ,L,77,21,16,7,46,10,4,3,39,,,55,,10,17,29,,12,6,12,28,,4,,6,1,403
> ,M,18,1,,9,43,3,1,1,32,,,4,5,7,44,,,15,14,14,9,,1,,4,,225
> ,N,172,,,5,120,2,3,2,169,,3,1,3,9,145,,,12,19,8,33,,10,,3,,719
>
,O,2,11,59,37,46,38,23,46,63,4,3,28,28,65,23,28,,54,71,111,2,6,17,1,28,,
> 794
> ,P,31,,1,7,32,3,1,1,3,,,2,16,7,29,26,,8,24,8,17,,2,4,7,,229
> ,Q,1,,,1,14,,,,,,,2,,,,,,,2,,,,,,,,20
> ,R,101,6,7,10,154,4,21,8,21,,,2,,5,113,42,,18,6,30,49,,1,,5,,603
> ,S,67,5,1,32,145,8,7,3,106,,2,12,6,51,37,3,,39,41,32,42,,3,,17,,659
>
,T,124,,38,39,80,42,13,22,88,,1,19,6,110,53,14,,63,121,53,45,,6,1,21,,95
> 9
> ,U,12,25,16,8,7,11,8,2,,4,,8,13,12,96,7,20,6,30,22,,,1,1,1,,310
> ,V,24,,,4,16,1,,,14,,,2,,4,13,,,5,2,4,,,1,,3,,93
> ,W,7,,1,9,41,4,2,7,1,,3,5,2,15,36,1,,10,27,16,,,2,,14,,203
> ,X,,,,,17,,,,1,,,,,1,,,,,,,1,,,,,,20
> ,Y,27,19,,6,17,1,1,1,,,3,47,3,14,4,2,,17,4,21,1,,,,,,188
> ,Z,1,,,,,,,,4,,,,,,2,,,,,,1,,,,,1,9
>
,Total,805,162,320,365,1231,228,161,514,719,10,51,403,225,719,794,229,20
> ,602,659,959,310,93,203,20,188,9,10000
>
> --
> -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.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Wed, 01 Dec 1999 18:36:04 +0100
Brian Chase wrote:
>
> In article <81fhl8$th1$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> What if you have all the blocks available and there are a lot of them, say
> several dozen blocks or maybe even hundreds? Can you find patterns then?
In a good block cipher, no.
That is why it is possible to use a cipher in counter mode to generate
cryptographically secure random numbers.
>
> Even if individual blocks are indistinguishable from random data, can that
> be said when analyzing the entire set of encrypted blocks which make up
> the complete message?
In ECB, the only thing you can find out is, if two ciphertext blocks are
identical or not.
If one block differs in one bit from another block, you can't say anything
about the corresponding plaintext. True, there are attacks that feed lots
of blocks in a cipher and try to exploit correlations, but for the known
attacks of this type there are ciphers that require more blocks than
are available for those attacks to work.
>
> If the NSA can decrypt messages enciphered with OTP when the OTP is say
> used only twice,
Not only the NSA. The attack is public knowledge.
> could it be possible that there's enough redundancy
> between block ciphered message blocks that similar successes are possible?
The attacks are totally different.
>
> Are such questions stupid?
No, but we here are no substitute for a good book.
The questions you ask indicate that you lack one.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
** 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
******************************
