Cryptography-Digest Digest #725, Volume #10 Sun, 12 Dec 99 03:13:02 EST
Contents:
Re: Brute Force Time (Maximum v Probable) (Scott Nelson)
Re: Synchronised random number generation for one-time pads ("Charles Meigh")
Re: Brute Force Time (Maximum v Probable) (Bill Unruh)
Re: New RNG Technique (Guy Macon)
Re: New RNG Technique (Guy Macon)
Re: Insecure PRNG? ("Gary")
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Synchronised random number generation for one-time pads (Guy Macon)
Re: low exponent in Diffie-hellman? (jerome)
Re: New Algorithm (Tim Tyler)
Re: Linear Congruential Generators ("Steven Alexander")
Re: New RNG Technique ("Steven Alexander")
Re: New Algorithm ("Steven Alexander")
Re: some questions about DES (jerome)
Re: If you're in Australia, the government has the ability to modify your files. >>
4.Dec.1999 (zapzing)
Encryption of I-Mail? Someone Invent this Please! (UBCHI2)
Re: Encryption of I-Mail? Someone Invent this Please! (Nike Y. Molar)
Re: Encryption of I-Mail? Someone Invent this Please! (UBCHI2)
Re: Encryption of I-Mail? Someone Invent this Please! (Johnny Bravo)
Re: Attacks on a PKI (lcs Mixmaster Remailer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Brute Force Time (Maximum v Probable)
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Dec 1999 21:24:22 GMT
On 11 Dec 1999 19:35:59 GMT, [EMAIL PROTECTED] (UBCHI2) wrote:
>1) You have a 50% chance of finding the key after only running only half the
>possible keys. Basically, there is a 1 in 2 chance of the attack taking only
>half the time allocated given the total possible number of keys.
>
>2) You only have to search for keys equal to the keylength of the target. For
>example, you only have to search for a key equal to 128, 256, 512, 1024. I
>estimate that less than 1 in 100 people use a key of an "off" size. You don't
>have to search for all keys smaller than 128. This cuts the number of keys
>down by perhaps 50%.
>
>In other words, .5*.5 is only 25%. This corresponds to the time needed to
>attack a key with brute force versus the time allocated given the total number
>of possible keys.
>
>The industry should shift from quoting maximum time to crack a key to quoting
>probable time to crack a key.
>
Producers who list the time taken to break a cipher in a
particular way, have an interest in having it be as large
as possible. In other words, they want you to view their
products in the best possible light. Consumers on the other
hand, have an interest in having uniform numbers to make
comparison "shopping" easier.
Given these two goals, it's seems better to choose
the most generous numbers possible - if you don't
then an unscrupulous producer can dupe some consumers
with inferior products. Not that they won't anyway,
but there's no reason to make it easy for them.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: "Charles Meigh" <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Date: Fri, 10 Dec 1999 20:57:04 -0000
Guy Macon <> wrote in message ...
>> (Charles Meigh) wrote:
> >
> >I'm still thinking that there might be some
> >vastly wide choice of 'celestial' events that could produce truly random
> >numbers that will still be sufficiently similar observed from any two (or
> >more) points on the globe, which would make OTP use more economical.
>
> You have that already. Just generate your random numbers using whatever
> method you prefer and post them in a newsgroup. Or you can put them on
> a CD and sell the CD on a web site. Or broadcast them with a ham radio.
> Getting your random numbers to two or more points on the globe is trivial.
> What is hard is getting your random numbers to exactly two (and no more
> than two) points on the globe and not to any other points on the globe.
> Alas, the latter is what you need if you want to have the shared secret
> that is the basis of OTP encryption.
>
>
But would those methods realistically allow you to distribute a sufficiently
large set of random data that from which enough potential OTP keys can be
generated without allowing brute force attacks. Interception of the pool
of random data is not a concern if it is large enough.
--
Charles Meigh
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Brute Force Time (Maximum v Probable)
Date: 11 Dec 1999 22:13:08 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (UBCHI2)
writes:
...
>The industry should shift from quoting maximum time to crack a key to quoting
>probable time to crack a key.
The estimates are so crude that the difference between the two is
irrelevant.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: New RNG Technique
Date: 11 Dec 1999 17:13:52 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Trevor Jackson, III) wrote:
>> 8.) ECHO does not repeat, it has a period of infinity.
>
>That's a tall one. How did you figure this out?
That's a *wrong* one as well. Basic computer theory says that the
number of possible states of any computer has an upper bound of
two to the power of all bit storage (mostly RAM plus hard disk),
which is less than infinity. In real life you would do better to
calculate this with unused RAM and disk, see how many bits this
program needs to save sate, etc. It's really huge either way,
but not infinite.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: New RNG Technique
Date: 11 Dec 1999 17:17:12 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
><cough>
><cough>
><cough>
><cough>
><cough>
>
>Your security claims are ridiculous :-(
>
I guess this means that your coughin' puts this technique in the coffin...
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: Insecure PRNG?
Date: Sat, 11 Dec 1999 22:18:53 -0000
So is this a quick and relatively secure cipher algorithm?
Most of todays DSP's and CPU's can efficiently perform this algorithm.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: 11 Dec 1999 17:30:22 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Trevor Jackson, III) wrote:
>The geometry of your model has misled you. A simple analysis will
>illustrate the fact. Consider that in half-life T, N/2 particles
>will decay. In the subsequent interval T+1, N/4 particles will decay.
>Thus the intensity numerator (decays) has decreased, but the intensity
>denominator (seconds) is constant. The intensity goes down.
>Exponentially with time.
I think that you are wrong. You are assuming that number of hits
per second is proportional to number of decays per second. It
clearly is not, because only the rate of decays that actually
make it to the detector is proportional to the area facing the
detector, while the number of decays in proportional to the
volume of the radium.
This is why I chose radium. The element that it decays to (Radon)
diffuses out of the sample and can be removed with a ventilation
system. Thus the sample shrinks instead of becoming a mixture
of two elements like some other elements do. (I was also looking
for alpha particle only emmission and a half-life of at least
1000 years).
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: 11 Dec 1999 17:36:09 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Trevor Jackson, III) wrote:
>I don't know why, but this message triggered a small Aha! as I read it. It
>may be possible to construct a device that produces quantum derived
>radiation at a constant rate -- no exponential decay. I'm certain we don't
>have the technology to build such a device today, but if modern crypto is
>as old as practical computers, we may be able to build one in the next
>period of similar length.
>
>Consider the final phase of an object emitting Hawking radiation. The
>final blast of radiation transforms all of the rest mass of the device into
>radiation. What's left over? A singularity. Postulate such a singularity
>captured and mixed with a gas (say hydrogen). At intervals comtrolled by
>the gas density the singularity will interact with (eat) an atom, and
>immediately re-emit the energy as thermal radiation. By maintaining a
>constant pressure in the enclosing vessel one might produce a mean emission
>rate that was constant.
>
>I suppose we don't know enough about the coefficients of interaction of
>such a singularity to determine the feasibility of the technique. But the
>idea of putting such an object to practical use is appealing.
A sample of Radium gets smallers and lighter as it decays into Radon
and the radon escapes. Just build a system that weighs the sample
and adds radium to keep it the same weight. Decay would then be
constant and perpetual (until you stop feeding in more Radium).
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Synchronised random number generation for one-time pads
Date: 11 Dec 1999 17:47:01 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
>
>Guy Macon <[EMAIL PROTECTED]> wrote:
>: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
>
>:>OTPs are [...] useless against simple complete known-plaintext attacks.
>
>: It depends on what you mean by "useless". I would say that being able
>: to send other plaintexts without the attacker being able to decode
>: them is quite usefull, wouldn't you?
>
>If (as I specified) the attacker has a "complete known plaintext", he has
>no need to decode and read the encrypted message - since he knows its
>entire contents completely anyway.
Except for the (huge!) hole of allowing the attacker to substitute his
own plaintext if and only if he can stop the senders messsage, a known
plaintext attack that only reveals the known plaintext and no other
would seem to be, to coin a phrase, useless. Hwat use is there in
deriving information that you already have? I can crack any security
system in existance in my head if that's my criteria for sucess.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: low exponent in Diffie-hellman?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Dec 1999 23:47:27 GMT
On Sat, 11 Dec 1999 03:55:07 GMT, Scott Fluhrer wrote:
>One of us is confused.
probably me.
>The sliding window exponentiation does evaluate
>m^x mod p, with no special preconditions on m, x or p. So, why can't
>you use it?
>I've used it (actually, a varient of it) with DH before, and had no
>problems.
i will look at it, thanks for your help.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: New Algorithm
Reply-To: [EMAIL PROTECTED]
Date: Sun, 12 Dec 1999 00:12:40 GMT
Loney Ramik <[EMAIL PROTECTED]> wrote:
: Jeroen van de Erve <[EMAIL PROTECTED]> wrote:
:>One of the features [...] is [...] full impossibility to crack the
:>encrypted file (of course except the full consideration of all
:>passwords).
: That absurd claim pretty much guarantees that cryptographers won't bother
: to look at it seriously. [...]
FWIW, whenever I see such a phrase I immediately conclude the author
does not know what they are talking about - and that spending any more
time considering their proposals would be futile.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
A good traveller leaves no track.
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Sat, 11 Dec 1999 14:03:22 -0800
It would change it at least somewhat because they would enter not only the
key but a number of rounds as well. With an LCG, if the multiplier and
increment are properly chosen, all possible outputs will be cycled through
before it repeats. I just didn't know if this would create enough
change....it was a fun idea to play with though.
-steven
> The numbers themselves (being entered by a human) will have
> less-than-maximal entropy. Feeding them as a seed to an RNG will
> change their entropy content not one whit.
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: New RNG Technique
Date: Sat, 11 Dec 1999 14:10:48 -0800
It cannot be a truly random generator...sorry.
-steven
> This generator has properties of both a pseudo-random and a true random
> generator, so I'm not sure what category it belongs in. I guess it's in a
> category by itself.
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: New Algorithm
Date: Sat, 11 Dec 1999 14:14:19 -0800
You shouldn't make claims like impossible to break, ever. Also, it's worse
when you are doing it, then asking people to try because nobody has looked
at it yet.
-steven
> One of the features of Wolf_Cub is support of unlimited length of
> password and full impossibility to crack the encrypted file (of course
> except the full consideration of all passwords).
>
> If you're interested, please mail me at: [EMAIL PROTECTED]
> (remove the nospam.). If you use PGP, please include your PGP Public
> Key-ID.
>
> Kind regards,
> Jeroen van de Erve
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: some questions about DES
Reply-To: [EMAIL PROTECTED]
Date: Sun, 12 Dec 1999 01:03:36 GMT
On Sat, 11 Dec 1999 18:11:05 GMT, Tom St Denis wrote:
>DES in it's original form is no longer used.
it is probably still the most used algorithm
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify your
files. >> 4.Dec.1999
Date: Sun, 12 Dec 1999 03:10:41 GMT
Hmmm.
What if someone corrupts the pgp
signing program, such that it is forced
to give the value stored in your file?
Then you would not notice that the
pgp was corrupted becuase the pgp
fiel was corrupted.
I would modify your procedure thusly:
as part of the sign off procedure,
enter a key for a HMAC, and create
the HMAC for some of the most essential
utilities Iincluding your startup file, etc.)
Don't record this in a file, write it down
on a little piece of paper you carry
around with you.
Test the value as part of the sign on
procedure.
ZZ
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Encryption of I-Mail? Someone Invent this Please!
Date: 12 Dec 1999 03:24:44 GMT
Is there any program out there that will let me encrypt my Imail as I enter it.
If not, some entrepreneur in this Newsgroup should start an internet company
to do just that and make millions.
------------------------------
From: [EMAIL PROTECTED] (Nike Y. Molar)
Subject: Re: Encryption of I-Mail? Someone Invent this Please!
Date: Sun, 12 Dec 1999 03:45:31 GMT
[EMAIL PROTECTED] (UBCHI2) wrote:
>Is there any program out there that will let me encrypt my Imail as I enter it.
> If not, some entrepreneur in this Newsgroup should start an internet company
>to do just that and make millions.
What's Imail?
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Re: Encryption of I-Mail? Someone Invent this Please!
Date: 12 Dec 1999 03:52:59 GMT
To clarify, I am referring to Instant Messenger on AOL when I write I-Mail, not
to e-mail.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Encryption of I-Mail? Someone Invent this Please!
Date: Sat, 11 Dec 1999 23:46:05 GMT
On 12 Dec 1999 03:24:44 GMT, [EMAIL PROTECTED] (UBCHI2) wrote:
>Is there any program out there that will let me encrypt my Imail as I enter it.
Use PGP and use the option to sign the current window.
> If not, some entrepreneur in this Newsgroup should start an internet company
>to do just that and make millions.
Why would anyone bother. The chances of anybody making millions
trying to sell Crypto to AOL users is just about 0. Your average AOL
user doesn't know a Crypto Key from a Locker Key. How can you really
offer security to a group of users who thinks that a one word password
straight out of a dictionary is secure?
And you would need the approval of America On Line if you wanted to
set up something automated enough for most of the users to handle it,
and you are not likely to get it. They have a real hard on for
control of user content and censorship. They censor their news feed,
and recently removed every page they could find that had so much as a
picture of a gun on it claiming it violated their anti-pornography
rules.
Anything making it easy for all users to transfer mail and files
without them being able to determine content is just not going to
happen. Sure you could probably write something, then they just make
a few small changes to the software and after the next automatic
update when you log on you have to start all over again. You are
better off learning how to use a real crypto program.
Best Wishes,
Johnny Bravo
------------------------------
Date: 12 Dec 1999 07:40:29 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
PKI is Public Key Infrastructure. Fundamentally this is any system for
determining the validity of a public key for some intended purpose.
By this definition you have to have some kind of PKI if you are going
to use public key cryptography. You always have to answer the question,
is this key valid for this purpose? Even if your PKI is just a matter of
storing the public keys in a personal database, tagged with the uses for
which they are appropriate, you are still vulnerable to various attacks.
You can never eliminate them.
More commonly when people discuss PKIs they mean a more elaborate system
in which some of the key validity information is stored indirectly, and
calculated as needed. A simple step forward from the previous example
would be to store the keys in an insecure directory, but to certify each
of them with a private key of your own, which you must keep securely.
The next step is to do this indirectly, and to delegate this certification
authority to someone else's key. This has the advantages that a much
larger number of people's keys can be certified, as the certification
authority can specialize in this task. The disadvantage is that you
now must trust this other entity to securely and accurately manage his
certifications. Of course, you entrust your very life every day to the
expectation that third parties have professionally applied their skills
and energies, so there is nothing particularly revolutionary in extending
such trust to a key infrastructure.
As for the comments that the effort to maintain PKI security is as
great as keeping shared secret keys, the difference is that with public
keys you don't have to keep them secret, you need only protect them
from modification. It is true that in today's environment, security
failures are often all-or-nothing; a hacker who gets root privileges on
your system can change public keys as easily as learning symmetric ones.
But in general, modification attacks tend to be more expensive than
access attacks, and PKC gives you much more value than shared secret keys.
------------------------------
** 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
******************************
