Cryptography-Digest Digest #893, Volume #9 Fri, 16 Jul 99 20:13:02 EDT
Contents:
Re: Properly Seeding RNGs (Doug Stell)
Re: Password generation question (Patrick Juola)
Re: What is the "real" length of a key in 3-key 3DES? (wtshaw)
Re: Properly Seeding RNGs ([EMAIL PROTECTED])
Re: Properly Seeding RNGs ([EMAIL PROTECTED])
Re: Why public key in PGP ([EMAIL PROTECTED])
Re: Why public key in PGP ([EMAIL PROTECTED])
obliterating written passwords ([EMAIL PROTECTED])
Re: randomness of powerball, was something about one time pads (Jerry Coffin)
SkipJack source??? ([EMAIL PROTECTED])
Re: Password generation question (David A Molnar)
Re: Why public key in PGP ([EMAIL PROTECTED])
Re: obliterating written passwords ([EMAIL PROTECTED])
Re: SkipJack source??? (David A Molnar)
Re: SSL and FTP over SSL -- Need resources. (Eric Young)
Re: Molecular-Computing and DES (David A Molnar)
Re: Molecular-Computing and DES (James Pate Williams, Jr.)
Re: Password generation question (David A Molnar)
Re: Password generation question ([EMAIL PROTECTED])
check out wincrypt ("Terry Mechan")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Properly Seeding RNGs
Date: Fri, 16 Jul 1999 20:44:49 GMT
On Fri, 16 Jul 1999 14:37:55 -0400, [EMAIL PROTECTED] wrote:
>Let's just say I am using a strong cryptographic RNG. This particular
>one requires a string of variable length to seed it. How in the world
>do I get a random string to seed it with?
Consider the platform on which this thing runs. Identify and exploit
any source of entropy available to you. Sources I've seen in the past
include the following.
Human-entered characters
Timing of human-initiated actions
Random timing of disk seeks, due to air in the hard drive
Mass storage topology, including bytes used & bytes free
Another, external random number generator
Process/task information (better on multi-user systems)
Remember also that you can "stir in" entropy over time to make the
seed grow stronger than the initial seed. RSADSI's BSAFE library has a
mechanism to stir in entropy. Entropy can be obtained from plaintext
and timing of events that are not available to adversaries in the
external envionment.
>At the current time, I'm using the current time to srand(); and then
>rand() % 256 to fill a string of [1024] long. This does NOT seem very
>secure to me. What is a practical way to seed this RNG?
You're right. This is not very secure.
You might try to find some of the discussion of 4-5 years ago, when
SSL suffered from a bad random number generator. Netscape asked the
entire community for suggestions and there were a lot of good ideas
floated at that time.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Password generation question
Date: 16 Jul 1999 16:38:47 -0400
In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]> wrote:
>> Large Assumption: /dev/random gets its bits from periodic keyboard
>> hits, mouse movements, etc, and not some stupid deterministic
>> pseudo random number generator. I read that on the alt.linux.advocacy
>> group once, so it must be true.
>
>a taught on this quote:
> A pseudo Random genrator (PRG) needs a seed, this seed needs to be random
>for the result of the function to be pseudo-random.
>
>/dev/random produces a lot of bits (supposevly random) and then hashes it to
>get
>compact random bits.
>
>In _both_ cases, we depend on a function.
> -With the PRFG, we depend on the PRG function,.
> -With /dev/random, we depend on the fact that the hash function has strong
>
> collision resistance.
>
>What makes one better then the other one?
>
>For the pass word , I'd just take the amount of bits you want directly form
>/dev/random
>and not rehash it again afterwards...
You don't really need *strong* collision resistance -- mere collision
resistance will work (given the context). The problem with just taking
the bits that you need direct from /dev/random is that they're likely
to be correlated, biased, &c. -- I'd feel more confident if I smoothed
them out myself. I think the secure hash is a great way to smooth them.
-kitten
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What is the "real" length of a key in 3-key 3DES?
Date: Fri, 16 Jul 1999 15:52:14 -0600
In article <[EMAIL PROTECTED]>, Nicol So
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> >
> > And, in practical use, getting a few if any chosen plaintexts is not
> > practical.
>
> That depends on the application. In some applications, the adversary
> can obtain a large amount of adaptively chosen plaintext-ciphertext
> pairs. People who work on these applications are aware of the
> possibility and they defend against the threat it poses in their designs
> one way or another.
>
If you can get lots of pairs, then you are probably overworking a specific
key. That is surely one of the problems with a small keyspace. It all
depends on traffic, small time users do not have the same ones as those
you remind us of.
--
Most wrestlers and politicians seem to have pretty the same
agenda, seek various kinds of by appearing to do things they are
not doing, catering to specialty groups of supporters, and as a
result of deals, learn to take falls when they know better. Those
who do not go along tend to be excluded and punished.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Properly Seeding RNGs
Date: Fri, 16 Jul 1999 17:15:08 -0400
>
> What PRNG are you using anyways?
>
I guess it would make some since to put that eh? RandPool (I believe that
is what PGP uses if I am not mistaken).
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Properly Seeding RNGs
Date: Fri, 16 Jul 1999 17:22:42 -0400
This is being used to encrypt files. However, the user's password is never
anything outside of to characters on the keyboard. So I should strip only a
few bits from each character? That would not be a lot of random bits....
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why public key in PGP
Date: Fri, 16 Jul 1999 21:20:14 GMT
[EMAIL PROTECTED] wrote:
> David A Molnar <[EMAIL PROTECTED]> wrote:
> > Well, you can get "perfect forward secrecy" by making new keys for
> each
> > conversation. "perfect forward secrecy" refers to a situation in
which
> > compromising the private key I hold _now_ doesn't allow you to
access
> > any _previous_ conversations. So if I have a key I use solely for
> > authentication, and exchange new DH keys for each conversation, then
> it
> > does make some sense to make new keys for each conversation.
> >
>
> But why don't you just use an intractable PRNG and make random session
> keys? If you both share the same PRNG state then no need for RSA!
Because it doesn't provide the advantages that David
Molnar was discussing. Authenticated key exchange
can provide perfect forward secrecy given that each
side starts with the others authenticated public key.
You have not clearly described what you mean with this
intractable PRNG system, but it clearly either doesn't
provide perfect forward secrecy or relies on stronger
initial assumptions.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why public key in PGP
Date: Fri, 16 Jul 1999 21:05:58 GMT
Patrick Juola wrote:
> The idea, though, is that if you use a different session key for each
> session, and only use the 'main' public key for key exchange, then
> it may not be worth the effort to attempt to recover the session
> keys.
More to the point, we only need depend on the main
public key to authenticate the key-exchange. The
key-exchange itself uses something like D-H. Exposure
of the main key doesn't compromise previous sessions.
If we also delete the session keys after the session,
we have perfect forward secrecy.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: obliterating written passwords
Date: Fri, 16 Jul 1999 22:15:52 GMT
I occasionally jot down a password, or social security number
or such, consisting of a handful of numbers and letters. I
later attempt to obliterate it by writing random numbers and
letters over all the original numbers and letters, several times.
Suppose you are given that piece of paper and told to find the
original password. How easy is it? What attacks are available?
More to the point, what can I do to obliterate it better? I'm
not expecting NSA to attack it, just other devious citizens.
- Bob Jenkins
http://burtleburtle.net
PS Originally I just scribbled over the password, but I found
that the imprint of letters is easily distinguishable from
any amount of random scribbling.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: randomness of powerball, was something about one time pads
Date: Fri, 16 Jul 1999 11:15:27 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > Not really very long: With three dice, you've got a total of 18
> > possible outcomes. ...
>
> But they are not equally probable outcomes.
>
> I guess we have ample demonstration in this thread that people
> really do have trouble with probability questions.
Quite true.
> I suppose when in doubt, one should run a careful simulation.
An excellent idea. This particular simulation may not qualify as
particularly careful, as it uses the random number generator in your
compiler's standard library, which may be of relatively poor quality.
Feel free to try it with different generators though -- I'd be VERY
interested in doing some statistical analysis of any generator that
comes out with the player winning or coming out nearly even on a
regular basis.
#include <stdlib.h>
#include <stdio.h>
#define num_dice 3
#define num_games 100
int roll() {
/* return a random number between 1 and 6 inclusive.
**/
int limit = 5;
static inited;
int divisor = RAND_MAX / (limit + 1);
int retval;
if ( !inited) {
srand(time(NULL));
inited=1;
}
/* The loop is to eliminate possible biases in the outcome.
*/
do {
retval = rand() / divisor;
} while (retval > limit);
return retval + 1;
}
int main(int argc, char **argv) {
int dice[num_dice];
int i;
int game;
int money = 0;
int verbose;
printf("At start, pot is: %d\n", money);
verbose = argc > 1;
for (game=0; game<num_games; game++) {
/* pick a number
*/
int pick = roll(6);
/* pay to play the game
*/
money --;
/* roll the dice
*/
for (i=0; i<num_dice; i++)
dice[i] = roll(6);
/* check for matches
*/
for (i=0; i<num_dice; i++)
if ( dice[i] == pick)
money++;
/* if the user wanted it, tell them how this game went
*/
if (verbose)
printf("Current pot is: %d. Player picked: %d."
" Rolls were %d, %d, %d\n",
money, pick, dice[0], dice[1], dice[2]);
}
/* Show much much the player made. If this is a negative number,
* the player lost money...
*/
printf("After %d games, pot is: %d\n", num_games, money);
return 0;
}
------------------------------
From: [EMAIL PROTECTED]
Subject: SkipJack source???
Date: Fri, 16 Jul 1999 18:56:08 -0400
I thought that SkipJack was supposed to be a complete and total
secret...and yet here it is:
ftp://ftp.funet.fi/pub/crypt/cryptography/symmetric/skipjack/
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Password generation question
Date: 16 Jul 1999 22:35:35 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote:
>> Large Assumption: /dev/random gets its bits from periodic keyboard
>> hits, mouse movements, etc, and not some stupid deterministic
>> pseudo random number generator. I read that on the alt.linux.advocacy
>> group once, so it must be true.
> a taught on this quote:
> A pseudo Random genrator (PRG) needs a seed, this seed needs to be random
> for the result of the function to be pseudo-random.
> /dev/random produces a lot of bits (supposevly random) and then hashes it to
> get
> compact random bits.
> In _both_ cases, we depend on a function.
> -With the PRFG, we depend on the PRG function,.
> -With /dev/random, we depend on the fact that the hash function has strong
> collision resistance.
> What makes one better then the other one?
I'd say it depends on how much you know about the PRG and how much
you know about the hash. Do you know how to make a hash function which
is collision resistant subject to some standard assumption? Use that.
Do you know a PRG which is provably pseudo-random subject to
some standard assumption and restrictions on the parameters (e.g.
Blum-Blum-Shub) ? OK, plug that in.
If you happen to know how to do both, then look at what your proofs say
and see which is more efficient with your stream of bits. For example,
a BBS generator needs care when choosing the p and q and the initial
state. You can probably figure out if this is more hassle than the
alternatives.
> For the pass word , I'd just take the amount of bits you want directly form
> /dev/random
> and not rehash it again afterwards...
I thought /dev/random already applied SHA-1 to its pool of bits, but
that impression is based on what the "entropy gathering daemon" used for
GnuPG does. Is there a coderpunks archive currently online? I think a
discussion on how /dev/random hashes its randomness came up a few months
ago; it may be worth referring to.
-David
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why public key in PGP
Date: Fri, 16 Jul 1999 23:00:19 GMT
In article <7mo7m2$rfa$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Because it doesn't provide the advantages that David
> Molnar was discussing. Authenticated key exchange
> can provide perfect forward secrecy given that each
> side starts with the others authenticated public key.
>
> You have not clearly described what you mean with this
> intractable PRNG system, but it clearly either doesn't
> provide perfect forward secrecy or relies on stronger
> initial assumptions.
>
Possibly so. What I mean is both start by seeding a PRNG. The PRNG
has to have outputs which do not reveal the state any faster then brute
force of the state. Then each session just uses another random key.
This way no session is encoded with the same key and you get
independance in any direction.
I think for this specific situation a PKC maybe more work then is
required.
Another Idea (just brainstorming) is to start off with one fixed key
then when the session ends you encrypt a counter (which would be in CBC
so it depends on the last packet). This ciphertext would make the next
key. The other party would be forced to process the entire message and
if part of the message was changed the keys will not be the same (well
probably not) for the next session.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: obliterating written passwords
Date: Fri, 16 Jul 1999 23:12:34 GMT
In article <7moauf$sln$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I occasionally jot down a password, or social security number
> or such, consisting of a handful of numbers and letters. I
> later attempt to obliterate it by writing random numbers and
> letters over all the original numbers and letters, several times.
>
> Suppose you are given that piece of paper and told to find the
> original password. How easy is it? What attacks are available?
> More to the point, what can I do to obliterate it better? I'm
> not expecting NSA to attack it, just other devious citizens.
Well some investigative centers can recover this. On a A&E special
documenting plane accidents they used these techniques to find 'repair
slips' which were forged (by writing over them). They could recover
writing from papers which were scribbled over in different colors, even
thru white out and such.
It's not hard to get access to this as well. You have to know who to
talk to.
> PS Originally I just scribbled over the password, but I found
> that the imprint of letters is easily distinguishable from
> any amount of random scribbling.
Well yes just look at the back of the paper. What I would do is either
keep it on your person or destroy the paper (i.e lighter).
Normally if you rip a piece of paper into enough parts it will be too
hard to put together (not impossible though).
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: SkipJack source???
Date: 16 Jul 1999 23:18:41 GMT
[EMAIL PROTECTED] wrote:
> I thought that SkipJack was supposed to be a complete and total
> secret...and yet here it is:
> ftp://ftp.funet.fi/pub/crypt/cryptography/symmetric/skipjack/
SKIPJACK and the key exchange algorithm were declassified after
it became clear that Clipper wasn't going to fly. (that doesn't
necessarily mean that's why they were declassified). So you
probably have the real thing.
-David
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: SSL and FTP over SSL -- Need resources.
Date: Sat, 17 Jul 1999 09:38:21 +1000
Lincoln Yeoh wrote:
> On Mon, 12 Jul 1999 19:22:14 GMT, [EMAIL PROTECTED] wrote:
> >I am developing an FTP server specialized for electronic commerce.
> >Among other requirements, it must support SSL.
> >
> Ouch! FTP uses two connections, then you've got to cater for the
> differences between PORT and PASV modes. Urk!
>
> I don't think there's a spec for SSL-FTP. But you could just put each
> normal FTP connection within an SSL one. But for PORT FTP it means the
> client probably needs to _provide_ a server style cert to the FTP server
> for the data connection.
No, just because the server does a connect, does not mean that the
SSL protocol needs to be run with the client running the server
side of the protocol. This also means that session-id reuse can
be used. Some SSL implementations may force the connecting
side to be the client in the SSL protocol, but this is
an artificial restriction, not a problem with the protocol
protocols problem.
eric
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Molecular-Computing and DES
Date: 16 Jul 1999 23:16:17 GMT
James Pate Williams, Jr. <[EMAIL PROTECTED]> wrote:
> chosen-plaintext attack that requires less time. Has
> the key experiment been openly performed?
Lenoard Adleman kicked off the whole "brute force with
molecular bio" craze by experimentally solving an instance
of a travelling salesman problem. So some experimental work
has been done. I'm not sure what the current state of the
art is, however.
-David
------------------------------
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: Molecular-Computing and DES
Date: Fri, 16 Jul 1999 20:47:10 GMT
In 1995 Boneh, Dunworth, and Lipton wrote a paper:
http://theory.stanford.edu/~dabo/pubs.html
called "Breaking DES Using a Molecular Computer".
In it they describe a molecular biological attack
using a liter of solution and approximately four
months of chemical work-up. Their algorithm can be
applied to most 64-bit ciphers. They also describe a
chosen-plaintext attack that requires less time. Has
the key experiment been openly performed?
==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Password generation question
Date: 16 Jul 1999 23:38:33 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> For the pass word , I'd just take the amount of bits you want directly form
> /dev/random
> and not rehash it again afterwards...
Ah hah. Here's the coderpunks archive(searchable!) :
http://www.privacy.nb.ca/cryptography/
and this message is in the middle of a thread which discusses /dev/random.
It indicates that the pool of bits is already hashed with SHA-1, so you
probably don't need to hash it again.
http://www.privacy.nb.ca/cryptography/archives/coderpunks/new/1999-04/0089.html
-David Molnar
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Password generation question
Date: Fri, 16 Jul 1999 23:14:00 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John McDonald,
Jr.) wrote:
> Gee, I always thought they were kooks.... Or was that spooks?
>
> Geez. I can never remember.
What about cleaners? (oh wait they are hitman...).
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Terry Mechan" <[EMAIL PROTECTED]>
Subject: check out wincrypt
Date: Fri, 16 Jul 1999 23:23:26 +0100
There are some good reference cusomers using this now
http://www.tmechan.freeserve.co.uk
Regards
TJM
------------------------------
** 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
******************************
