Cryptography-Digest Digest #657, Volume #10 Wed, 1 Dec 99 09:13:01 EST
Contents:
Re: Verication - Anyone? (Simon)
Re: What part of 'You need the key to know' don't you people get? (Brian Chase)
Re: What part of 'You need the key to know' don't you people get? (Brian Chase)
Re: What part of 'You need the key to know' don't you people get? (Brian Chase)
Re: The $10,000.00 contest (Peter Galbavy)
Re: Decyption proof cellphones in Europe? [x3] (Gurripato)
Re: Use of two separate 40 bit encryption schemes (Fredrik Olofsson)
Re: Question About SHA-1 (Fredrik Olofsson)
Re: compact encryption in javascript (Paul Rubin)
Re: brute force versus scalable repeated hashing ("Tim Wood")
Re: Elliptic Curve Public-Key Cryptography (Paul Crowley)
Recommendations on implementing ElGamal ("Sven Knispel")
The Code Book - Part 4 (Andreas)
Some feedback from the USA --- my story is real .. ("Markku J. Saarelainen")
Re: Elliptic Curve Cryptography (Darrel Hankerson)
Re: Open BCRYPT/1 brute-force analysis (Juergen Thumm)
Re: A dangerous question (Johnny Bravo)
Re: brute force versus scalable repeated hashing (Johnny Bravo)
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: brute force versus scalable repeated hashing (Juergen Thumm)
Re: Verication - Anyone? (fungus)
Re: NSA should do a cryptoanalysis of AES (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: Simon <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Verication - Anyone?
Date: Wed, 01 Dec 1999 07:31:21 GMT
> 65537 &^ 9 mod 976234876234812734876124246346;
>
477376334740716679392684972971
according to Maple, so you have a problem.
Glenn Larsson wrote:
>
> Hi. I'm developing a Bignum + DH implementation. I need someone
> to confirm that i'm on the right track so what i'm asking for
> is someone to verify this:
>
> (Compiler overflows at 65536^2)
> 65537 ^ 9 =
> 22303807926762253812938859060411589043224577
> Mod
> 976234876234812734876124246346
> =
> 291762786418173483520827836081
>
> Thankfull for answers, since i don't have access to a bignum lib
> and cannot confirm it, that's why i'm developing it...Catch 22.
>
> Regards,
>
> Glenn
> Sweden
--
Dr Simon Fitzpatrick, Shenton Park, Western Australia
Mathematician and International Correspondence Chess Master
http://www.q-net.net.au/~dsf/Simon.html
------------------------------
From: [EMAIL PROTECTED] (Brian Chase)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Wed, 1 Dec 1999 07:35:03 GMT
In article <81h9ug$5d0$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>You guys really have no clue about modern cryptosystems? ... that's
>sad.
>
>If I follow your logic properly everyone should use OTP's since they
>are the only true cipher. Everything else is just weak and made up by
>retards.
No, I don't think that's quite what is being said here. The point being
made is that we haven't proven whether or not weaknesses exist in
contemporary block cipher based encryption schemes. And I believe David
Scott's ideas following along the lines of making our ciphers more like
OTP in their characteristics in order to make them more secure.
I think that's a reasonable belief. Of course I don't think he's proved
that they're more secure. Yet I would be very surprised if the
redundancies in block mode ciphers (chained or otherwsie) resulted in
greater security than a cipher without those redundancies. That's a
speculation.
I think what I'm finding most disturbing, if not just outright disgusting,
is how quickly disregarded are Scott's challenges to the conventions of
the cryptology community. Sure he's an asshole, but as a community is it
not true that we don't conclusively know how secure the contemporary
algorithms are?
You've got someone who's flying smack in the face of your beliefs and you
aren't challenging him by trying to prove he's wrong through mathematical
rigor. Instead all anybody can come up with here is that he's difficult
and hard to get along with. That's pathetic. What a frail collection of
egos this lot has.
-brian.
--
--- Brian Chase | [EMAIL PROTECTED] | http://world.std.com/~bdc/ -----
It was powered by one AA battery from Radio Shack, in other words, half
a normal AA battery. -- K.
------------------------------
From: [EMAIL PROTECTED] (Brian Chase)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Wed, 1 Dec 1999 07:46:59 GMT
In article <81bhk8$29no$[EMAIL PROTECTED]>,
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>>So the main strength of CBC is to thwart the use of multiple
>>ciphertext messages to assist in breaking messages encrypted with the
>>same key, and it does this.
> I disagree!!
Yes, I agree with David Scott :-) Can not each block of CBC be viewed as
a seperate message encrypted with the same key? It's true there is some
localised modification to the behavior of the encryption function, but
does that modification *truly* alter the weaknesses of non-chained block
ciphers? Does it only mask the weakness or does it actually remove it?
I don't know. I'm still new and full of questions, and I don't think I'm
capable of proving it one way or the other. BUT it would be an
interesting thing to prove if it hasn't been already.
-brian.
--
--- Brian Chase | [EMAIL PROTECTED] | http://world.std.com/~bdc/ -----
It was powered by one AA battery from Radio Shack, in other words, half
a normal AA battery. -- K.
------------------------------
From: [EMAIL PROTECTED] (Brian Chase)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Wed, 1 Dec 1999 08:04:44 GMT
In article <81fhl8$th1$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>Ok look jerk. If you cannot tell the function from random then no
>ammount of cryptanalysis will break the cipher. For the most part you
>can't tell the popular block ciphers [such as RC5 and Blowfish] with
>only a handfull of blocks available.
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?
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?
If the NSA can decrypt messages enciphered with OTP when the OTP is say
used only twice, could it be possible that there's enough redundancy
between block ciphered message blocks that similar successes are possible?
Are such questions stupid?
-brian.
--
--- Brian Chase | [EMAIL PROTECTED] | http://world.std.com/~bdc/ -----
It was powered by one AA battery from Radio Shack, in other words, half
a normal AA battery. -- K.
------------------------------
From: [EMAIL PROTECTED] (Peter Galbavy)
Subject: Re: The $10,000.00 contest
Date: 1 Dec 1999 08:20:58 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Roy K. Menial wrote:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
>>Mr BS run a contest...
>
>You'll always be Mr. BS to me, Scott.
ROFL. Thank you. I needed cheering up this morning.
Regards,
--
Peter Galbavy
Knowledge Matters Ltd
http://www.knowledge.com/
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Gurripato)
Crossposted-To: alt.2600,alt.privacy
Subject: Re: Decyption proof cellphones in Europe? [x3]
Date: Wed, 01 Dec 1999 08:13:04 GMT
On 1 Dec 1999 06:56:21 -0000, [EMAIL PROTECTED] (The Watchman) wrote:
>Hey Folks,
>
>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).
Who knows, maybe the NSA did decrypt them but kept the
information for themselves (and perhaps key personnel at the Pentago,
the White House...). They can�t just tell the world that they are
able to crack another nation�s crypto methods.
>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?).
------------------------------
From: [EMAIL PROTECTED] (Fredrik Olofsson)
Subject: Re: Use of two separate 40 bit encryption schemes
Date: 1 Dec 1999 09:34:11 GMT
tony.pattison ([EMAIL PROTECTED]) wrote:
: > > As this is pitifully
: > >inadequate, I'm thinking of encrypting the data in my packets (again
: I was trying to find a way around the problem, by using what I have at hand.
By using a method like
Rivests 'all-or-nothing transform';
Bihams Bear, Lion or Lioness constructions; or
the Variable-Input-Length construction by Roggaway and Bellare
you could at least add to the complexity for the brute forcing
opponent, since the whole received message must be decrypted in order
to decrypt the sent message.
For all of those above your 40 bit DES can be used (probably for
everything, even the hashes).
If the packets are small, it is not a big win (effectively six or so
extra bits).
However they require at least one (depending on scheme) rekeying per
packet, which makes the efficiency drop further - in addition to the
double encryption (quickly keyed stream ciphers, preserving the
strength of the system by that there are two of them? Adding streams
with independent keys will never hurt, but you didn't have ready
access to any stream cipher?).
Another thing, you said you had 40 bit DES? Is it OK to change the
56-bit implementation inside so that it makes the 40 bit key to a 56 bit
(in computational terms) by 2^16 encryptions of the 40 bit secret key?
If the opponent has a long pipeline of circuits specially designed or
configured for the purpouse, it will only lead to latency.
All of this, even if used together, is admittedly a long way from
2^80, but it would hopefully delay the chances for a reasonably
equipped individual brute forcer to decrypt some session long enough
into the future.
- Fredrik Olofsson
------------------------------
From: [EMAIL PROTECTED] (Fredrik Olofsson)
Subject: Re: Question About SHA-1
Date: 1 Dec 1999 09:52:52 GMT
dpwhite ([EMAIL PROTECTED]) wrote:
: I am considering the use (abuse, perhaps) of SHA-1 to generate unique
: identifiers for java objects based upon their serialized state data. I
: need to be able to quickly and easily discern one serialized object from
: another based upon it's contents. There will be enough instance data to
: allow adequate discrimination to occur. Since the SHA-1 digest mechanism
: is part of the Java 1.2 distribution, it seems a likely possibility.
Hi David,
are there enough different states at the time the identifier is
created to support the hash with entropy?
Is it impossible to use some kind of atomically incremented counter or
timer instead (possibly timer in combination with state)?
I figure it is easy to err here.
- Fredrik
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: compact encryption in javascript
Date: 1 Dec 1999 09:59:57 GMT
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.
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: brute force versus scalable repeated hashing
Date: Wed, 1 Dec 1999 10:20:16 -0600
Johnny Bravo wrote in message <[EMAIL PROTECTED]>...
>On Sun, 28 Nov 1999 06:04:57 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>> Not very sporting of you to miss quote me. But then I guess I can't
>>expect very much from your type anyway.
>>
>>
>>David A. Scott
>
> It was a misquote, the material presented did not come from your
>post. Is your memory that bad that you can't even remember what you
>posted 26 hours previously? In the standard fashion "..." is used to
>represent missing material that was irrelevant to my reply.
>
> Johnny Bravo
>
< This quote has been altered! first line is:
It was not a misquote, the material presented did come from your
sorry >
You must however appreciate how easy it is to misrepresent someone by
changing the position of even one word ;-) or leaving out important concepts
or provisos ... there is nothing to say everyone has read the earlier post.
tim
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: 1 Dec 1999 08:29:06 -0000
[EMAIL PROTECTED] (DJohn37050) writes:
[...]
> this means I give the adversary some known plaintext/ciphertext pairs,
> this is undesirable. Is there an attack? Not that I know of, but I
> do not have as warm a fuzzy.
Can I just say I love this phrase?
How warm are *your* fuzzies?
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
Reply-To: "Sven Knispel" <[EMAIL PROTECTED]>
From: "Sven Knispel" <[EMAIL PROTECTED]>
Subject: Recommendations on implementing ElGamal
Date: Wed, 01 Dec 1999 11:09:29 GMT
I am looking for links on documents on any kind about the implementation of
ElGamal:
- precautions
- how to avoid wearnesses
- cryptoanalysis of ElGamal
- format of message packets
- other
Any help appreciated
-Sven
------------------------------
From: Andreas <[EMAIL PROTECTED]>
Subject: The Code Book - Part 4
Date: Wed, 01 Dec 1999 11:26:29 GMT
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: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Subject: Some feedback from the USA --- my story is real ..
Date: Wed, 01 Dec 1999 04:47:53 +0000
I have experienced such violations of human rights in the United States
of America that I could have not imagined earlier. Quite frankly, I had
very positive perception (in the scale of 1-10 - about 9) of this
country prior to coming this country. However, due to experiences over
the period of many years (that I have described in my many postings), my
perceptions have changed - unfortunately - to 3. If I would have known
what types of violations such as privacy abuses, I have to go through, I
would have never come to this country. And quite frankly I am just one
ordinary man. So this tells something about the United States of America
and I hope that some other people can learn from these experiences.
======
Back in 1996 I worked as a consultant developing organizational
management systems and joined in the beginning of 1997 one company in
Atlanta for the period of six months. It became obvious that some people
in this company had some SECRET information about me that they could
have only obtained by listening my private audio diary recordings or my
conversations at my private property (either my car or my house). It is
obvious that their intelligence collection was actually initiated before
I joined their company (which actually does not make any difference
since they were collecting the information at my private property (house
and car)). So since they collected my business information at my private
property, they indeed violated the Economic Espionage Act of 1996. So
the U.S. companies ARE actively violating this Act. What else can I tell
you about doing the business in the U.S.A - and what can I conclude
about the United States of America ... ?
I have listed some previously communicated details below:
(In fact, there have been some interesting cases, where the U.S.A.
locals in Atlanta have been very deceitful toward their international
managers (I have seen this) and ownership for the benefit of local
investments and companies ---> actually the excellent use of the EEA
against the U.S.A. locals.)
1. I talked in my car with another close person about specific personal
issues and I had never discussed these issues before this discussion.
Soon after a director at my work place started talking about exactly
same my personal issues to me in a private meeting. PRIVATE AUTOMOBILE
COMMUNICATIONS, Atlanta, U.S.A., January-1997.
2. A person came to the same barbershop in Atlanta and started asking
some specific personal questions. This person worked for the same
company as I did. This event is very unusual, because Atlanta is a large
city and has never happened to me before. HUMAN, Atlanta, U.S.A.,
May-1997
3. I was forced to resign from a company based on private audio diary
recordings at my private home. The director used same words and topics
during the exit meeting as I had used prior to this event in my private
diary recordings at my home. PRIVATE PROPERTY COMMUNICATIONS, Atlanta,
U.S.A., June-1997
And there are many other items for the future. All of these situations
are linked to specific companies and certain US intelligence
arrangements. If you are a CEO of any international corporation in the
U.S.A., you might just stop trusting certain telephone companies.
=====
------------------------------
From: Darrel Hankerson <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curve Cryptography
Date: 01 Dec 1999 06:29:36 -0600
[EMAIL PROTECTED] writes:
> I'm currently working on a university project
> about Elliptic Curve Cryptography (ECC). I would
> be very grateful, if any of you could direct me to
> some good sources of information on ECC. Both the
> tough math and the implementation details. Online
> web resources would be the best!
A short primer on EC appears as part of the ECDSA paper (CORR 99-34)
by Johnson and Menezes, found with the technical reports at
http://cacr.uwaterloo.ca
The references within should direct you to more extensive coverage.
--
--Darrel Hankerson [EMAIL PROTECTED]
------------------------------
From: Juergen Thumm <[EMAIL PROTECTED]>
Subject: Re: Open BCRYPT/1 brute-force analysis
Date: Wed, 01 Dec 1999 14:06:10 +0100
David Hopwood wrote:
> That means that the times estimated for a brute force crack (for example,
> 360 years for an 8-character random alphanumeric password, although
> I haven't checked the other assumptions that is based on) must be divided
> by the number of hash instances the attacker can afford to implement and
> run in parallel.
of course - whenever you perform a brute force attack,
using multiple hardware instances in parallel,
you can divide the overall time required by this factor.
i thought this so obvious that i didn't mention it.
nevertheless, i updated the document accordingly.
much more interesting than pure cracking time would be the *cost*.
however, i have no data about it. does anyone know
if md5 and sha were actually ever implemented in hardware
at rates of 256 Mbps? and what do those chips cost?
--
[jthumm(@)lycosmail.com] http://go.to/bcrypt
address altered to deflect spam.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: A dangerous question
Date: Wed, 01 Dec 1999 08:26:48 GMT
On Mon, 29 Nov 1999 23:13:20 -0800, Jim Nelson
<[EMAIL PROTECTED]> wrote:
>Saying this alone constitutes an illegal contract is like betting on the
>Lakers and being arrested for fixing the game.
However there is nothing illegal about the Lakers winning a
basketball game.
>> This is where it breaks down of course. Would you risk the rest of
>> your life in prison in return for a promised payoff by a person who
>> you don't know and can't find?
>
>"Assassination Politics" relies on protocols that guarantee payment without
>either party knowing the identity of the other.
Sorry, there is nothing in there that guarantees payment. Even if
the target person is killed, the person running the pool can just keep
the money. The actual killer has no way to find the person running
the pool and forcing a payout.
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Crossposted-To: comp.security.misc
Subject: Re: brute force versus scalable repeated hashing
Date: Wed, 01 Dec 1999 08:26:47 GMT
On Wed, 1 Dec 1999 10:20:16 -0600, "Tim Wood" <[EMAIL PROTECTED]>
wrote:
>You must however appreciate how easy it is to misrepresent someone by
>changing the position of even one word ;-) or leaving out important concepts
>or provisos ... there is nothing to say everyone has read the earlier post.
It hardly matters, the only thing I was responding to was the
language I specifically quoted. It wouldn't matter if the previous
post was 500k words long.
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Wed, 01 Dec 1999 08:26:46 GMT
On Wed, 1 Dec 1999 07:35:03 GMT, [EMAIL PROTECTED] (Brian Chase)
wrote:
>I think what I'm finding most disturbing, if not just outright disgusting,
>is how quickly disregarded are Scott's challenges to the conventions of
>the cryptology community. Sure he's an asshole, but as a community is it
>not true that we don't conclusively know how secure the contemporary
>algorithms are?
Correct, however walking into a community and calling everyone
names, and insinuating that all the other people in the community are
idiots but he alone knows the one true knowledge is not going to get
you accepted in the community.
>You've got someone who's flying smack in the face of your beliefs and you
>aren't challenging him by trying to prove he's wrong through mathematical
>rigor.
The burden of proof is on the claimant. If has a point to make, it
is up to him to prove he is right, it is not up to us to prove him
wrong.
Johnny Bravo
------------------------------
From: Juergen Thumm <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: brute force versus scalable repeated hashing
Date: Wed, 01 Dec 1999 14:34:37 +0100
Benedikt Stockebrand wrote:
>> the attacker would have to store 36**8 == 2.82e+12 patterns,
> Do you actually expect real-world passwords to be taken from a
> somewhat evenly distributed key space? The only way to enforce this
> is giving your users an assigned password, which in 98% ends up on a
> post-it sticker on the monitor.
modify the word "sticker" to "stihker" and your dictionary will fail.
furthermore consider the approx. 5000 living human languages
on earth. modify every word contained therein with a typo,
and you notice that, sooner or later, you have to check
an evenly distributed key space. it is mainly dependent
on the user's awareness, but secure passwords can be done.
> A TB of disk space is available at somewhere around EUR/US$ 15-20k.
> This isn't exactly big money. Even with decent SCSI disks and a
> proper RAID array it should be well below EUR 50k, but using cheapo
> PCs with four 25GB IDE disks each is cheaper and more efficient for a
> parallelized dictionary attack.
you're right. the storage space isn't the limit today.
still, the table has to be precomputed initially,
taking the same time as a direct brute-force attack.
> The obvious solution to avoid dictionary attacks is exactly what Un*x
> does since the beginning of times: Use a random salt value; preferably
> from a larger value space than old-fashioned Un*x passwords do. Say
> starting at expt(2,32) and going up to expt(2,128) or so.
can't follow that. you cannot mix real random data into the passphrase
entered, it would never create the same output, rendering decryption
impossible. if you use deterministic pseudo-random, with a seed
based on the passphrase itself, the attacker just has to do the same
on every passphrase he tests, at nearly no cost of time.
open bcrypt of course contains a random salt block in it's
file format ( http://members.tripod.de/privacy/format0106.txt )
but this doesn't change the fact that brute-force has to iterate
only over 2.82e+12 combinations - considering an 8-character
optimum-chosen password.
greetings,
Juergen Thumm
--
[jthumm(@)lycosmail.com]
address altered to deflect spam.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Verication - Anyone?
Date: Wed, 01 Dec 1999 03:09:20 +0100
Glenn Larsson wrote:
>
> Hi. I'm developing a Bignum + DH implementation. I need someone
> to confirm that i'm on the right track so what i'm asking for
> is someone to verify this:
>
> (Compiler overflows at 65536^2)
> 65537 ^ 9 =
> 22303807926762253812938859060411589043224577
My TI-89 calclator agrees with this...
> Mod
> 976234876234812734876124246346
> =
> 291762786418173483520827836081
>
But not this, I get 477376334740716679392684972971 (checked it twice)
> Thankfull for answers, since i don't have access to a bignum lib
> and cannot confirm it, that's why i'm developing it...Catch 22.
>
Get yourself a decent calculator.... ;-)
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Wed, 01 Dec 1999 14:46:09 GMT
In article <82134d$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Kenneth Almquist) wrote:
>albert <[EMAIL PROTECTED]> wrote:
>> The problem I'm seeing is that NIST is going to have to parse the information
>> that NSA gives to them, internalize it, have it influence their decision, and
>> then not let us know about it. That seems like a difficult thing to do in my
>> book.
>
>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
Do you really think that if the NSA broke a method that the public
finds safe that it would be eliminated from the AES selection.
You do live in a dream world. The whole goal of the NSA is be able
to read and intercept everything. What you are saying would be
totally out of character for the NSA.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
** 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
******************************
