Cryptography-Digest Digest #733, Volume #10 Mon, 13 Dec 99 17:13:01 EST
Contents:
Re: Are thermal diodes as RNG's secure (Scott Nelson)
Re: Linear Congruential Generators ("Gary")
Re: Linear Congruential Generators ("Gary")
Re: Insecure PRNG? (Mok-Kong Shen)
Re: Insecure PRNG? (Mok-Kong Shen)
Re: Why no 3des for AES candidacy (Anton Stiglic)
Re: Insecure PRNG? (CLSV)
Re: Why no 3des for AES candidacy (SCOTT19U.ZIP_GUY)
Re: How can you tell? (Tim Tyler)
Economic Espionage Act of 1996 and the U.S.A. government's violations ("Markku J.
Saarelainen")
Re: Linear Congruential Generators (Mok-Kong Shen)
RSA Cryptography Today FAQ (1/1) ([EMAIL PROTECTED])
Re: Insecure PRNG? (CLSV)
Re: Linear Congruential Generators ("Tony T. Warnock")
Re: Data Encryption in Applet? ("Law Wun Suen, Brian")
Re: Insecure PRNG? (Mok-Kong Shen)
Re: Attacks on a PKI (Darren New)
Re: Data Encryption in Applet? (Chris Wolfe)
Re: Insecure PRNG? (Mok-Kong Shen)
Re: Simple newbie crypto algorithmn (Eric Hambuch)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Are thermal diodes as RNG's secure
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Dec 1999 18:26:12 GMT
On Mon, 13 Dec 1999 16:58:56 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Bill Unruh <[EMAIL PROTECTED]> wrote:
>: [EMAIL PROTECTED] (Lincoln Yeoh) writes:
>
>[removing biases from hardware sources of randomness]
>
>: ]How can we cook such output?
>
>: Eg, if you suspect that the output is not really random, but is
>: "partially" random, so that say a fraction f of the information really
>: is random,then you could feed say 128/f bits into a hash function like
>: MD5 and use the 128 bits of output. That output should be "fully"
>: random.
>
>Yes, although you seem to be using "should" in the same sense as in the
>sentence:
>
>"The output from a pseudo-random number generator should be fully random."
>
>If any practical hash were as good at distilling entropy as this,
>it would be a miracle.
If the hash produced a random (rather than evenly distributed)
128 bits based on the input 128/f bits, then the number of states
would only be 1/e*2^128. That sounds bad, but it's less than
2 bits off of perfect, or under 2% error. Secure hash
functions aren't perfect, but they are very good.
I think a much bigger problem is the estimation of f.
Historically, entropy estimates have been off by as much as
two orders of magnitude. Being wrong by a factor of 2
is not uncommon.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Mon, 13 Dec 1999 18:25:07 -0000
Tony T. Warnock wrote in message <[EMAIL PROTECTED]>...
>A long cycle (128 bit) LCG with only the leading bit exposed is
>difficult to decode but it should be possible with a lattice reduction
>computation.
>
How much of it's output is required for a lattice attack?
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Mon, 13 Dec 1999 18:30:22 -0000
The non linear mix was suggested so that instead of solving AXn+B+CYn+D, one
would need to solve the non linear problem (AXn+B)^(CYn+D).
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Mon, 13 Dec 1999 19:39:03 +0100
Guy Macon wrote:
>
> Actually, this is an excellent analogy. Steel has tensile strength
> that is much better than stone but the compressive strength isn't
> so superior. Wood has different strengths in different directions.
>
> As an erngineer, I can not answer the question "what is stronger:
> a steel or a wooden beam?". It depends on what kind of load and
> on what kind of support the beam has. Just like crypto strength
> depends on what kind of attack.
The point is that, given all the details, an engineer can normally
do computations to obtain fairly well an estimate of the load
carrying capacity/behaviour of a structure, becuase all the theories
are public, while in crypto some knowledge are purposedly kept
from public access. That's why one can't have the same kind of
'sureness' in evaluating crypto algorithms as the engineer does, I
believe.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Mon, 13 Dec 1999 19:38:53 +0100
CLSV wrote:
> It does not matter, technically, if there are analysis methods
> that are kept secret from the public or that they just haven't been
> invented yet. There is nothing special about it.
The first case is clearly critical, because it means that the
security you have evaluated is deceptive.
> I think, correct me if I'm wrong, that you have trouble with the
> fact that most people concern themselves with finding new
> upperbounds for the effort to break a cipher rather than attacking
> the interesting problem of finding proper lowerbounds.
In that matter I personally like to take the position common to
numerical computations. If the bounds are not too wide apart, then
they are o.k., otherwise barely useful.
M. K. Shen
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Mon, 13 Dec 1999 13:49:01 -0500
Uri Blumenthal wrote:
>
> > >One good reason:
> > >The AES is supposed to support the following different key sizes:
> > > 128, 192, 256
> > >
> > >You can see why 3-DES, with it's single sized 168 bit key,
> > >does not fit in this categorie.
>
> No I can't - there are ways to securely make key of any length
> (from 64 bis to 768*3 bits) for 3DES.
Hunn??? 3DES uses DES, 3 times, with 3 different keys. The result
is a cipher that has a key of size 3*(size of key for DES) = 168 bits.
If we proove that the security given by this method is just 2 bits, the
cipher still remains a cipher that needs uses a 168-bit key.
I would realy be interested in seeing you come up with a 72 bit key
3-DES. Do you have any idea of what you are talking about?
Anton
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Mon, 13 Dec 1999 18:58:28 +0000
Mok-Kong Shen wrote:
> Guy Macon wrote:
> > As an erngineer, I can not answer the question "what is stronger:
> > a steel or a wooden beam?". It depends on what kind of load and
> > on what kind of support the beam has. Just like crypto strength
> > depends on what kind of attack.
> The point is that, given all the details, an engineer can normally
> do computations to obtain fairly well an estimate of the load
> carrying capacity/behaviour of a structure, becuase all the theories
> are public,
Yes, but you assume that all the details can be known.
How would the strengths be in two hunderd years?
Or in extreme conditions like a fire or an earthquake.
These are all situations that require special calculations.
The point is we don't know what situations arise so we will
consider only the most likely risk profile. That is the same
way to treat security. Sometimes an earthquake destroys many
buildings, sometimes a security architecture is broken, these
things happen.
Regards,
Coen Visser
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Why no 3des for AES candidacy
Date: Mon, 13 Dec 1999 20:12:46 GMT
In article <8338sf$8ep$[EMAIL PROTECTED]>, "Tim Wood" <[EMAIL PROTECTED]>
wrote:
>
>
>Anton Stiglic wrote in message <[EMAIL PROTECTED]>...
>>UBCHI2 wrote:
>>
>>> Why isn't 3des being considered for the AES? Is it because it is slower
>than
>>> DES?
>>
>>One good reason:
>>
>>The AES is supposed to support the following different key sizes: 128, 192,
>256
>>
>>You can see why 3-DES, with it's single sized168 bit key, does not fit in
>this
>>categorie.
>
>of course it's effective key length (strength) is 112bit not 168bit...
>
it depends on how you do 3 DES
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***
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: How can you tell?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Dec 1999 19:18:18 GMT
Pelle Evensen <[EMAIL PROTECTED]> wrote:
: John ([EMAIL PROTECTED]) wrote:
: To write a "stream cipher" that will pass all known tests for randomness;
[snip KISS and Diehard]
: Moral: You can't get any information whatsoever about a cryptosystems
: security from statistically measuring the output data. [...]
I'm not quite about this. *If* you know a PRNG-based stream-cypher - and
it dramatically and reproducibly fails any test for randomness, you can
discard it straight away.
I /think/ I understand what you mean, though. Passing tests for
randomness proves nothing positive about security. Failing them
indicates insecurity only under certain circumstances.
: This also works the other way round, you could of course add redundant data
: to a secure algorithm's output to make the data fail any such tests. Not
: that I know why anyone would do that [...]
;-)
It /could/ help. You could include fake messages that are easier to
decrypt than the real ones and /look/ as though they have been padded out
with some "random" data to conceal their length or their headers.
If you can conceal the presence of the /real/ message (which is in the
"random" padding) from attackers in this way, that is great.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Radioactive cats have 18 half-lives.
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia
Subject: Economic Espionage Act of 1996 and the U.S.A. government's violations
Date: Mon, 13 Dec 1999 14:20:36 +0000
I do believe that the government of the U.S.A. with the assistance of
its intelligence agencies and commercial agencies have violated my
private property rights and taken away my intellectual property ("Genie
Services") by listening secretly my own R&D development and audio
recordings, when I did my R&D work at my own private property in the
summer of 1998. I do believe that this is the violation of the Economic
Espionage Act of 1996 among other laws and regulations. I do believe
that the U.S.A's intelligence and other agencies are involved in
counter-intelligence activities only to steal a private person's and/or
company's intellectual properties. Since early 1990's my experience in
many international corporations has enabled me to create an
understanding how the U.S.A.'s individuals and corporations are behaving
offensively against international business people and their intellectual
properties.
I have informed many Ambassadors and other diplomatic people about this
matter.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Mon, 13 Dec 1999 21:01:47 +0100
Tony T. Warnock wrote:
>
> If you use LCG's with power-of-two modulus, there are some strong
> structural relations. The bottom bit (assuming full cycle) alternates
> 010101, then next bit has a cycle of length 4, then next is cycle 8,
> etc. The first half of the entire cycle is the equal to the second half
> with the top bit flipped. The first, second, third, and fourth, quarter
> cycles are identical except for the first two bits, etc. For non-full
> cycle generators, the same holds except that the cycle is only 1/4 as
> long.
>
> A long cycle (128 bit) LCG with only the leading bit exposed is
> difficult to decode but it should be possible with a lattice reduction
> computation.
I believe that the impact of the phenomenon described can be reduced
or largely eliminated in some (admittedly heuristic) ways: (1) schuffle
the output, (2) combine outputs of two or more generators through
addition, (3) convert (standardize) the output to a real in [0, 1)
and then obtain an integer of a fixed (smaller) size e.g. 24 bits,
(4) pseudo-randomly activate a number of generators, interleaving
their outputs. I made use of these in an encryption algorithm of
my own. If someone has ideas of other and better ways of
combating the 'regularities' in LCPRNGs, I should appreciate very
much to know them.
M. K. Shen
===============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
Crossposted-To:
talk.politics.crypto,alt.security.ripem,sci.answers,talk.answers,alt.answers,news.answers
Subject: RSA Cryptography Today FAQ (1/1)
from: [EMAIL PROTECTED]
reply-to: [EMAIL PROTECTED]
Date: 13 Dec 1999 20:02:24 GMT
Archive-name: cryptography-faq/rsa/part1
Last-modified: 1997/05/21
An old version of the RSA Labs' publication "Answers to Frequently Asked
Questions about Today's Cryptography" used to be posted here until May
1997. These postings were not sponsored or updated by RSA Labs, and
for some time we were unable to stop them. While we hope the information
in our FAQ is useful, the version that was being posted here was quite
outdated. The latest version of the FAQ is more complete and up-to-date.
Unfortunately, our FAQ is no longer available in ASCII due to its
mathematical content. Please visit our website at
http://www.rsa.com/rsalabs/ to view the new version of the FAQ with your
browser or download it in the Adobe Acrobat (.pdf) format.
RSA Labs FAQ Editor
[EMAIL PROTECTED]
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Mon, 13 Dec 1999 20:05:37 +0000
Mok-Kong Shen wrote:
> CLSV wrote:
> > It does not matter, technically, if there are analysis methods
> > that are kept secret from the public or that they just haven't been
> > invented yet. There is nothing special about it.
> The first case is clearly critical, because it means that the
> security you have evaluated is deceptive.
It may be a philosophical difference but technically
you have exact the same information: you can with certainty
say that there is no publicly known attack. Whether the
Mossad or the NSA or some academic researcher publish an attack
tomorrow can never be known. It would be deceptive if you don't
communicate that but otherwise the situation is the same.
Regards,
Coen Visser
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Mon, 13 Dec 1999 13:32:39 -0700
Reply-To: [EMAIL PROTECTED]
Gary wrote:
> Tony T. Warnock wrote in message <[EMAIL PROTECTED]>...
> >A long cycle (128 bit) LCG with only the leading bit exposed is
> >difficult to decode but it should be possible with a lattice reduction
> >computation.
> >
> How much of it's output is required for a lattice attack?
I don't know. A lower bound should be about 2*Log(cycle) and an upper bound
of Sqrt(cycle).
------------------------------
From: "Law Wun Suen, Brian" <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.java.security,microsoft.public.java.security,comp.lang.java.programmer
Subject: Re: Data Encryption in Applet?
Date: Tue, 14 Dec 1999 04:24:37 +0800
Tim Wood wrote:
> wrote in message <[EMAIL PROTECTED]>...
> >Hi
> >
> >I am looking for a way to encrypt data through an applet using symmetric
> >(or asymmetric) encryption. I thought of sending an applet containing a
> >symmetric key to a client.
>
> How? If the symmetric key is not encrypted when you send it, it could be
> intercepted and used to read the, client side encrypted, data.
>
I think if the application have to consider about the performance, better to
use both
(symmetric and asymmetric) encryption together. It really look like how the
SSL
work. You generate a random key (secret key) for the symmetric encryption and
encrypt this securet key with your own private key. The client program
receive the key and
decrypt it by the public key. Then use that secret key for that sesssion
communication.
This solution would solve the key distrubution problem as well as the
performance problem.
Rgds,
Brian Law
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Mon, 13 Dec 1999 21:53:39 +0100
CLSV wrote:
>
> Mok-Kong Shen wrote:
>
> > Guy Macon wrote:
>
> > > As an erngineer, I can not answer the question "what is stronger:
> > > a steel or a wooden beam?". It depends on what kind of load and
> > > on what kind of support the beam has. Just like crypto strength
> > > depends on what kind of attack.
>
> > The point is that, given all the details, an engineer can normally
> > do computations to obtain fairly well an estimate of the load
> > carrying capacity/behaviour of a structure, becuase all the theories
> > are public,
>
> Yes, but you assume that all the details can be known.
> How would the strengths be in two hunderd years?
> Or in extreme conditions like a fire or an earthquake.
> These are all situations that require special calculations.
> The point is we don't know what situations arise so we will
> consider only the most likely risk profile. That is the same
> way to treat security. Sometimes an earthquake destroys many
> buildings, sometimes a security architecture is broken, these
> things happen.
I personally would prefer to take an engineer's standpoint in
matters concerning crypto security. If something is not sufficiently
fully known, employ a factor of safety to take care of the uncertainty.
Of course, here more or less subjectivity enters. (In your example,
the question of which scale of earthquake to be reasonably taken care
of arises.) On the other hand, I have yet no concrete idea of how
this could be properly implemented and I am not sure whether this
renders the task of comparing two given algorithms easier or harder
and whether such a non-rigorous approach could be accepted by users
and experts/professionals of crypto at all.
M. K. Shen
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Attacks on a PKI
Date: Mon, 13 Dec 1999 21:05:57 GMT
Helger Lipmaa wrote:
> Secure electronic commerce necessitates wide-scale employment of
> public-key cryptography
Ummm.... I'm pretty sure folks were doing secure electronic commerce quite a
while before PK became popular, and possibly before PK was even invented.
There were even secure *internet* commerce systems that didn't rely on
cryptography at all. Or does "electronic commerce" mean something different
on sci.crypt, like "commerce based on encryption" or some such?
--
Darren New / Senior Software Architect / Dai Ye
San Diego, CA, USA (PST). Cryptokeys on demand.
"Perl - The BASIC of the 90's"
------------------------------
From: Chris Wolfe <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.java.security,microsoft.public.java.security,comp.lang.java.programmer
Subject: Re: Data Encryption in Applet?
Date: Mon, 13 Dec 1999 15:59:36 -0500
I see a big, big problem with that key distribution. By definition if
the key can be decrypted using your public key, than anyone who
intercepts the transmission can decrypt it.
If the applet (or HTML page) contains the public key of the server, and
then encrypts the session key using that key, the connection should be
fairly secure. (The only holes I can see is someone modifying the code
in transit or getting the private key off the server). The session key
is then used in a standard symmetric cipher to handle the rest of the
transfer.
Cheers,
Chris
===========================================================
Me: <http://qlink.queensu.ca/~9cw4>
If it wasn't for C, we would be using BASI, PASAL and OBOL!
If you're not confused, you're not paying attention.
===========================================================
"Law Wun Suen, Brian" wrote:
>
> Tim Wood wrote:
>
> > wrote in message <[EMAIL PROTECTED]>...
> > >Hi
> > >
> > >I am looking for a way to encrypt data through an applet using symmetric
> > >(or asymmetric) encryption. I thought of sending an applet containing a
> > >symmetric key to a client.
[snip]
> I think if the application have to consider about the performance, better to
> use both
> (symmetric and asymmetric) encryption together. It really look like how the
> SSL
> work. You generate a random key (secret key) for the symmetric encryption and
>
> encrypt this securet key with your own private key. The client program
> receive the key and
> decrypt it by the public key. Then use that secret key for that sesssion
> communication.
> This solution would solve the key distrubution problem as well as the
> performance problem.
>
> Rgds,
> Brian Law
<extra garbage>
Unfortunately my news server complains about "more included text than
new text" a lot, so these useless filler comments get added to the end.
*sigh*
</extra garbage>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Mon, 13 Dec 1999 22:13:10 +0100
CLSV wrote:
>
> Mok-Kong Shen wrote:
>
> > CLSV wrote:
>
> > > It does not matter, technically, if there are analysis methods
> > > that are kept secret from the public or that they just haven't been
> > > invented yet. There is nothing special about it.
>
> > The first case is clearly critical, because it means that the
> > security you have evaluated is deceptive.
>
> It may be a philosophical difference but technically
> you have exact the same information: you can with certainty
> say that there is no publicly known attack. Whether the
> Mossad or the NSA or some academic researcher publish an attack
> tomorrow can never be known. It would be deceptive if you don't
> communicate that but otherwise the situation is the same.
I am afraid you misunderstood me to some extent. The actual attacks
include both the publically known and the secret (yet already
invented) attacks. It is against all these that the security should
ideally be evalauted. At least this is what most users desire to
know. If the best academics currently can't attack a certain
algorithm but some three lettered agency can, that algorithm is
cracked, isn't it?
M. K. Shen
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: Simple newbie crypto algorithmn
Date: Mon, 13 Dec 1999 22:17:22 +0100
Steven Siew schrieb:
>
1. Keysize is 4856 bits - too long
2. Your program needs more than 1.6 MBytes of memory - really too much !
3. It isn't fast.
4. It uses permutation on a 64 KByte block. I agree, that this is
normally hard to break.
But if you use this algorithm on smaller blocks (e.g. encryption
stream data) I will
become much weaker.
5. Your "fibonacci generator" doen't produce a fibonacci sequence:
fibseq = 607+1;
{
fibseq = ++fibseq % (FIBP+1);
...
}
only: 607,0,1,2,3,4,...,606,607,0,1,2,...
If you had some knowledge of algebra, you would know that you should
use a prime number
for your modulo value (FIBP+1 isn't prime) !
6. If you can break your array fib[] you can easily remove your
XOR-substition. And than
try to break the permutation!
Eric Hambuch
------------------------------
** 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
******************************
