Cryptography-Digest Digest #947, Volume #8 Fri, 22 Jan 99 11:13:06 EST
Contents:
Re: Who will win in AES contest ?? (Jack Schott)
Re: french law about cryptography (Jan Garefelt)
Re: Pentium III... (R. Knauer)
Re: Pentium III... (R. Knauer)
Re: Help: Which secret key cipher? ("Kazak, Boris")
Re: Crack in Export Laws?? ("Kazak, Boris")
Re: 3DES cracked in 22 hours ??? (Was: Re: (fwd) DES Challenge III Broken in Record
22 Hours !) (Reuben Sumner)
Re: Metaphysics Of Randomness (R. Knauer)
Re: Help: Which secret key cipher? ([EMAIL PROTECTED])
Re: Metaphysics Of Randomness (R. Knauer)
Re: Thoughts on 'BestCrypt'? ([EMAIL PROTECTED])
Re: Who will win in AES contest ?? ([EMAIL PROTECTED])
Re: Help: Which secret key cipher? (Mok-Kong Shen)
Call-For-Papers: SAC '99 (SAC99)
Strong Encryption for 8086 (16 bit) (Andrew Lord)
Re: Help: Which secret key cipher? (Dorina Lanza)
----------------------------------------------------------------------------
From: Jack Schott <[EMAIL PROTECTED]>
Subject: Re: Who will win in AES contest ??
Date: Fri, 22 Jan 1999 05:18:39 -1000
RC6 will be in the top 5 candidates chosen this Spring.
RC6 will be chosen as the next standard. You can
start your product planning now, and dismiss
all of the other candidates. After
considering all aspects related
to its purpose, it rates
overall the best.
But do not take
my word for it.
Evaluate it
youself.
Fast.
Secure.
Small.
Respected.
Tested.
Flexible.
Simple? No.
Sophisticated? Yes. Key dependent key schedule, data dependent data
rotations, no S-Box means no differential cryptanalysis. Parameterized
versions mean AES can select several versions for different uses, even a
reduced version.
------------------------------
From: [EMAIL PROTECTED] (Jan Garefelt)
Crossposted-To: talk.politics.crypto
Subject: Re: french law about cryptography
Date: 22 Jan 1999 14:08:52 +0100
[EMAIL PROTECTED] () wrote:
> 19 jan 1999. the french prime minister announced that the gouvernement
> will allow the key size up to 128bytes.
["bytes" above should be "bits"]
...but the greatest about this is that it only a temporary measure.
The french prime minister, Monsiur Lionel Jospin says, in part:
> Changer la loi prendra plusieurs mois. [---] Ainsi, dans l'attente
> des modifications l=E9gislatives annonc=E9es, le Gouvernement a d=E9cid=E9
> de relever le seuil de la cryptologie dont l'utilisation est libre,
> de 40 bits =E0 128 bits, niveau consid=E9r=E9 par les experts comme
> assurant durablement une tr=E8s grande s=E9curit=E9.
Which in essence means: "Changing the law will take a many months...
so in the meantime we raise the level of cryptography that doesn't
require a licence from 40 to 128 bits, which is considered by experts
to be a level that assures a very high long term security."
> the original text in french:
> http://www.premier-ministre.gouv.fr/PM/D190199.HTM
/Jan Garefelt
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Pentium III...
Date: Fri, 22 Jan 1999 14:18:11 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 22 Jan 1999 01:15:31 GMT, [EMAIL PROTECTED] wrote:
>Yes, I believe it's possible to generate very high quality random numbers,
>without thermal noise hardware, like Intel is planning to add to the Pentium
>III. Random number generators are used for key generation.
That very well may be true if you do not require crypto-grade random
numbers.
>I have quite a lot of experience in this specific issue. I've written about
>five generations of cryptographic random number generators for assorted
>applications on Intel machines. The latest generation I believe makes
>extreemly high quality random numbers.
Please elaborate.
Also you might want to join the thread on sci.crypt entitled
"Metaphysics of Randomness" where we are discussing the fundamentals
of crypto-grade random number generation in terms of considerations
such as Kolgomorov-Chaitin complexity theory, Godel's Theorem and
Turing's Halting Problem, decorrelation schemes for text ciphers,
digit expansion generators for irrational numbers and transcendentals
and other schemes to generate random numbers.
To date no one has come up with a proveably secure method other than a
hardware TRNG - although some have claimed their methods are
practically secure to a very close level of approximation. The
criterion is to produce an OTP cipher system which can withstand a
Bayesian attack, yet not require distribution of the pads.
>At least a dongle would work with your replacement processor. Of cource if
>your dongle breaks (or you loose it) you may be stuck.
I cracked a dongle once - it is not all that difficult if you trap the
strings it expects and then write a wedge to supply them.
>I like thumbprint or
>retina scans more and more every day. Or a smart card, with a duplicate in
>your safe deposit box (SDB).
I guess my problem is that there is no real need for all this. The
apparent money lost in pirated software is far less than the money
gained when people buy the S/W later, especially when you take into
account that the people who pirate S/W can't or won't buy it if they
have to until they can afford it.
This obsession with sticking one's nose into every nook and cranny of
consumer activities is fueled by companies who profit from promoting
the technology to do it. Then at a later date it is discovered that
the intrusions were worthless, and in many cases even
counterproductive, in commercial terms.
Bob Knauer
"It is not the function of our government to keep the citizen from
falling into error; it is the function of the citizen to keep the
government from falling into error."
--Justice Robert H. Jackson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Pentium III...
Date: Fri, 22 Jan 1999 14:21:13 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 22 Jan 1999 08:48:54 GMT, [EMAIL PROTECTED] wrote:
>If you are looking for something more secure, see my article "One-Time Pad
>Cryptography" in the Oct. 1996 Cryptologia.
Is that posted to the web? If so, could you give us the link.
Bob Knauer
"It is not the function of our government to keep the citizen from
falling into error; it is the function of the citizen to keep the
government from falling into error."
--Justice Robert H. Jackson
------------------------------
From: "Kazak, Boris" <[EMAIL PROTECTED]>
Crossposted-To: nl.comp.crypt
Subject: Re: Help: Which secret key cipher?
Date: Fri, 22 Jan 1999 09:26:08 -0500
Reply-To: [EMAIL PROTECTED]
Graham Jones wrote:
>
> I plan to encrypt and send a single message using a shared secret key
> scheme. I do not intend to send subsequent messages using this scheme.
> Could someone please point out to me the advantages of using a block
> cipher such as DES, over a simple algorithm such as an exclusive-or of
> the plaintext against the key. Note that the key length can be equal to
> the length of the plaintext.
>
> I realise that by using the XOR technique, the key can easily be
> recovered once the plaintext is known, but I'm not concerned about this
> in a one-shot situation.
>
> Also, I have little concern over the speed at which an XOR can be
> performed in comparison to DES. The application of the message involves
> a lengthy checking process; hence if an attack involved the trial of
> each key combination, then the time taken to check each recovered
> message would far outweigh the duration of each decryption pass.
>
> Any advise would be very much appreciated.
> --
> Graham Jones
================================
Your problem will be - how do you find a secure channel to pass the
key. If you have such a secure channel, and if your key and message are
of the same length, why not use this channel to pass the message itself
(especially if it is a one-time need)?
Respectfully BNK
------------------------------
From: "Kazak, Boris" <[EMAIL PROTECTED]>
Subject: Re: Crack in Export Laws??
Date: Fri, 22 Jan 1999 09:20:07 -0500
Reply-To: [EMAIL PROTECTED]
Paul Rubin wrote:
>
> This is called Server Gated Cryptography. It's present in
> Netscape Navigator 4.x and MSIE 4.x browsers and there's a
> patch for MSIE 3.x to support it. In order to enable it,
> your web server needs a special certificate (an SGC certificate)
> which at the moment is only available from Verisign (Global ID).
==============
However, technically it seems equivalent to just sending a cookie
and configuring the browser remotely. I would not be surprised if
the exact procedure will be hacked, listed and posted on the Web
for everybody's use. Especially now, when the source code of
Netscape products is opened.
> Global ID's are available only to US corporations and overseas
> companies and banks under certain circumstances. See the
> Global ID page in the web server security section of www.verisign.com
> for more info. Basically, you're allowed to get these certificates
> and enable strong cryptography in exportable browsers only in
> applications that the US goverment approves of--and that's been
> the case all along. It's just a little more streamlined now.
==============================
But then apparently it is the first step. USA banks have lots of foreign
customers, and they don't want to lose this hefty supplement to their
business. The pressure to allow strong cryptography in exportable
browsers can only increase with time. They want their overseas clients
to be able to access their accounts on-line.
>
> Interestingly, I've been hearing from some server vendors that
> they can't get Global ID's without a crypto export license--even to
> ship servers to domestic US customers, even if the servers will
> connect only to domestic US clients, so no exporting is involved.
> What a pain!
===========================
Server vendors should ally themselves with the banks, this union will
be VERY powerful...
Thanks for comment BNK
------------------------------
From: [EMAIL PROTECTED] (Reuben Sumner)
Subject: Re: 3DES cracked in 22 hours ??? (Was: Re: (fwd) DES Challenge III Broken in
Record 22 Hours !)
Date: 22 Jan 1999 12:49:32 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 21 Jan 1999 10:14:46 -0000, Sam Simpson <[EMAIL PROTECTED]> wrote:
>Assuming 3DES has an effective keylength of 112-bits then it would take
>around 329293306 years on average to break a single key.
>
>This figure is based on the peak keys per second figure (250 Billion) quoted
>in the EFF/RSA press release.
I'm afraid I have to dissagree with your calculation.
>> kps:=250*10^9; // keys per second
250000000000
>> spy:=60*60*24*365.24; // seconds per year (average year)
31556736.0
>> kpy:=kps*spy; // keys per year
7889184000114802736.0
>> 2^111/kpy;
329076927259548.0
2^111 is the average number of keys you need to search. Thus the total number
of years is 329,076,927,259,548. That is 329 trillion not 329 million.
Even just searching 64 bits (ie the RC5-64 search) would take 1.17 years.
The real threaght is not distributed.net. It is amusing and a demonstration
that there are lots of wasted CPU cycles out there, but not a real threaght.
In the paper by Matt Blaze et al it is estimated that a $10 custom ASIC
can test about 200M keys/second. At that rate a $10M computer could break
64 bits in an average of 12.8 hours. Compare that to 1.17 years.
Even only 80 bits of something like skipjack (assuming brute force is your
best attack) would take a $1B attack 1 year (on average) to crack.
Reuben
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Fri, 22 Jan 1999 14:45:28 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 22 Jan 1999 08:12:34 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>Like most things to do with knowledge, randomness is contextual.
That is crucially imporant to understand in Quantum Mechanics. Until a
context is posited, particles behave completely randomly. Once the
context is posited where an interaction with the environment can
occur, you get effects that are not random.
>The key is not "random" *with respect to the ciphertext it was
>used to produce*. You can easily demonstrate that by using it
>to with confidence decipher the ciphertext (to a highly coherent
>plaintext), something a number "chosen at random" has little
>chance of doing.
Indeed! The random number has interacted with something in a given
context, namely it has interacted with the message to produce the
ciphertext. As soon as it did that, it lost its randomness.
The fact that the key lost its randomness when it was used to produce
the ciphertext gives it the property that it can decipher that
particular ciphertext.
Bob Knauer
"It is not the function of our government to keep the citizen from
falling into error; it is the function of the citizen to keep the
government from falling into error."
--Justice Robert H. Jackson
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: nl.comp.crypt
Subject: Re: Help: Which secret key cipher?
Date: Fri, 22 Jan 1999 14:37:04 GMT
In article <[EMAIL PROTECTED]>,
Graham Jones <[EMAIL PROTECTED]> wrote:
> I plan to encrypt and send a single message using a shared secret key
> scheme. I do not intend to send subsequent messages using this scheme.
> Could someone please point out to me the advantages of using a block
> cipher such as DES, over a simple algorithm such as an exclusive-or of
> the plaintext against the key. Note that the key length can be equal to
> the length of the plaintext.
>
If the key length is the actaull length of the text nothing
can beat A OTP which is the method your are describing. However
one problem with a OTP is that transmission errors may mean
that the file you decode is not really the file you sent.
If this is not critcal that what you have is enough.
If it is critical you can zip the file and then encrypt
so that one can check the validity of the zip file as some
assurance that the correct file was sent intact.
Or you could use an "all or nothing encryption" like
scott19u which means the file will be totally garbage if
there are any errors in recieving the file but either you
get exactly what was encrypted or nothing. But it is much
slower than either DES or the OTP.
Or you can do various combinations of the above.
> I realise that by using the XOR technique, the key can easily be
> recovered once the plaintext is known, but I'm not concerned about this
> in a one-shot situation.
>
> Also, I have little concern over the speed at which an XOR can be
> performed in comparison to DES. The application of the message involves
> a lengthy checking process; hence if an attack involved the trial of
> each key combination, then the time taken to check each recovered
> message would far outweigh the duration of each decryption pass.
>
> Any advise would be very much appreciated.
> --
> Graham Jones
>
David A. Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Fri, 22 Jan 1999 14:51:58 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 21 Jan 1999 22:15:48 -0600, "R H Braddam"
<[EMAIL PROTECTED]> wrote:
>How about the fact that the plaintext can be used to
>recover the random number in the same way? Doesn't that
>make the random number "computable" because you can get
>it by XORing the cipertext with the original plaintext?
To continue this wild metaphysical speculation, I would comment that
the plaintext is not random. It can be used to operate on the random
ciphertext to produce the non-random key.
The error in your statement above is that you consider the key to be
random after it has been used to encrypt the message, which is not
what we are saying. Once the random key is used to encrypt the
message, it loses its randomness because it is no longer just one
possible sequence from a pool of equiprobable sequences. Once it is
used to encrypt the message, it is not random any more - it is very
unique in that it is the only key that can decrypt the random
ciphertext.
Bob Knauer
"It is not the function of our government to keep the citizen from
falling into error; it is the function of the citizen to keep the
government from falling into error."
--Justice Robert H. Jackson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Thoughts on 'BestCrypt'?
Date: Fri, 22 Jan 1999 14:48:53 GMT
[I'm involved with ScramDisk - a free version of BestCrypt, so take my
comments with a pinch of salt!]
In article <MPG.11120c57db94f023989680@localhost>,
[EMAIL PROTECTED] (Morgan Schweers) wrote:
> Greetings,
> I'm just curious what the prevailing thought about BestCrypt is these
> days? Given that it has an IDEA plug-in now with source as well, appears
> to be pretty professional on their web page, and seems overall pretty
> open for a commercial product, I don't really get the 'Snake Oil' feeling
> from it at least...
At least you can check there are no obvious flaws in the cipher. However, it
is clearly possible that bugs exist in the periphery code that could serious
damage the overall strength of the package. Reviewing just the abstract
cipher code is insufficient.
Why don't they just release the source code for independent review (as do
PGP)?
> Does anyone else use it? Are there any alternatives that do the same
> thing?
Depends on your OS.
If you use 95/98 then try ScramDisk (URL in my SIG) - it's free and comes with
complete source code. Supports IDEA, 3DES, Blowfish etc etc
If you need NT support then have a look at PGPDisk - which is a very nice
package.
Cheers,
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Who will win in AES contest ??
Date: Fri, 22 Jan 1999 14:52:53 GMT
In article <789p0m$ltm$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Coen L.S. Visser) wrote:
> Brad Aisa <[EMAIL PROTECTED]> writes:
> >[EMAIL PROTECTED] wrote:
>
> >> The [AES] winner will be one of the entries that the NSA has entered
> >> which to the public will seem secure.
>
> >Prove it.
>
> Oh come on, you know as well as David Scott that such a claim can never
> be verified to be true or false. Why waste time with such claims (or
> trying to prove it which is impossible)?
>
Sir I think the main reason such time is wasted is that I have a large
"hate fan club" They get restless and disapointted if I don't toss a bone
now and then for them to chop on. But then again maybe the guy lacks your
level of intelligence and thinks that I actually have a proof in which case
I guess I have to just leave him frustrated and with hold any proof.
> >> If the method was any good then it would not be so easily available.
>
> >This is refuted by the fact that very many excellent cryptographic
> >techniques already exist and are publicly available.
>
> The US proposes a system of export restrictions on strong crypto systems as
> international policy. Wouldn't it be against their interest if they
> supported the development of a extremely strong cipher that would be the
> next international standard?
>
> >> The US government would never allow something to be used that it
> >> can not easily break.
>
> >Duh. If it can break it, then so can others. The U.S. govt doesn't have
> >a monopoly on bright cryptanalysts.
>
> But at this point in time they may have the largest crypto
> organization. I wouldn't know any other government, academic
> or commercial organization that could measure up against the NSA.
> Maybe there is something in China the general public doesn't know about.
>
I think the Chinese are an extremely brillant people and if they had
the desire to become the worlds best in crypto they could. But I think
as a people they lack the will. Lets hope they remain a sleeping giant
and leave this fertile field alone or the rest of the world could be
in trouble.
> Regards,
>
> Coen Visser
>
ENJOY
David A. Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: nl.comp.crypt
Subject: Re: Help: Which secret key cipher?
Date: Fri, 22 Jan 1999 16:04:25 +0100
Kazak, Boris wrote:
>
> Graham Jones wrote:
> --------------------------------
> Your problem will be - how do you find a secure channel to pass the
> key. If you have such a secure channel, and if your key and message are
> of the same length, why not use this channel to pass the message itself
> (especially if it is a one-time need)?
I think one can more profitably discuss without the assumption of
key length equal to message length of Jones' original post, i.e.
only assuming that the same key (secret information) is used for
driving a stream cipher in comparison to a block cipher. (OTP is a
topic difficult to treat and easily leads to a tremendous thread.)
Further, his assumption that the message is not in natural language
should be dropped.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (SAC99)
Subject: Call-For-Papers: SAC '99
Date: 22 Jan 1999 14:46:49 GMT
***** CALL FOR PAPERS *****
SAC '99 - Sixth Annual Workshop on SELECTED AREAS IN CRYPTOGRAPHY
August 9 & 10, 1999
Queen's University, Kingston, Ontario, Canada
Original papers related to the following themes are solicited.
* Design and Analysis of Symmetric Key Cryptosystems
* Efficient Implementations of Cryptographic Systems
* Cryptographic Solutions for Web/Internet Security
The deadline to receive submissions is April 30, 1999.
The Proceedings will be published by Springer-Verlag in the
Lecture Notes in Computer Science (LNCS) series.
Detailed instructions for submitting papers are available at
"www.engr.mun.ca/~sac99/cfp"
As well, general information on the Workshop will be available on
the SAC '99 web page at
"www.engr.mun.ca/~sac99"
Email inquiries may be directed to "[EMAIL PROTECTED]".
------------------------------
From: [EMAIL PROTECTED] (Andrew Lord)
Crossposted-To: comp.lang.asm.x86
Subject: Strong Encryption for 8086 (16 bit)
Date: 22 Jan 1999 15:08:04 GMT
Reply-To: [EMAIL PROTECTED]
[cross posted - see headers]
I'm looking for a *strong* encryption algorithm the has been implemented
in 8086 assembler to use on the Psion PDA. ( Eg TwoFish, SkipJack. )
I've got "intermediate" 8086 experience, lots of C and ZERO cryptoanalysis, so
I could struggle at porting some C code, but it would be ever so nice if
someone has implemented and tested this for 8086 already. Or can recommend an
algorithm that is the easiest to implement on a 16bit processor.
rgds,
Andy L.
--
Andy Lord
http://w3.to/lordcentre
mailto:[EMAIL PROTECTED]
------------------------------
Date: Fri, 22 Jan 1999 10:21:56 -0500
From: Dorina Lanza <[EMAIL PROTECTED]>
Subject: Re: Help: Which secret key cipher?
Kazak, Boris wrote:
> Your problem will be - how do you find a secure channel to pass the
> key. If you have such a secure channel, and if your key and message are
> of the same length, why not use this channel to pass the message itself
> (especially if it is a one-time need)?
The OTP concept has taken a lot of criticism along this and one other line ot
thought. The insight needed to counter this argument is that the secure
channel probably does not have convenient timing characteristics.
The other complaint about OTP-style security is that it takes too much pad
material. However, the density of data storage is now so high that very
infrequent use of a secure channel can support long term (months or years)
worth of traffic in most cases.
Consider hand-carried DVD as a secure channel. It is incredibly slow and
expensive. But, you get gigabytes worth of pad. Since hand carrying disks
is easy, we can assume that more than one disk is carried at once. A
reasonable amount of luggage would support a terabyte of pad.
Once the pad is in place, message exachange can ocur at any convenient time
with provably secure message handling. As the density of magnetic storage
goes up I expect to see products utilizing OTPs appear to exploit the
opportunity.
Point is that the existence of the secure channel of does not eliminate tthe
requirement for use of an insecure channel of identical bandwidth. The
dissimilar quantization of the channel capacity may make the insecure channel
preferable for operational reasons.
------------------------------
** 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
******************************
