Cryptography-Digest Digest #292, Volume #9 Sun, 28 Mar 99 04:13:03 EST
Contents:
Re: Random Walk (R. Knauer)
RC4 weakness? ([EMAIL PROTECTED])
DES or RSA Program source (C langage) (BERTINI Fabien)
Re: Message Digest (wtshaw)
Re: Assymetry cryptography is dead :)) (wtshaw)
Re: How do I determine if an encryption algorithm is good enough? (Serge Paccalin)
Extending a hash? (Peter Gunn)
Re: RSA key distribution ("Roger Schlafly")
Re: RSA key distribution ("Roger Schlafly")
Re: Extending a hash? (Casey Sybrandy)
What did Gilbert Vernam look like? (monterey)
Key Schedule for my algorithm ([EMAIL PROTECTED])
Mathematically, when does Blowfish key=3DES? (UBCHI2)
Re: a little math please ([EMAIL PROTECTED])
Re: Mathematically, when does Blowfish key=3DES? ([EMAIL PROTECTED])
Re: Extending a hash? (wtshaw)
Re: Securid Card (Vin McLellan)
Re: Extending a hash? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random Walk
Date: Sat, 27 Mar 1999 15:48:41 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 25 Mar 1999 09:43:11 -0700, Shawn Willden <[EMAIL PROTECTED]>
wrote:
>If I have a radio antenna that monitors noise from the stars and it just so
>happens that the resulting bit stream has P(0)=.5 and P(1)=.5 (again, as
>discovered through tests), is this stream random? Yes. Is it a good RNG for
>cryptographic purposes? No. An attacker may be able to monitor the same
>source.
>If I have a noise-based RNG based on radioactive decay, well-shielded to
>prevent an attacker from monitoring the output, and I have not performed any
>statistical tests to look for, is this stream random? Yes, it is. Is it a
>good RNG for cryptographic purposes? Possibly not. An attacker may be able to
>detect significant biases in the output (possibly due to a feedback loop or
>other bug).
Both processes described above are quantum mechanical in nature.
Therefore they have two properties of significance here:
1) The two quantum processes above are truly random;
2) Measuring a sequence of random variables for those two quantum
processes will preclude someone else from learning about that
measurement sequence. The act of measurement destroys any and all
information about a particular sequence of measurements of random
variables associated with a quantum processes.
Therefore in principle, your statement in the first case above is
about someone else being able to monitor your star noise source is
incorrect - you can use quantum noise from the stars, and even publish
your exact source openly.
And your statement in the second case about shielding the radioactive
source above is incorrect - you do not have to shield the radioactive
source to keep someone else from measuring the decay process.
If what you meant in the second case was to shield the *final* output
- the random sequence itself - to avoid a tempest attack, then your
statement is correct.
I make my comment based on the reference to "output" to mean the
output of the radioactive source itself, in which case the statement
about shielding the radioactive source from extraneous monitoring is
incorrect, since once a decay event is measured by you, the
information contained in that event is lost forever to anyone else.
Bob Knauer
"I am clearly more popular than Reagan. I am in my third term.
Where's Reagan? Gone after two! Defeated by George Bush and
Michael Dukakis no less."
-- Marion Barry, Mayor of Washington DC
------------------------------
From: [EMAIL PROTECTED]
Subject: RC4 weakness?
Date: Sat, 27 Mar 1999 16:00:20 GMT
I did an entropy test of state[XorIndex] and found that it is has a bias.
I would like someone else to test it, and see if they come to the same
conclusions. I encoded a buffer full of zeros and counted the output symbols.
Source code for RC4 is at
http://members.tripod.com/~tomstdenis/rc4.c
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: BERTINI Fabien <[EMAIL PROTECTED]>
Subject: DES or RSA Program source (C langage)
Date: Sat, 27 Mar 1999 16:08:07 +0100
Reply-To: [EMAIL PROTECTED]
Do you know where we can find the source code in C langage of the RSA or
DES system?
I will be very happy if anybody could help me or send me the adress
where I can find it.
My e-mail is [EMAIL PROTECTED]
Thank you at all!
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Message Digest
Date: Sat, 27 Mar 1999 12:22:37 -0600
In article <7kVK2.1373$[EMAIL PROTECTED]>, "karl malbrain"
<[EMAIL PROTECTED]> wrote:
>
> I'm sorry that you've chosen to <<snip>> the pertenent section of my
> reply -- hence the redundancy (factored from the VULGAR)
Wicked things, cut and paste.
>
> No, the 128 bit length of the Message Digest is MORE than enough length to
> GIVE each message ever created by a person its own (expected to be unique)
> MD value. Let's see, 2^32 ~ number of persons alive, that leaves ~
> 2^(128-32) messages each!!! Gee, that's more than the number of nucleons in
> the known universe!
That really is beside the point. An approximate length hash, a MAC close
to the length of the source, can be used to verify content of the
original, specifically identifying areas that might have been changed.
Typical message digests and so-called secure hashes could not very well do
this. But, with the proper algorithm, you can, and still well prevent an
attack of the key used in the MAC. Needless to say, I think I have the
only algorithm that does that well, admitted that it is secret keyed..
> (... sections snipped under the rubrick that I'm still ~45 quarter units shy
> of my BSEE from CAL...)
>
> > Ethnic clensing does not appear to be a response to a high moral calling.
>
> My, how this was never an issue under the PROTECTIVE CUSTODY of the
> CONSTITUTED RED army!! Karl M
--
Ethnic clensing does not appear to be a response to a high moral calling.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Assymetry cryptography is dead :))
Date: Sat, 27 Mar 1999 12:24:43 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Francois Grieu) wrote:
> "Arthur" <[EMAIL PROTECTED]> wrote :
> > 4731083528105746283956593479028465928745473
>
> 41*3917285674659911261*29457203471209423131373
>
And he did that on his abacus too.
--
Ethnic clensing does not appear to be a response to a high moral calling.
------------------------------
From: [EMAIL PROTECTED] (Serge Paccalin)
Subject: Re: How do I determine if an encryption algorithm is good enough?
Date: Sat, 27 Mar 1999 23:11:42 +0100
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Hi!
>
> > <<How can I test if this algorithm is easily crackable?>>
> > General rule: if you don't have years of experience making
> > cryptographic systems, then it is definitely easily crackable. (Even
> > then, odds are not so good. :-D )
>
> Maybe this one I've created is hard to crack, even though I have no
> cryptographic experience.
>
> You can't assume that it's bad, without examining it first.
>
Read the following and guess whow wrote it...
<QUOTE>
|When I was in college in the early seventies, I devised what I
|believed was a brilliant encryption scheme. A simple pseudorandom
|number stream was added to the plaintext stream to create
|ciphertext. This would seemingly thwart any frequency analysis of
|the ciphertext, and would be uncrackable even to the most resourceful
|Government intelligence agencies. I felt so smug about my
|achievement. So cock-sure.
|
|Years later, I discovered this same scheme in several introductory
|cryptography texts and tutorial papers. How nice. Other
|cryptographers had thought of the same scheme. Unfortunately, the
|scheme was presented as a simple homework assignment on how to use
|elementary cryptanalytic techniques to trivially crack it. So much
|for my brilliant scheme.
|
|From this humbling experience I learned how easy it is to fall into a
|false sense of security when devising an encryption algorithm. Most
|people don't realize how fiendishly difficult it is to devise an
|encryption algorithm that can withstand a prolonged and determined
|attack by a resourceful opponent. Many mainstream software engineers
|have developed equally naive encryption schemes (often even the very
|same encryption scheme), and some of them have been incorporated into
|commercial encryption software packages and sold for good money to
|thousands of unsuspecting users.
<END QUOTE>
Did you guess? Did you recognize Philip Zimmermann, the author of PGP?
Abstract from "PGP(tm) User's Guide - Volume I: Essential Topics"
Best Regards
--
___________
_/ _ \_`_`_`_) Serge PACCALIN
\ \_L_) [EMAIL PROTECTED]
-'(__) People take different roads seeking fulfillment
_/___(_) and happiness. Just because they're not on your
road doesn't mean they've gotten lost. - H. Jackson Browne
------------------------------
From: Peter Gunn <[EMAIL PROTECTED]>
Subject: Extending a hash?
Date: Sat, 27 Mar 1999 22:40:27 +0000
Hi there,
Im looking for a good 256bit hash algorithm for passphrase hashing
for input to an encryption routine, and although Ive done a fair amount
of searching the only algorithm which seems to cover 256bits is HAVAL.
Now, Ive heard tell of 'extending' hash algorithms like doubling up
RIPEMD128, or the 240bit 'double barrelled' SHA-1 approach taken
by the Pegwit program, but Im guessing these offer nowehere near as
good an output as a true 256bit hash??
So, two questions for the crypto gurus (and anyone else :-)...
1) What 256bit hash algoriths are there out there?? (esp. those suitable
for passphase hashing.. and that can be implemented reasonably fast
(both time & code :-))
2) Are there any general purpose algorithms for 'extending' a hash
function that can be used with predictable results??
Ive got Schneider's doc on low entropy keys and key stretching... what
else can I read??
ttfn
PG.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: RSA key distribution
Date: Sat, 27 Mar 1999 16:51:08 -0800
DJohn37050 wrote in message
<[EMAIL PROTECTED]>...
>It is not true that Bob's procedure MUST be used. ANSI carefully separated
the
>requirements from the recommendations from the examples. Bob's method is
one
>method and in some sense shows that the requirements could be met in a
>reasonable way without too much performance cost. But it is not THE
required
>method, others are possible as long as the requiements are met.
Ok, but the primes must be "strong" primes according to Bob's
definition. The issue is whether requiring strong primes is a good idea.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: RSA key distribution
Date: Sat, 27 Mar 1999 16:57:15 -0800
Paul Rubin wrote in message ...
>In article <7dgcnr$vo6$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>>I do not like to get involved business issues. Let me point out that
>>RSADSI has a lawsuit against Mr. Schlafly (as I understand it for patent
>>infringement) and he has some sort of suit against us, (the nature of
which
>>I do not know).
>
>The stuff on his web page is interesting reading; you might look at it.
Thanks. I just updated it.
http://bbs.cruzio.com/~schlafly/pkp.htm
The judge just dismissed RSADSI's lawsuit against me (for patent
infringement). It was a complete win for me. I did not even use a
lawyer. IMO, RSADSI's ability to defend its patent in court is highly
questionable at this point.
If the case had continued, I was going to counterclaim RSADSI for
an assortment of crimes that it has committed. But as of now, I have
no lawsuit against RSADSI.
------------------------------
From: Casey Sybrandy <[EMAIL PROTECTED]>
Subject: Re: Extending a hash?
Date: Sat, 27 Mar 1999 20:26:05 -0500
There is a GOST hash function that generates a 256 bit hash. It uses the
GOST encryption algorithm. I don't know where to get any details on it. If
you happen to find some literature on this algorithm, I'd like to see it
too.
Casey
Peter Gunn wrote:
> Hi there,
>
> Im looking for a good 256bit hash algorithm for passphrase hashing
> for input to an encryption routine, and although Ive done a fair amount
> of searching the only algorithm which seems to cover 256bits is HAVAL.
>
> Now, Ive heard tell of 'extending' hash algorithms like doubling up
> RIPEMD128, or the 240bit 'double barrelled' SHA-1 approach taken
> by the Pegwit program, but Im guessing these offer nowehere near as
> good an output as a true 256bit hash??
>
> So, two questions for the crypto gurus (and anyone else :-)...
>
> 1) What 256bit hash algoriths are there out there?? (esp. those suitable
>
> for passphase hashing.. and that can be implemented reasonably fast
> (both time & code :-))
>
> 2) Are there any general purpose algorithms for 'extending' a hash
> function that can be used with predictable results??
>
> Ive got Schneider's doc on low entropy keys and key stretching... what
> else can I read??
>
> ttfn
>
> PG.
------------------------------
From: monterey <[EMAIL PROTECTED]>
Subject: What did Gilbert Vernam look like?
Date: Sat, 27 Mar 1999 20:13:21 -0500
I am trying to find an image file of Gilbert Vernam and/or Joseph
Mauborgne without any success. Has anyone ever run across a picture of
Vernam? If so could you refer me to the book/website?
Thanks.
------------------------------
From: [EMAIL PROTECTED]
Subject: Key Schedule for my algorithm
Date: Sun, 28 Mar 1999 00:22:32 GMT
I updated TC1 (my algorithm) based on some ideas by Jack Lloyd. However I
still have to work out the key schedule. I want to use ideas from RC6 adn
TEA, but not actually copy them.
If you would like to peak it's at:
http://members.tripod.com/~tomstdenis/tc1.c
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Mathematically, when does Blowfish key=3DES?
Date: 27 Mar 1999 13:20:00 GMT
How long does the blowfish key have to be to create an encryption as strong as
3DES?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: a little math please
Date: Sat, 27 Mar 1999 13:13:16 GMT
> The question's wording is ambiguous. If `an even number of' means
> `equally many', then C(256, 128) is correct. If `an even number of' means
> `counts divisible by 2', then 2^255, as posted by others, is correct.
I meant equally many.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Mathematically, when does Blowfish key=3DES?
Date: Sat, 27 Mar 1999 15:07:48 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (UBCHI2) wrote:
> How long does the blowfish key have to be to create an encryption as strong
as
> 3DES?
>
Strong against what attacks? If it's a key search, then a 112 bit key is ok.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Extending a hash?
Date: Sat, 27 Mar 1999 23:30:27 -0600
In article <[EMAIL PROTECTED]>, Peter Gunn
<[EMAIL PROTECTED]> wrote:
>
> 2) Are there any general purpose algorithms for 'extending' a hash
> function that can be used with predictable results??
By extending, I assume that you mean getting more information out than you
input to the hash. Good hashing might decrease content from input to
output, but, not increase it. In short, there ain't no free lunch; learn
to use appropriate sized inputs, or settle for knowing that your
pseudooutput is worth less than it might appear.
But, if you must, simply glue the input you have to necessary number of
copies of itself to get the desired input length. Then, do the hash on
your sandwich. Careless users will continue to use short passphrases;
there is not much you can do about that, just continue to warn them about
the problems with such a practice.
>
> Ive got Schneider's doc on low entropy keys and key stretching... what
> else can I read??
How about a receipe for taffy or whipped cream?
>
--
Ethnic clensing does not appear to be a response to a high moral calling.
------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Securid Card
Date: Sun, 28 Mar 1999 03:33:53 -0400
I'm glad my post was useful to so many people.
"Steve Matthews" <[EMAIL PROTECTED]> wrote:
> Am I correct in assuming SDI als now produce a 'soft' version of
> the token card (softID?) which can reside on Client machines.. if
> so how does this differ (if at all)from the token card
> implementation.
I'm something of a purist on this. I've never liked people
calling this type of wholly-software token emulators "soft tokens,"
since they are typically installed on desk-top systems.
By my lights, a software token emulator like SDTI's softID is
only equivalent in two-factor security to the classic hand-held
authenticator (HHA) -- traditionally, a physical token which is used
as a personal authentication device, assigned to an individual and
typically carried on his or her person -- when it is embedded in a
conventional smartcard, or a personal organizer like 3Com's PalmPilot,
or in a laptop that is habitually held dear and close.
To respond directly, Steve: you are correct. SDTI offers a
"softID" version of the SecurID in a stand-alone app for Windows-based
laptops and desktop workstations. (Yup. They also have SoftID for
3Com's PalmPilot, as well as a version that is installed in a standard
smartcard.)
The SoftID hash algorithm is the Brainard one-way function,
the same used in the SecurID hardware token. The SoftID
token-emulator's internal protocol is almost identical to that used in
the PinPad SecurID token. That is, the user's memorized PIN and the
pseudo random SecurID hash are arithmetically added (no carry) within
the SoftID's host to generate a combined PRN "token-code," the better
to protect the PIN (which has to be manually typed in for each
authentication.)
The difference in form factor does have some interesting
implications, however.
Bill Murray of Deloitt noted earlier: "Among other
differences, it has code in it to resist arbitrary copying." As you
would expect, the SoftID has layered (3DES) crypto protecting the seed
used in the token emulation, as well as other safeguards against
reverse engineering. It uses several tricks to bind the app to the
machine it is first installed on, so illicitly moving a working
version of SoftID from one CPU to another is quite difficult --
although, given that this is all in software, not impossible.
(The concern is not software piracy. It is, after all,
presumed that an HHA -- or a token-equivalent -- can only exist in one
place, and that it functions only under the control of its assigned
user. One user in one place. A one-time password can only serve its
function if the device that generated it cannot be easily copied or
effectively cloned by a thief or an errant user.)
SDTI's SoftID generates a SecurID token-code, a one-time
password -- and is thus, vastly more secure than a mere static
password or PIN -- but just because it is in software it is an
authentication service which requires an ongoing effort to safeguard
the integrity of its code, and the physical integrity of the CPU which
holds it.
To a much greater degree than with a physical token, the
relative security of any soft token emulator is a function of the
physical (and virtual) protection given to the computer which holds
it.
That said, the SoftID version of SecurID also has advantages,
particularly for corporate network management. It is, as one might
expect, cheaper -- although since much of the cost of the whole system
lies in the ACE/Server, not so much cheaper as some expect. Unlike the
hardware token, the SoftID also doesn't have a life span limited to
five years by a battery life. The real cost advantage of the SoftID
lies in administrative savings, however.
The fact that SoftIDs can be safely distributed to their
assigned users from an internal web server, or (in a self-decrypting
module, using RSA Secure PC, in mail) -- with the user given a
password "out of band" to unlock and install the module, cuts down the
cost of the initial roll-out considerably. (For reasons I've never
understood, some major corporations budget almost as much for their
staff time in distributing the tokens in roll-out as the do for the
physical SecurIDs themselves. Fortune 100 pay scales, I guess.)
On site administrators also seem to value highly the way
SoftID can be integrated into their own logon screens, and linked
(thru an API call) directly into Windows apps.
(For enterprise wide deployment, I presume that the sort of
firm which uses SoftID -- Intel, for example -- would today choose
SDTI's cert-based Keon authentication system instead of ACE/SoftID. If
you have to roll out per-user software, why not choose the system that
offers a full public key infrastructure? Perhaps particularly if it
can overlap, absorb, and support legacy SecurID installations within
the PKI?)
<[EMAIL PROTECTED]> wrote:
/> I am interested in how SecurID interacts with other third party
/> apps- y ou mentioned that terminal servers may contain securid code
/> -please can you provide some more info on how SecurID works with
/> Terminal server. For example, do you put the ace agent on the ts
/> and if so how do you authenticate to other apps in a ts session?
There are probably a hundred-odd third-party network products which
are sold and shipped with integrated ACE/Client code. (I pulled out
some URLs to point you to different categories of SDTI's strategic
partners, below, many of which have web pages which discuss how they
use the ACE/SecurID authentication.)
When the ACE/Client code is not integrated into something like a
terminal server or some home-grown app, the device has to be adapted
to call upon APIs in an ACE/Client to get SecurID support.
Typically, in such a situation, the ACE/Client is installed on
the server's platform, or on a client to that application server.
See SDTI's thumbnail descriptions of their strategic partners, with
hot links to partner sites, at:
31 vendors of Remote Access devices:
http://www.securid.com/partners/strategic/remote.html
11 Firewall venders:
http://www.securid.com/partners/strategic/firewall.html
13 vendors of Network and Application servers:
http://www.securid.com/partners/strategic/network.html
21 VPN vendors:
http://www.securid.com/partners/strategic/firewall.html
Functionally, of course, SecurIDs (and the ACE/Server and ACE/Clients
which support them) offer only authentication -- and user
authentication is only a security service which supports an access
control facility, which is what actually manages the user privileges
for the relevant user community.
Different environments place different access control facilities in
different places. Perimeter control devices like firewalls and remote
access servers use one type of access control; NT, UNIX, and IBM 390
hosts use their well-known access control modules for managing user
privileges. Some networked applications (e.g., an Oracle database)
may be set up to require a second level of authentication. Single
signon is emerging, but most enterprise environments today still use
different access control systems to protect different networks, hosts,
or other resources.
I beg the indulgence of the newsgroup (again) for continuing
this discussion, since there have been only peripheral references to
the crypto used in these systems. There are other newsgroups and
mailing lists where this would have been more appropriate, but the
questions were raised here.
As I noted earlier, I still work closely with SDTI as a
consultant. I'd be willing to discuss here the crypto used in, say,
the SoftID, the ACE protocol, or BoKs secure single sign-on, or the
Keon PKI system, if there is interest -- but more general discussions
about the architecture of ACE, BoKS, or Keon should probably be raised
elsewhere.
Suerte,
_Vin
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Extending a hash?
Date: Sun, 28 Mar 1999 10:41:21 +0200
Peter Gunn wrote:
>
> Hi there,
>
> Im looking for a good 256bit hash algorithm for passphrase hashing
> for input to an encryption routine, and although Ive done a fair amount
> of searching the only algorithm which seems to cover 256bits is HAVAL.
>
> Now, Ive heard tell of 'extending' hash algorithms like doubling up
> RIPEMD128, or the 240bit 'double barrelled' SHA-1 approach taken
> by the Pegwit program, but Im guessing these offer nowehere near as
> good an output as a true 256bit hash??
>
> So, two questions for the crypto gurus (and anyone else :-)...
>
> 1) What 256bit hash algoriths are there out there?? (esp. those suitable
>
> for passphase hashing.. and that can be implemented reasonably fast
> (both time & code :-))
GOSThash is quite slow, but this doesn't matter for password encryption
(you could use any other cipher with 64 bit blocksize and 256 bit
keysizs
instead of GOST) - you'll find a description at
ftp://ftp.funet.fi/pub/crypt/hash/gost/
You could use all AES candidates with 256 bit keysize in Tandem- or
Abreast-
Davies-Meyer mode to get 256 bit hashes.
Another way is to use a 128 bit hash algorithm twice, using the first
result
as chaining variables for the second one.
Andreas Enterrottacher
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
** 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
******************************
