Cryptography-Digest Digest #24, Volume #11 Mon, 31 Jan 00 13:13:02 EST
Contents:
Re: How much random needed for random (Shawn Willden)
Re: Should I buy the Dr Dobbs CD? (Shawn Willden)
Re: "Trusted" CA - Oxymoron? (Shawn Willden)
Re: Java's RSA implimentation (Shawn Willden)
Re: Output openssl results to memory buffer (Roger Gammans)
Re: NIST, AES at RSA conference ("Trevor Jackson, III")
Re: How to password protect files on distribution CD (Eric Lee Green)
Re: Help needed on peculiar use of cryptography (Eric Lee Green)
Re: Voynich manuscript (Jim Reeds)
----------------------------------------------------------------------------
Date: Fri, 28 Jan 2000 17:03:00 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: How much random needed for random
Scott Nelson wrote:
> On Sun, 23 Jan 2000 11:59:15 +0200, "Yoni M." <[EMAIL PROTECTED]> wrote:
>
> >I'm using SecureRandom (java) in my SSL implementation to produce the
> >random bytes needed for the challanges. My problem is performance, it
> >takes too long to generate the bytes. If I'm using a simple Random
> >everything is much faster.
>
> If your problem is performance, then you should consider
> a language built for performance, rather than compatibility.
> Java is nice for some things, but this isn't one of them.
Java is plenty fast for such an application.
The reason SecureRandom is slow is not because the SHA-1 implementation is
slow, but because of the mechanism used to seed the PRNG. A technique
based on counting the number of times a thread can yield in a certain
amount of time with some other stuff going on (read the docs -- this is
from memory) is used to generate the seed. Once the seed is generated,
the PRNG itself is very fast.
> >Does anyone knows of a short cut or suggestion how to improve the
> >performance without reducing security ?
> Not in Java.
The language is not really relevant to that question.
> Normally, you can speed initialization by keeping a pool
> of entropy handy which is then hashed for use. That implies
> the ability to write files, which is counter to the Java
> philosophy. (and introduces another whole host of problems.)
> For your app, this would probably need to be a separate program.
<offtopic>Writing files is not at all "counter to the Java philosophy",
and in fact Java has some rather nice tools for handling files. Sheesh, I
didn't realize there was still so much Java FUD circulating. Personally,
I use C++ when possible, but Java is very usable, and with a a
just-in-time compiler performance seems to be somewhere between 0.5 and
0.1 times the performance of C, which is just fine in most applications.
In my environment, when building an application that may have to scale up
to very high performance requirements, Java is the language of choice,
because it makes throwing more hardware at the problem so much
easier.</offtopic>
You could allow the SecureRandom to initialize itself once, and then get
some data from it to write to a file for use in initializing SecureRandom
next time. Of course, this means that the security of your random numbers
is only as good as the security on your randomness pool file (not to
mention the question of whether or not the thread-yield-counting method of
initialization is any good).
If you do have any source of randomness available, it's a good idea to
periodically use the setSeed() method to add randomness to the
SecureRandom internal state. It mixes the new seed data in with the
existing state, meaning it does not reduce entropy. Mixing in the current
time each time the application is started may add a few bits of entropy.
Finally, note that my comments about the internals of SecureRandom (SHA-1)
and the seeding mechanism (the thread-yield-counting thing) only apply to
the Sun implementation of SecureRandom that comes with the JDK. The Java
security framework allows other versions of SecureRandom to be added and
then requested with SecureRandom.getInstance().
Shawn.
------------------------------
Date: Sun, 30 Jan 2000 17:16:44 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Should I buy the Dr Dobbs CD?
David A Molnar wrote:
> Victor Zandy <[EMAIL PROTECTED]> wrote:
> > I found one article in deja.com that says some of the text on the
> > CD is "garbled". What does that mean? Is it still true of more
> > recent pressings of the CD?
>
> The first version of the CD had a horrible proprietary Windows-only
> interface. It also exhibited problems with missing text or links which did
> not work. Actually, "exhibits", since I still have my copy.
Also, garbled text, unreadable images and generally very poor quality in many
of the books (but not all).
> The current version of the CD consists of .pdf files and by all accounts is
> a fine product and worth buying.
I hadn't heard they had a new version... I'm going to have to see if I can get
an upgrade.
Shawn.
------------------------------
Date: Mon, 31 Jan 2000 09:42:54 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: "Trusted" CA - Oxymoron?
Paul Rubin wrote:
> And in some states there are laws (bad idea!) making
> digital signatures equal to paper signatures for contracts, etc.
Could you elaborate on this statement? I'm not aware of
what the laws are
elsewhere, but in Utah there are state-certified CAs who
will certify your
public key (two of them, I think). In order to get it
certified, you have
to appear in person at the CA, present two forms of picture
identification, and sign a statement saying you are who you
say you are
(apparently so legal action can be taken against you if you
aren't --
though I'm not sure what action can be taken).
This seX-Mozilla-Status: 0009 digital signature much
stronger than your
paper signature, and as such it should be perfectly adequate
for
contracts, etc.
Are you saying this is a bad idea because most people won't
keep their
private key secure (violating non-repudiability), or for
some other
reason?
BTW, Just out of curiosity, I'm going to get a legal
certificate. I'll
post later and describe the process.
Shawn.
------------------------------
Date: Mon, 31 Jan 2000 09:43:23 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Java's RSA implimentation
Bill Unruh wrote:
> In <862upd$vr$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>
> >Is anyone aware of any effort to analyse the RSA implementation in Java;
> >specifically focusing on key generation.
>
> ??? Java is a language, much like C in many essentials. It is up to you
> to code what you want it to do.
True and false. In many cases Java provides much of what
you might want to
code in the standard and extended libraries. Java does not
currently provide RSA (the Java Cryptography Extension
provides DH).
> >Does Java use a table of primes? If so, how big is the table?
>
> No, Java does not. But you can enter a table of primes if you wish. And
> you can encode a prime testing routine in Java just as you can in C.
Except that the common way of writing a primality testing
routine in java is:
java.math.BigInteger i = new
java.math.BigInteger(number);
return i.isProbablePrime();
> >Otherwise how good is it's prime number generation routines ie. what is
> >the probability of a generated number not being prime.
>
> I do not know that Java has a "prime number generating routine". but you
> can code one up in Java.
Again, the easy way to write a prime number generating
routine in Java is:
java.security.SecureRandom sr = new
java.security.SecureRandom();
return java.math.BigInteger(numberOfBits, 100, sr);
The original poster's question does actually make some sense
in the context
of a language that provides extensive libraries.
Shawn.
------------------------------
From: [EMAIL PROTECTED] (Roger Gammans)
Subject: Re: Output openssl results to memory buffer
Date: Mon, 31 Jan 2000 17:37:56 GMT
In article <[EMAIL PROTECTED]>, Angus Lee wrote:
>Hi,
>
>I tried to use openssl in my final year project to create certificate.
>The openssl package does not provide enough documentation, however. I
>tried to digged into the source code of the openssl applications. But
>they usually output the results to files. I want the results output to
>the memory buffer. Does anyone know how this can be done?
How about mmap(2).
--
Roger
------------------------------
Date: Mon, 31 Jan 2000 12:50:38 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Bryan Olson wrote:
> John Savard wrote:
> > bryan.olson wrote, in part:
> >
> > >But where is the proof that the adversary will have to
> > >attack it that way? If in fact he has a general solution,
> > >then the argument is irrelevant. Does adding additional
> > >cipher layers seem stronger? Absolutely. Does it help us
> > >prove strength? No, at least it hasn't yet.
> >
> > If the only response to a situation where "we lack proof" is to find
> > some way to get proof, your objection would be fatal.
> >
> > However, if "we can't get proof" is also considered as a reason to,
> > failing some way to obtain proof, try to at least do everything we can
> > to make our ciphers stronger - without proof that we have done enough,
> > without the knowledge whether or not we may have done more than is
> > necessary - then things like Mr. Ritter's multi-ciphering are entirely
> > sensible responses to the situation.
>
> I'll explain my point in terms of the two responses you
> present. I see Ritter's argument as insisting that "we lack
> proof" is fatal to any cipher that an effort such as AES
> might produce, regardless of how the designer of that cipher
> may have applied the "do everything we can" principle in
> your second paragraph. He rejects such ciphers
> categorically, saying we have no results about them. He does
> not consider any analysis of their properties or any
> internal structure they may have; they are simply rejected
> because we cannot disprove that an adversary may break them.
>
> Then for the systems Ritter advocates, I do not see the same
> criteria applied. If we do apply it, then these
> multi-ciphers fail just as surely as single ciphers.
>
> Do we accept a cipher with unproven and unquantifiable
> security? If the answer is "yes with great caution" then
> the idea that we cannot categorically reject single ciphers;
> we have to carefully apply that great caution in the design
> and analysis of that cipher. That is the process the AES
> effort is pursuing.
>
> If the answer is that we cannot accept a system with
> unquantifiable security, and I see the position as
> reasonable though it is not my own, then no system based on
> computational security can pass, no matter how layered or
> dynamic. If all unprovable ciphers must be tripled, then we
> must triple our triples of triples with no end.
I believe there is a way out of this infinite regress. It requires a
particular definition of the phrase "single cipher".
The structure of your argument is reminiscent of set theory in that the
"size" (cardinality) of the set of natural numbers is the same as the size
of the set of even numbers. And 10 times the size of the set of even
numbers is not 5 times the size of the set of natural numbers. Aleph 0
isn't a quantity. Neither is cipher strength.
If "single cipher" means any encryption mechanism E(K, P, C ) then we are
stuck with incomparables. All such ciphers fail the proof-of-security
test. However, a more restrictive definition may support a "cipher
arithmetic" that has some value. Modern block ciphers are not designed to
be arbitrarily strong. The designs are minimalist in the sense that they
are designed to push the cryptanalytic effort just beyond the horizon of
feasibility. They all have some margin of safety whose extent depends upon
the intuition of the designers. Thus we can define a "single cipher" to be
a system whose design objective is to establish a point well past the
current analytic horizon, but not arbitrarily far past it -- past it "just
enough".
None of the existing "single ciphers" are provably secure. There is no
transform that will make them provably secure. Provable security is like
the speed of light. Unless we find some drastic revision to our understand
of the universe we'll never travel faster than light. Unless we find some
breakthrough in cipher theory we won't ever have provable security in a
cipher less cumbersome than an OTP. This makes analysis near the boundary
fruitless.
But we may profitably inspect the other end of the spectrum of cipher
strength. If the analytic horizon mentioned above is real then it may be
the basis for a quantum or unit of security. We have reason to believe that
the analytic horizon is real because that is the basis for the rule that
says one should have much experience breaking ciphers before one attempts to
create one.
Given a single cipher that passes the minimal test for security, i.e., it
lies beyond the current analytic horizon, there is little value in extending
it further past the horizon by increasing round counts, table sizes, etc.,
because the extensions do not eliminate the possibility of a systematic
weakness that may be revealed when a new attack is developed (the horizon
moves because we stand monotonicly higher). Thus an extended version of a
"single cipher" is not measurably stronger. It may in fact be stronger in
that it resists more attacks, but it may not be stronger in that a single
attack may invalidate both the base and extended versions.
However, a stack of several such "single ciphers" may have value in the
reduction of the possibility of a systematic weakness that will be found
that affects the entire stack. The concept is to work with entities that
have some measurable amount of strength: they are considered secure today.
A stack composed of such strength quanta is not any more provably secure
than any component cipher is. I.e., not at all. But if we assume that the
ciphers are "sufficiently distinct", then we can reasonably expect that no
_one_ weakness will affect the entire collection.
I have no metric for "sufficiently distinct" so it may be that this
proposal simply hides the difficulty of cipher strength arithmetic in
another guise.
In any case, if we are able to define a quantum or unit of security then
piling up such entities will have provable merit. Not provable perfect
security, but provable increase in strength.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Mon, 31 Jan 2000 10:51:37 -0700
> We have developed some software and we want to ship them on CD
> in encrypted form to our customers. Then we want to give them some keys
> to decrypt the software. We should be able to generate the passwords
> for our customers. We might want to put further restrictions on
> encryption and authorization in the future but not now.
As others have pointed out, the problem is that CD media is immutable -- it
cannot be "personalized" to have a different key for each customer. Thus
you'll only have one single key. Once that key is posted to a public "hacker"
web site, you're fried. And the key WILL be posted.
What many people do to produce a "license key" is to apply MD5 or some other
message digest algorithm to the user's name, contact info, serial number, and
feature set code (# of users licensed or whatever), then encrypt the digest
with an RSA private key. This encrypted digest is then converted into
printable ASCII characters. The software itself does the same calculation, but
uses the RSA public key (embedded in the software) to decrypt the digest in
order to make sure that the digest calculated matches the authorized feature
set that was sent as the "license key". This uses the authentication property
of RSA encryption.
The problem is that this can be easily "cracked" by crackers in order to strip
out the license key checking code. Thus don't think this is uncrackable. All
you're doing is locking your screen door so that people can't just wander in
and steal things from you. Anybody who really wants to steal your stuff can
just pull out a big knife (object code debugger), cut your screen out of its
frame (disassemble your code, put a patch around the license key check part),
and walk in and steal you blind. Count on this scheme to keep honest people
honest, not to be a fail-safe anti-theft device.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Help needed on peculiar use of cryptography
Date: Mon, 31 Jan 2000 10:58:37 -0700
David P Jablon wrote:
> In article <[EMAIL PROTECTED]>,
> John Savard <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] (Sgwbutcher) wrote, in part:
> >>a social security number can be encrypted
> >>so that the informational value of the cyphertext can be retained but the
> >>plaintext cannot be recovered?
> >
> >It is not clear what this wording means. However, a one-way hash
> >function can allow a social security number to be encrypted so that,
> >althought the social security number itself cannot be recovered, its
> >hash is still usable as an identifier by which records can be matched.
>
> John, don't fool yourself. Given the small space of SS #s, a
> brute-force search will reveal which # matches the hash very quickly.
> The attacker's job is equivalent to cracking a 20-bit key.
This attack can be foiled by including a "secret" as part of the hash. The
attacker then needs to not only check the SS# space, but also must check the
entire keyspace of the "secret". I say "secret" because this is really a
"salt" value, but one which is hopefully not stored on disk anywhere that an
attacker could find it (i.e., the user is required to type in a passphrase in
order to access the application).
Most secure network protocols use a similar method to authenticate data being
transmitted over the network -- i.e., they include a message digest hash which
has had a secret hashed into it, so that the receiving end knows whether the
packet is authenticated or not. (You could use RSA to do this, but it's much
faster to use RSA to handshake the secret across at the start of the
connection, rather than run those bignum calculations for every packet).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Jim Reeds)
Subject: Re: Voynich manuscript
Date: Mon, 31 Jan 2000 17:59:12 GMT
In article <[EMAIL PROTECTED]>, JCA <[EMAIL PROTECTED]> writes:
|>
|> I have not heard any news about this for quite some time. Anybody
|> know if
|> there has been any progress within the last few years? Or, more to the
|> point,
|> is anybody actually looking into this, or has it been brushed aside as a
|> medieval
|> practical joke?
There is a sometimes active, sometimes quiet mailing list;
drop a line to Jim Gillogly = [EMAIL PROTECTED] if you want
to be added. There are various web sites on the subject,
reporting recent work & theories. These include
http://web.bham.ac.uk/G.Landini/evmt/evmt.htm
http://www.dcc.unicamp.br/~stolfi/voynich/
http://www.geocities.com/Athens/Delphi/8956/
and
http://www.research.att.com/~reeds/voynich.html
This last one has archived Voynich mailing list traffic
in http://www.research.att.com/~reeds/voynich/vmail.html
--
Jim Reeds, AT&T Labs - Research
Shannon Laboratory, Room C229, Building 103
180 Park Avenue, Florham Park, NJ 07932-0971, USA
[EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360 8178
------------------------------
** 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
******************************
