Cryptography-Digest Digest #44, Volume #9 Sat, 6 Feb 99 14:13:04 EST
Contents:
College student needs input on secure instant messaging ("Corbett J. Klempay")
Re: Crypto mailing lists (Ian Geldard)
Re: I hate to bring up PRNGs again... (R. Knauer)
Re: Metaphysics Of Randomness (R. Knauer)
FS:Apps for PC/SGI ([EMAIL PROTECTED])
Re: Rational points on a curve ("Vonnegut")
Re: Metaphysics Of Randomness (R. Knauer)
Re: Who will win in AES contest ?? (DJohn37050)
Re: Spread Spectrum (Patrik Norqvist)
Re: Rational points on a curve (Scott Fluhrer)
Re: MS ActiveX Licensing Scheme (A. Bettik)
Re: Java random (fungus)
Re: Metaphysics Of Randomness (R. Knauer)
Re: Java random ("Else")
Re: Java random (Paul Rubin)
Re: Java random ("Else")
----------------------------------------------------------------------------
From: "Corbett J. Klempay" <[EMAIL PROTECTED]>
Subject: College student needs input on secure instant messaging
Date: Fri, 05 Feb 1999 22:44:25 -0500
Hey all...I'm a sci.crypt newbie. I thought I'd post in here to see if
I can get some constructive ideas. Here's the deal: there is an instant
messaging system in development called Jabber (www.jabber.org)...they
already have lots of the core code and some limited functionality in
place. It's similar to ICQ, but with a much more flexible design, and
has the ability to take plug-in transports, such that a Jabber client
can interoperate with other instant messaging systems (ICQ, AIM, etc.).
I have a cryptography class here at school this semester, and a large
(i.e. 40% of our grade) project is part of the class. I haven't
committed to doing it yet (that will probably be within 2 weeks), but I
have talked with the professor about adding digital signatures and/or
encryption to the Jabber system. This is one feature that I think is
sorely missed in existing IM systems, and I think that some people
(myself included) would find such a feature a compelling enough reason
to switch to the new system. What I need to start thinking of is the
design and implementation of this, such as:
- In Jabber, there very little (if any? need to verify)
client-to-client communication...it all passes through a server as an
intermediary. I need to think of how to (within this framework) deal
with key distribution, as well as minimize any CPU load on the servers
(I can't have them doing computationally expensive processes with every
client all the time if there will be lots of clients).
- I need to look into the most suitable (from a cryptographic strength,
as well as far as patenting issues) cryptosystem designs to apply to
this problem.
- I need to become more familiar with these lame export laws...I need
to know so I know what I can freely distribute in this context and what
I have to do differently, etc etc...
Any and all input would be _greatly_ appreciated. At this point, I'm
still just looking at doing this work and haven't committed to it, but I
hope that it doable and hope to get some useful comments. Thanks!
---
Corbett J. Klempay | cklempay at acm.jhu.edu
http://www2.acm.jhu.edu/~cklempay
------------------------------
From: [EMAIL PROTECTED] (Ian Geldard)
Subject: Re: Crypto mailing lists
Date: Fri, 05 Feb 1999 20:57:02 GMT
In article <[EMAIL PROTECTED]>, on Fri, 05 Feb
1999 13:33:06 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Of the non-US lists there is the ukcrypto, as far as I know. There
>are certainly others, probably not all in English.
Contact details?
--
Ian Geldard
London, England
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: I hate to bring up PRNGs again...
Date: Sat, 06 Feb 1999 13:04:46 GMT
Reply-To: [EMAIL PROTECTED]
On 5 Feb 1999 12:55:20 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>>I challenge that statement on the grounds that crypto-grade security
>>must have at least one intinsically random source in those steps.
>Nope. Most of the security in most systems is based on key choice,
>which you can do in any manner you like.
Then the key is the source of randomness.
>You're using an extremely unusual and personal definition of
>"crypto-grade security" if you think that 3DES doesn't provide
>such.
That's not my term - I adopted it from others here on sci.crypt. And
it is not unusual at all. It means that the cipher can sustain a
cryptanalytic attack.
Bob Knauer
"Sometimes it is said that man cannot be trusted with the government
of himself. Can he, then, be trusted with the government of others?"
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Sat, 06 Feb 1999 13:19:45 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 05 Feb 1999 15:35:58 -0700, "Tony T. Warnock"
<[EMAIL PROTECTED]> wrote:
>> Maybe you need to tell Greg Chaitin something he doesn't know.
>No, I'm telling you something you don't know.
So what you are saying is that Chaitin is wrong when he claims that
Champernowne's number is not normal except in base 10.
I guess I need to be more discriminating.
Bob Knauer
"Sometimes it is said that man cannot be trusted with the government
of himself. Can he, then, be trusted with the government of others?"
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: Fri, 5 Feb 1999 02:27:19
Subject: FS:Apps for PC/SGI
Hi,
We have for sale some gfx apps for the PC and SGI.
All softwares with removed a protection.
For SGI:
Maya 1.5 (include Power Animator 8) - $3.000
SoftImage 3.7 SP1 (include Eddie 4) - $2.000
For PC:
Maya 1.0 (include Artisan,FX) - $500
SoftImage 3.8 Extreme - $500
SoftImage Twister - $500
LightWave 5.6 - $200
3D Studio Max 2.5 - $400
Houdini 2.5 - $300
AutoCad r14 - $500
ArchiCAD 6.0 - $500
and much more.
If you need full list,let us know...
Thank you !
------------------------------
From: "Vonnegut" <[EMAIL PROTECTED]>
Subject: Re: Rational points on a curve
Date: Sat, 6 Feb 1999 10:10:42 -0500
>An obvious example of a curve which will not have any integral points is
>
> y^2 = -x^2 + 1/2
>
>which is a circle with radius 1/2.
No, radius 1/sqrt(2),
y^2 = -x^2 + 1/4 has radius 1/2.
_________________
-Vonnegut
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Sat, 06 Feb 1999 13:47:31 GMT
Reply-To: [EMAIL PROTECTED]
On 5 Feb 1999 09:11:19 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>Well, a simple example, then. Perhaps oversimplified -- but what
>do you expect for free in a seventy-line posting.
The truth, perhaps? Or is that asking too much? What makes you think
that the truth costs money to obtain?
>Define a level of "unacceptable" bias
What makes you think that tests for bias are conclusive? What if a
PRNG passes such tests, and yet is not secure at all?
>Implicit in this is are (mathematically) two probabilities, that
>the statistician you hired can probabily give you the formulae
>for.
"Probably" give you the formulas? If he can't give the you the
formulas, then he is a Snake Oil salesman - not a statitician.
>1 -- the probability that a good generator would fail this
>2 -- the probability that a biased generator with bias right as
> the threshhold would pass.
You have reduced the whole question of using statistical tests down to
testing for bias. I find that inadequate.
>Call these probabilities x and y, respectively. If you can live
>with those numbers, you're done. If you use a fairly large sample,
>they're easily going to be in the close order of 5%. A *really*
>large sample will give you reliablity into the area of 0.1%
I fail to see how using a large sample is going to demonstrate that an
unsecure PRNG is secure just because it passes some statistical tests.
>If they don't agree, run more tests, and consult with your stastistician.
And when a cryptanalyst finally breaks your unsecure ciphers, drink
some more snake oil.
There can be no algorithmic tests, not even statistical tests, that
can cover all possible ways in which a number generator can be
unsecure, even within specified limits of confidence. Statistical
tests measure properties that are based on infinite numbers, e.g.,
there can be no bias in an infinite number. But just because your
generator behaves in a statistically correct manner in terms of bias
does not mean that it is crytographically secure.
Over and over in the literature the statement can be found that you
cannot show that a number is random using algorithmic tests like
statistics. Just because it is not non-random does not mean it is
random. Failing algorithmic tests for non-randomness is not sufficient
for demonstrating randomness.
The only way I can imagine to show that a number is random is to use
it to encrypt a message and then try to break the cipher
experimentally using known attacks. If you cannot break the cipher
then at least you have some empirical evidence that the number might
be crypto-grade random.
Statistical tests do not give empirical results regarding security.
The Nazis convinced themselves that Enigma was statistically secure,
yet their ciphers were routinely broken.
Bob Knauer
"Sometimes it is said that man cannot be trusted with the government
of himself. Can he, then, be trusted with the government of others?"
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Who will win in AES contest ??
Date: 3 Feb 1999 14:35:07 GMT
P.S. I hear there are over 25 papers submitted to 2nd AES conference. Pretty
respectable.
Don Johnson
------------------------------
From: Patrik Norqvist <[EMAIL PROTECTED]>
Subject: Re: Spread Spectrum
Date: Sat, 06 Feb 1999 17:01:04 +0100
[EMAIL PROTECTED] wrote:
>
> On Thu, 28 Jan 1999 15:31:24 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
[cut]
> >About Spread Spectrum, it's a big subject...good luck.
>
> Yeah, and it appears that no one is able to provide the answers to the
> question about intercepting and converting DS back into speech...
Could this bibliography be useful to you?
http://www.sp.nps.navy.mil:80/ss/biblio.html
Regards
/NOR
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Rational points on a curve
Date: Sat, 06 Feb 1999 17:32:52 GMT
In article <79hkpc$vp4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>In article <79ga19$fgg$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Jayant Shukla) wrote:
>> Sammy <[EMAIL PROTECTED]> writes:
>>
>> >Jayant Shukla wrote:
>> >>
>> >> Hi,
>> >> Is there an easy way to find integer points on
>> >> the curve y^2 = a x^2 + b x + c? i.e. both x and y
>> >> are integers. The constants a, b, and c are integers
>> >> as well.
>
>> I am really interested in the curve that I mentioned
>> and for the case when the constants a, b, and c are
>> all non zero integers. The solutions x any y are also
>> integers.
>>
>> The elliptic curve that you have mentioned, I found
>> methods for finding rational points on that curve.
>> But I see no easy way to extend those method to
>> quadratic curves (a x^2 + b x + c).
>>
>> In one book that I have, there is a mention of a
>> method by Hasse to solve this problem, but no references
>> were given.
>
>Your equation may not have ANY integer solutions. But if it has 1, it
>has infinitely many.
Not necessarily. Counterexample:
y^2 = -1*x^2 + 4*x + 3
has precisely 4 integer solutions: (2,1), (2,-1), (1,0), (3,0)
--
poncho
------------------------------
From: A. Bettik <[EMAIL PROTECTED]>
Subject: Re: MS ActiveX Licensing Scheme
Date: Sat, 06 Feb 1999 16:50:50 GMT
That's right. The MS licensing system for key files is extremely simple since
the component must store the license key within itself in unicode - so it's
very easy to find this out - a warning to component developers!
Their registry licensing scheme is a bit more complex, and it's this I'd like
to know about.
By default licensing info is stored in the user's registry under
HK_CR\Licenses\. A unique registry key is created for each control, the
default string data containing the control's actual registration key. This
is, however, encrypted as a string of 36 lower case characters. The MS key
file system uses a copyright notice (usually Copyright (c) 199x
SomeCompanyName) as the default registration key, and presumably this will be
the same in the registry system. But what encryption method is used? There
seems to be a relationship between the registry key and the encrypted data
e.g.
12B142A4-BD51-11d1-8C08-0000F8754DA1
aadhgafabafajhchnbchehfambfbbachmfmb
096EFC40-6ABF-11cf-850C-08002B30345D
knsgigmnmngnmnigthmgpninrmumhgkgrlrk
XORing of Hexed ASCII values? How to generate these values from the plaintext
(and back) is what I'd really like to know!
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Stephen Darlington) wrote:
> On Mon, 01 Feb 1999 00:05:53 GMT, A. Bettik <[EMAIL PROTECTED]>
> wrote:
>
> >I'm interested in finding out how MS implements its activex registry
> >licensing scheme and wonder if anyone knows more? From what I can gather, two
> >complimentary techniques are available - a file key and a registry key. I
> >understand how the file key system works, but the registry I can't figure
> >out. From what I can see a registry key is created along with string data,
> >apparently encrypted somehow. Is this a known cipher and what does MS use as
> >the key? Anyone offer any pointers?
> >
> >-----------== Posted via Deja News, The Discussion Network ==----------
> >http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>
> My understanding is that ActiveX controls can be used at design time
> and at runtime. At design time the control checks for certain
> information (whether in the registry or in a file), if the information
> is there and correct, it is properly licensed. If the information isnt
> there (or is corrupted), then the control will not allow itself to be
> used for development. At runtime the control still checks the
> information, but now it is actually stored inside the executable.
>
> Stephen Darlington
> Author of
> the addZIP Compression Libraries and
> the addCRYPT Encryption and Hash Components
> http:\\welcome.to\addZIP
>
>
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Java random
Date: Sat, 06 Feb 1999 10:20:20 +0100
Paul Rubin wrote:
>
> In article <[EMAIL PROTECTED]>,
> fungus <[EMAIL PROTECTED]> wrote:
> >> >The java random number generator is 48 bits internally. No matter how
> >> >good your seed is, you're only selecting one of 2^48 possible keys.
> >>
> >> Actually, it's 64 bits in Java.
> >>
> >Is it? Let's have a look at the source code:
> >
> You're looking at the Random class. You need to look at the
> SecureRandom class, which is supposed to be better.
The original poster said he was "using Random". I assume he meant
java.util.Random. I'm not sure what SecureRandom does, it doesn't
seem to be in the JDK as standard (export resrrictions?)
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Sat, 06 Feb 1999 18:30:32 GMT
Reply-To: [EMAIL PROTECTED]
On 5 Feb 1999 09:11:19 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>>Perfectly secure generators can produce numbers which do not pass bias
>>tests,
>But, in general, they don't -- this probability can be reduced
>as far as you like.
I maintain that statistical tests, including those for bias, are not
suitable for determining crypto-grade randomness, even to a specified
level of confidence.
Consider the following proveably secure cipher. Let the OTP key be the
same as the message. The resulting cipher is composed of all 0s, which
is an extremely biased number. Yet that cipher is crypto-grade random
because it is completely indeterminant - i.e., it leaks no
information.
If so, then I challenge you to decipher the following random number:
000000000000000000000000000000000000000000000000000000
[Don't try too hard. :-)]
I realize that this is a stupid protocol, since you have to send your
correspondent the key each time. Furthermore, since the key is
identical to the message, why bother to send him the cipher (except to
befuddle your attacker. :-) But that is not a valid criticism of my
point above, since I do not have to justify the practical use of this
cryptosystem.
To make your point regarding the adequacy of ststistical tests, you
have to show that bias in random numbers will result in some analytic
weakness in the cipher. And if that is the case, then how do you
rationalize the use of TRNG numbers for keys, since some of them are
biased? Should you not filter those out so they won't weaken the OTP
ciphers?
Remember that it was you who argued that one should not even filter
out a sequence such as 000...0. Therefore, if filtering out one of the
most biased sequences is not permitted, why would filtering out any
biased sequences be permitted? And if filtering out any biased
sequences is not permitted, then how can bias have any effect on the
crypto-grade randomness of finite numbers generated by a TRNG?
I suspect you are now going to present an argument using the binomial
theorem and the law of large numbers, alluding to the combinatorial
properties expected from an analysis of infinite random numbers. I
suspect you are going to say that in order for all of the possible
numbers generated by a TRNG to be equiprobable, the distribution of
actual finite numbers generated must obey the binomial theorem in the
limit of large numbers. And then I am going to ask you to prove that,
giving appropriate measures to the probabilities along the way.
There is something very deceptive going on here with the claim that
statistical tests can be used to determine the quality of randomness
of a TRNG from its output, because we know the same tests can be faked
out with suitably chosen PRNGs.
It is the same kind of deception we run into all the time with
political opinion polls. For example, how many times have you heard
that Clinton is still the most popular man in America? [Too many times
to suit me.] Yet that poll is true.
What the polsters did not tell you, however, was that his actual
popularity is only 15%, which happens to be the highest among the many
other people less popular than he is.
The same kind of deception is going on with the use of statistical
tests to certify randomness.
Bob Knauer
"To compel a man to furnish contributions of money for the propagation
of opinions which he disbelieves is sinful and tyrannical."
--Thomas Jefferson
------------------------------
From: "Else" <[EMAIL PROTECTED]>
Subject: Re: Java random
Date: Sat, 6 Feb 1999 21:58:17 +0300
fungus wrote in message <[EMAIL PROTECTED]>...
>Paul Rubin wrote:
>>
>> In article <[EMAIL PROTECTED]>,
>> fungus <[EMAIL PROTECTED]> wrote:
>> >> >The java random number generator is 48 bits internally. No matter how
>> >> >good your seed is, you're only selecting one of 2^48 possible keys.
>> >>
>> >> Actually, it's 64 bits in Java.
>> >>
>> >Is it? Let's have a look at the source code:
>> >
>> You're looking at the Random class. You need to look at the
>> SecureRandom class, which is supposed to be better.
>
>The original poster said he was "using Random". I assume he meant
>java.util.Random. I'm not sure what SecureRandom does, it doesn't
>seem to be in the JDK as standard (export resrrictions?)
I meant java.util.Random.
By the way - thanks. I got the answer I was looking for and already changed
the algorithm used in the product.
SecureRandom *is* part of the JDK. It uses SHA. I believe SHA is not export
controlled (am I correct on this?). FYI - SecureRandom is very slow. Its
seeding takes over 1 second.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Java random
Date: Sat, 6 Feb 1999 18:59:48 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
>> You're looking at the Random class. You need to look at the
>> SecureRandom class, which is supposed to be better.
>
>The original poster said he was "using Random". I assume he meant
>java.util.Random. I'm not sure what SecureRandom does, it doesn't
>seem to be in the JDK as standard (export resrrictions?)
Yes, you're right, I lost track of the thread.
SecureRandom is included in JDK 1.1. As mentioned, the constructor
is pretty slow.
I don't know what can really be done. The problem is one of gathering
enough entropy from what's supposed to be a deterministic computer.
Crypto algorithms are mostly irrelevant to this.
If you have a way to load native functions with the JNI, your best
bet is to add some system specific code that gets closer to the hardware.
Then use something like Yarrow (www.counterpane.com). You can't do
that in portable Java, though.
------------------------------
From: "Else" <[EMAIL PROTECTED]>
Subject: Re: Java random
Date: Sat, 6 Feb 1999 22:17:19 +0300
>In article <[EMAIL PROTECTED]>,
>fungus <[EMAIL PROTECTED]> wrote:
>I don't know what can really be done. The problem is one of gathering
>enough entropy from what's supposed to be a deterministic computer.
>Crypto algorithms are mostly irrelevant to this.
>
>If you have a way to load native functions with the JNI, your best
>bet is to add some system specific code that gets closer to the hardware.
>Then use something like Yarrow (www.counterpane.com). You can't do
>that in portable Java, though.
Unfortunately, I cant go native. It's a part of a web client (Forex trading
terminal) which is given to clients for free on the web.
I made an implementation similar to SecureRandom. I setup a counter which
just goes
count++;
while another thread sleeps for 10 ms. 10 ms is enough for the counter to go
to a few thousand on an average Pentium. I think it's enough entropy for one
byte. The whole 16 bytes takes just 160 ms, which is way faster than
SecureRandom. I think it should be enough for this application.
------------------------------
** 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
******************************
