Cryptography-Digest Digest #593, Volume #13 Tue, 30 Jan 01 18:13:00 EST
Contents:
Re: Random stream testing. (long) ("Paul Pires")
Re: How many bits of security can a password give? (Splaat23)
Re: Ciphertext Stealing question (Paul Rubin)
Re: Recommendations on simplest way to add client/server encryption ("Joseph
Ashwood")
I need some crypting components for Delphi! ("ddd")
Re: fast signing (Bob Silverman)
Re: A Password Protocol (David Hopwood)
Re: fast signing ("Joseph Ashwood")
Re: Ciphertext Stealing question (Jim Gillogly)
Re: Ciphertext Stealing question ("Joseph Ashwood")
Re: fast signing (Paul Rubin)
Re: fast signing (Paul Rubin)
Re: I need some crypting components for Delphi! ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Random stream testing. (long)
Date: Tue, 30 Jan 2001 13:22:22 -0800
Joseph Ashwood <[EMAIL PROTECTED]> wrote in message news:OPsaMv#hAHA.319@cpmsnbbsa09...
>
> "Paul Pires" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Joseph Ashwood <[EMAIL PROTECTED]> wrote in message
> > <Snip>
> > > Well RNG output has 1 bit of entropy per bit, (Deterministic)PRNG output
> > has
> > > a fixed k bits of entropy scattered throughout the infinite output
> > (although
> > > the entropy in a given bit is likely to diminish to true 0 near the end
> > > versus near the beginning).
> > Is there any test that detects this difference in blind data? I believe
> that
> > you
> > said no but I just wanted to verify.
>
> Such a program can't exist, a program could however be created that gave an
> apparent entropy value, but not a measurement of real entropy.
>
>
> > Did you folks run any data collected from some true random source as a
> > control? Did it perform similarly to PRNG's as far as "passing your
> > criteria"
> > goes? I have found that it is real hard to raise the bar just high enough
> > so
> > that there is a distinction between otherwise "Good" generators. Maybe it
> > is not possible but I still have some subborn pig-headed bumbling about to
> > do before I stop looking.
>
> Well we ran into a very hard problem, in order to verify the test suite we
> would have had to find a perfect true RNG, and that requires a mathematic
> proof for verification, so we actually couldn't (although we did do a
> smaller test on a bunch of dice where the dice actually failed, I suspect
> it's because of the bias in them, or because the suite was too small). If it
> didn't have a solid proof behind it then we ran the risk of verifying
> correctness against an incorrect benchmark.
> Joe
Sorry for the tardy reply, My server is acting senile again :-)
A proof of correctness would be great but I'd be happy to get
a handle on improving the discretion of tests. Right now, there
seems to be a knee in the curve. After a certain point is reached,
everything looks pretty darn good. What I have been looking into
is quantifying different tests against each other to see which ones
should trend alike and which ones seem un-correlated for same
data sets. My hope is to spot some inter-relationship that is more
sensitive to "Goodness" rather than looking for a "good/bad" score.
All I have found so far is a correlation between the Entropy test
[Hamming, pp. 104-108] as implemented in The test suite "ent"
and the Chi-square Test as implemented in the same package.
For a large result set, Chop, baseline shift, invert about the baseline
and scale and the two result sets graph over each other. Seems like
the only difference when looking at data sets is in the round-off error.
Unfortunately, I haven't found a practical use for this particular insight.
It probably means that at some basic level that these are the same
analysis looking a the same samples within each data file. They just
present the answer in a different way.
About the only thing I add to the effort is ant-like persistence. I test,
check, modify and observe and hope (like a kid with a chemistry set)
to spot something interesting. I tried thinking and it hurt. I am now
reduced to pokin around.
Thanks for the help,
Paul
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Tue, 30 Jan 2001 21:15:19 GMT
Umm, 8 random bytes = 64 random bits = 64 bits of entropy/"security".
There are 256^8 = (2^8)^8 = 2^64 different passwords with 8 random
bytes.
- Andrew
In article <95743r$ivp$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <94mn7a$27r$[EMAIL PROTECTED]>,
> Erik Runeson <[EMAIL PROTECTED]> wrote:
> > I'm doing some analysis on how many bits of security a password can
> > provide.
> >
> > For instance, if we take a password with 8 random characters (all
> lower
> > case to simplify a bit), it is easy to assume that it would mean:
> > 8*8=64 bits of security (since each character is 8 bits).
> > However, since there are only 26 lower case letters, the actual
figure
> > is:
> > log2( 26^8 ) = 37.6 bits
> >
> > Of course, the whole issue gets a lot more complicated when you add
> > upper case letters, numbers and other characters, as well as dealing
> > with the fact that users rarely choose random passwords.
> >
> > Does anyone know any articles or other studies in this area?
> >
> > - Erik Runeson
> >
> > ---
> > Disclaimer: This post represent my personal views,
> > not those of my employer.
> >
> > Sent via Deja.com
> > http://www.deja.com/
> >
> hrm, that seems a little dodgy. You say the an 8 character provides
64-
> bits of security. This wrong, If 8 random characters are selected for
a
> passkey then there are (256^8) - 1 other keys it could be. However,
> like you state people like to use printable characters etc....... and
> the effective reduction of key-space you point out is correct.
>
> A cipher with a small key is definitly insecure, however one with a
> massive keyspace doesn't insure security atall.
>
> Simon.
> --
> Hi, i'm the signuture virus,
> help me spread by copying me into Signiture File
>
> Sent via Deja.com
> http://www.deja.com/
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Ciphertext Stealing question
Date: 30 Jan 2001 13:32:00 -0800
"N. Weicher" <[EMAIL PROTECTED]> writes:
> I have Ciphertext Stealing working with odd-length messages as long as it is
> over 8 bytes in length. Is there any technique that will work with messages
> less than 8 bytes in length? Padding is not an option: the ciphertext must
> be the exact length of the plaintext.
What are you saying? If you have 6 bytes of plaintext, do you mean you
want 6 bytes of ciphertext? You can't do that with an 8-byte block cipher.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Recommendations on simplest way to add client/server encryption
Date: Tue, 30 Jan 2001 13:13:47 -0800
Crossposted-To: comp.security.misc
Oops, my typo. the server to client one uses IV2.
You are correct it does not make use the standard ssl handshake, so you
cannot call it ssl. What it does is it eliminates all the negotiation about
ciphers by simply fixing it to be 3DES.
A MAC is an abbrviation for Message Authentication Code. It's similar to a
hash function (like SHA-1) in that it is cryptographically strong and makes
tampering detectable. I'd recommend going to the cryptonessie site and
taking a look at the MAC entries, basically you need one for each direction
that needs to be sent either periodically or at termination of the
connection, you need to be prepared to rollback all actions if that MAC
doesn't verify.
Now about that sending the public key with no certification authority
involved. BY doing that you're entering territory that is very well known,
and know to be a bad place to be. Without a CA of some form (more on this
later) what you have is a perfect situation for a Man-In-The-Middle, because
the MITM can simply pretend to be the server, pass off his own key as the
real one, and communicate behind the client's back with the server. To
protect against this you need to create a small very limited CA. Since this
is obviously not designed for broad consumption you don't necessarily need a
full CA (although it wouldn't hurt), all you _need_ is a public key that is
embedded in the client, from there the client can verify any key signed with
that. To make things a bit less tricky you may just explicitly leave the
issues of certifying keys in the hands of the user much like PGP does. This
is done by having the user generate a private key, and then the user
determines which key(s) to sign. If the key isn't signed and the user
can't/won't sign it do not allow access. That will give you limited CA-like
ability with the user acting as the CA (hopefully the user trusts
him/herself).
Of course since this is a ner protocol it needs much more examination before
it can be as trusted as SSL. That was the point I think Angry Bob was trying
to make. What I would recommend is that you finalize your protocol design,
including formatting, and publish it completely, a post to sci.crypt
announcing it will likely be enough, but more may be necesary later on. Also
remember that any customers that are concerned about security will want to
examine what has been done, let them examine it in full detail. And keep
immaculate records of the development process. Just as an example I am in
the process of completing a project, there's only 2000 lines of code
involved, but I've got nearly 50 pages documenting why each decision was
made, even down to which character set is supported, which format numbers
are output in, why I chose the algorithms I chose, attacks that have been
examined (that alone is the majority of the documentation) and their
effectiveness, etc. It's not an easy job and this isn't even the beginning
(the other thing that Angry Bob was indicating).
Joe
------------------------------
From: "ddd" <[EMAIL PROTECTED]>
Subject: I need some crypting components for Delphi!
Date: Tue, 30 Jan 2001 15:10:17 +0100
Hi all, I need some crypting components or DLL's for Delphi5.0.
Could U help me.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Tue, 30 Jan 2001 21:38:45 GMT
In article <[EMAIL PROTECTED]>,
Gerard Tel <[EMAIL PROTECTED]> wrote:
>
>
> Bob Silverman wrote:
> >
> > In article <O9buH8niAHA.338@cpmsnbbsa09>,
> > > What is the fastest secure signing algorithm?
>
> > Note that RSA with e = 3 takes only 2 modular multiplies.
>
> But that is for signature verification.
> Signing uses the secret exponent d, which is NOT short
All we need is e*d = 1 mod phi(n)
Normally we first choose e = 3, then d is large.
Suppose instead we choose a large e, resulting in d = 3.
The method will still work.
After all, Don Johnson keeps asking me to put wording into a
standards document I am editing (over my objections and deriding me
when I don't) along the lines of
"small public exponents may not be safe. It may be safer to use
large public exponents".
I'm just making his suggestion public. I've let e be large.
We get d = 3 and now signing is very fast and verification slow,
instead of the other way around....
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Tue, 30 Jan 2001 21:45:36 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: A Password Protocol
=====BEGIN PGP SIGNED MESSAGE=====
John Savard wrote:
[snip]
> 1) The hash of the user's password is calculated: H(PW).
>
> 2) The challenge vector is decrypted: D(CV,H(PW)) -> ( MK, SK, R )
>
> 3) The master key is used to produce the hash of the user's password
> that the host computer posesses. H(E(PW,MK))
>
> 4) This hash is used as the key to encrypt the challenge vector, and
> the result is hashed.
>
> 5) This result is then encrypted by the session key, and the result is
> hashed, and this hash is transmitted to the host computer.
For each guessed password, an attacker can repeat these steps (using
an eavesdropped challenge vector), until the transmitted hash matches.
Therefore the protocol is vulnerable to off-line password guessing
attacks.
It is possible to do what you seem to want using a strong password-based
protocol such as SRP-3, PAK-X, SNAPI-X, etc.: one method is for the
client to run the password-based protocol with the secure computer
(via the host), then the secure computer tells the host the session key
in a signed, encrypted message (which is uniquely associated with that
session). There may be more efficient ways, but that one is obviously
correct, and gives an idea of what security properties you should be
aiming for.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOnXMDTkCAxeYt5gVAQGKEwf+NgtuTYWb3hK6QjUVhTnM0BOk8KddZKgp
1jIyx5Sqk1Iz7U6pfvk1drwcpQ8RFw3ZtMKvX/7DwVZ72ZTdFBn8oknf6WHV72VV
S5MkXpWco7VIf1Ra8hs81dNBkKhYN5LF3Stqu5hNMHfZkDet5mScMliik0YDgN24
FyeNRtZsR8+5tH5PiTlrc/5mlKC2QQtlsgi+JzoC8FvnPzAxdOaGzf1KtfqxmF8Q
PdU8bJrwt0656Z5nkAhVqDn5K7Lpt5tUBudaJvDj7EWxHy+FnZkLl6oB7VTKWSit
1TBKBhOx612MiwfZb9qeAZ72gg4Mkwto/I3/yefS9q36gvRxlWkr4g==
=GSFJ
=====END PGP SIGNATURE=====
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Tue, 30 Jan 2001 13:55:19 -0800
Ok to clarify:
I need signing to by excessively fast. I've got an application where one
person here expects in the 10,000 signature/second range (I doubt he'll get
that speed out of his code, but that's another issue), on a single-processor
x86 P4 1.5 GHz, gobs of RAM, etc.
The verification can take as long as it needs, preferably the sub-second
range, but it's unimportant.
Key generation can take hours if needed, I'm even less concerned about this.
As to what the application is, signing audit logs. From my view this should
be something you can bring into court and beat the defendant resoundingly
over the head with until he pleads guilty, so it needs to be extremely
solid. Right now DSA isn't fast enough, but before I go writing the stuff to
make use of precomputing I wanted to know if there was something that would
be significantly faster. I'm looking at the quartz recommendation, we'll see
where that leads.
Joe
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:O9buH8niAHA.338@cpmsnbbsa09...
> I've got a question for some of the other people. What is the fastest
secure
> signing algorithm? Right now I'm using DSA (openssl) but I'd like to get
it
> up around 20 times faster. Any ideas?
> Joe
>
>
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Ciphertext Stealing question
Date: Tue, 30 Jan 2001 14:01:42 -0800
"N. Weicher" wrote:
>
> I have Ciphertext Stealing working with odd-length messages as long as it is
> over 8 bytes in length. Is there any technique that will work with messages
> less than 8 bytes in length? Padding is not an option: the ciphertext must
> be the exact length of the plaintext.
This is off the top of my head, so there's probably something boneheaded about
it. I assume your currently-implemented ciphertext stealing is a cipher block
chaining deal, and you do something like encrypting the next-to-last
ciphertext to get the bytes to XOR against your partial last block.
Since the plaintext is the same length as the ciphertext, I assume further
that you have some way of getting a secret per-message IV so that the
first block isn't exposed to a codebook attack, or else you have a different
secret key for each message. In either of these two cases you could
encrypt the IV or the key with the key and use that to XOR against your
partial block. I suggest doing the encryption in case the IV or key is
printable or predictable in some way.
As Paul Rubin said, 64-bit block ciphers aren't good for doing smaller
blocks, but with CT stealing you aren't really using the block cipher
directly for your whole message anyway, so there may be some way around
your problem if you have enough key material lying around.
I know there are a lot of assumptions there, and as Samuel L. Jackson's
character said in "The Long Kiss Goodnight", when you make an assumption
you make an ass out of u and mption.
--
Jim Gillogly
Hevensday, 9 Solmath S.R. 2001, 21:50
12.19.7.16.15, 1 Men 18 Muan, Second Lord of Night
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Ciphertext Stealing question
Date: Tue, 30 Jan 2001 13:58:40 -0800
"N. Weicher" <[EMAIL PROTECTED]> wrote in message
news:ajEd6.3078$[EMAIL PROTECTED]...
> Is there any technique that will work with messages
> less than 8 bytes in length? Padding is not an option: the ciphertext
must
> be the exact length of the plaintext.
Nope. It can't be done, the output size of a deterministic cryptgraphic
function is going to be N-bits of zeros and ones no matter what you do. All
Ciphertext stealing does is overlap them. If it would work for you what you
can do is use a stream cipher, or a cipher with a variable block length, but
these have their own issues.
Joe
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: 30 Jan 2001 14:16:34 -0800
Bob Silverman <[EMAIL PROTECTED]> writes:
> I'm just making his suggestion public. I've let e be large.
> We get d = 3 and now signing is very fast and verification slow,
> instead of the other way around....
Um, now that the signing exponent is known, the signatures don't
authenticate much any more...
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: 30 Jan 2001 14:21:01 -0800
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> Ok to clarify:
> I need signing to by excessively fast. I've got an application where one
> person here expects in the 10,000 signature/second range (I doubt he'll get
> that speed out of his code, but that's another issue), on a single-processor
> x86 P4 1.5 GHz, gobs of RAM, etc.
There's no way to do that many sigs/sec on that hardware on a
continuous basis with any public key algorithm that I know of. The
way to secure audit logs is with hash chains, not public key
signatures. See:
http://www.counterpane.com/audit-logs.html
You might be able to do a DSA signature in 0.1 msec (1/10,000 sec) on
that P4 with several msec of precomputation per signature, i.e. if
you're going to have 10,000 documents to sign tomorrow, you could
spend several hours doing precomputation today and then do all 10,000
signatures in 1 sec, but I don't know if that helps you.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: I need some crypting components for Delphi!
Date: Tue, 30 Jan 2001 22:19:29 GMT
In article <9571tg$84f$[EMAIL PROTECTED]>,
"ddd" <[EMAIL PROTECTED]> wrote:
> Hi all, I need some crypting components or DLL's for Delphi5.0.
> Could U help me.
>
Search for Torry's, Delphi Superpage, VclComponents, Delphi32 etc on
the web. You will perhaps find what you are looking for on those sites.
Sent via Deja.com
http://www.deja.com/
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
