Cryptography-Digest Digest #108, Volume #13 Mon, 6 Nov 00 11:13:01 EST
Contents:
Re: XOR Software Utility (freeware) available from Ciphile Software (Lissi)
Re: XOR Software Utility (freeware) available from Ciphile Software (Richard
Heathfield)
Re: Microsoft's script encoder (Richard Heathfield)
blowfish ([EMAIL PROTECTED])
Memory map Visual C (MS) ("kihdip")
Re: Hardware RNGs (Alan Rouse)
Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: blowfish (Alan Rouse)
Re: A new paper claiming P=NP (Daniele Degiorgi)
Re: Memory map Visual C (MS) ("Brian Gladman")
Re: Brute force against DES (David Wagner)
Re: CHAP security hole question (David Wagner)
Re: ECC choice of field and basis (Anwar Hasan)
Re: Brute force against DES (JPeschel)
Thanx alan ([EMAIL PROTECTED])
Re: Brute force against DES (David Wagner)
Re: Microsoft's script encoder (Sundial Services)
Re: Memory map Visual C (MS) (Sundial Services)
Re: [newbie] Is PGP 7.0 hash extension secure? ("Thomas J. Boschloo")
Re: [newbie] Is PGP 7.0 hash extension secure? ("Thomas J. Boschloo")
----------------------------------------------------------------------------
From: Lissi <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Mon, 06 Nov 2000 12:33:29 GMT
On 06.11.00, 04:36:29, the suspect Tom St Denis <[EMAIL PROTECTED]>=20=
answered when questioned about Re: XOR Software Utility (freeware)=20
available from Ciphile Software:
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
> How on earth did you make such a simple program take 155kb?
> Tom
LOL! Did you scan it for hidden nuisances, Tom?
Lissi
- --=20
Life ain't fair, but the root password helps.
-BOFH
PGP-Fingerprint:
F119 52A9 A520 B1C5 28B7 BDFE 2B72 9E38 479E 31CC
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
iQA/AwUBOgaW9ytynjhHnjHMEQL+1ACg9gsM8JtXCI8KH7jY+Mt+Je36c1UAoOcB
QHY46IJvTlwkOsZ8SABND7wF
=3DYdYl
=====END PGP SIGNATURE=====
------------------------------
Date: Mon, 06 Nov 2000 10:26:07 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
[alt.freespeech snipped from crosspost - my news server hates free
speech]
Anthony Stephen Szopa wrote:
>
> XOR Software Utility (freeware) available from Ciphile Software
>
> This software simply performs the universally available logical XOR
> process on two files chosen by the user and outputs the resulting
> file.
>
> http://www.ciphile.com
I tried to have a look at this, but failed. No source code. Just the
binary. On the system I'm using right now, I couldn't have run it even
if I'd wanted to.
Since it's such a simple program to write, why no source code?
If someone will kindly point out what they would expect to happen if the
two source files are of different lengths, I will happily post portable
C source code to do this, on alt.crypto.sources (to avoid clogging up
all the splendid newsgroups to which this was cross-posted). Mind you,
if the code exceeds twenty lines of code (not including #includes, {,
and }, I'll be very surprised indeed...
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
Date: Mon, 06 Nov 2000 11:18:29 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Microsoft's script encoder
Ichinin wrote:
>
> Richard Heathfield wrote:
> > You probably can't learn how it works, because reverse-engineering it
> > probably contravenes the terms of your licence agreement.
>
> Except where such license agreements are nullified by law...
Perhaps. But it seems to me that, when one agrees to a contract, one is
morally bound by that contract even if one is not legally bound by it
(unless there are overwhelming considerations to the contrary, such as
in the case of, say, a forced marriage).
<opinionated rant>
There's so much high-quality, free, Open Source and GNU software around
nowadays that locking oneself into proprietary and closed solutions
seems an odd strategy.
</opinionated rant>
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: blowfish
Date: Mon, 06 Nov 2000 13:16:58 GMT
Hi ...
I've had the "honor" to translate the blowfish algorithm from c to java
and i wonder ... can it be done ?
If yes! Hasn't it been already made by someone else ? If so is there
any good site you would recommend so i can download it thus saving
precious time ....
Thanx in advance for all help.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Memory map Visual C (MS)
Date: Mon, 6 Nov 2000 14:33:25 +0100
This is somewhat far from topic, but I figured that some of you have had
experience with this:
In Twofish, you're able to choose different levels of computations of the
subkeys. this affects the codesize, and the authors have made functions to
calculate the codesize.
But I'm not certain that tables and vars are included.
Does anybody know if Microsoft Visual C++ 5/6 outputs a memory map during
the link-operation ??
Or another way to get the exact code-size ??
Kim
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Mon, 06 Nov 2000 13:29:07 GMT
>If you use Yarrow, all you have to get right is
> the expected entropy per bit of each of your sources, and then it will
> safely produce only unguessable bits.
My point is, the output bits from a hash function are no more
unguessable than the input bits. My underlying assumption is that your
algorithm is not secret--a pretty standard assumption in cryptography.
I'm not familiar with the details of the Yarrow algorithm, but if it is
portable C code there is only so much that can be done to add entropy
under the covers. The ANSI X9.17 PRNG adds a small amount of entropy
to the input by mixing in a timestamp. That doesn't make the
result "unguessable" if the input seed was guessable. It makes it
somewhat harder to guess, but nowhere near impossible.
Note that timestamps are imminently guessable--knowing the approximate
time a timestamp-based random was taken dramatically reduces the search.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BENNY AND THE MTB?
Date: 6 Nov 2000 13:33:33 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>Matt Timmermans <[EMAIL PROTECTED]> wrote:
>: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
>: news:[EMAIL PROTECTED]...
>
>:> AFAIK, you are responsible for inventing this terminology - so I
>:> hesitate to tell you what I think of it.
>
>: I can take responsibility for that, yes. I assume you think it sucks.
>: []
>
>I would be quite happy with it - if zero wasn't somehow "odd".
>
>: What is the "oddness" of 0? Certainly less than the "oddness" of 1.
>
>In my books, 0 is indeed less "odd" than 1. 1 is odd, and 0 is not.
>
>: Since 1 is finitely odd, then 0 must be too.
>
>Am I losing it? If the conclusion follows from the premise here, I
>don't see how.
>
>I have "odd"ness as being associated with a lack of ability to divide by
>two - with a lack of evenness. I can't see how 0 sensibly qualifies ;-|
I am not sure where you two going. But it reminds of arrays do
we count arrays is in C from zero or one you could define it either
way. Even if you define fintiely odd as a infinte series of bits
where the last one is a fintie distance away. You could say Zero is
shortest distance meaning no one. But as with 1-1 bijective
unadulterated what ever we are again having trouble with what words
to use for what we want to say. I for one don't care that much about
words and would just as soon use loose definations. THe C source
code can define what we mean by it and allow for the various possible
bounary conditions as extra art. I fear to precise of a defination
may stright jacket ones creativeity. But you both are far more qualified
to pick the best words than me. Just don't let defintions stand in
the way of implementaions.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: blowfish
Date: Mon, 06 Nov 2000 13:43:58 GMT
Sun's JCE implements blowfish... see
http://java.sun.com/products/jce/
There are several open source projects implementing the Sun JCE spec.
Try
http://www.openjce.org/
http://www.cryptix.org/
http://www.bouncycastle.org/
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 06 Nov 2000 15:02:43 +0100
From: Daniele Degiorgi <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: A new paper claiming P=NP
This is a multi-part message in MIME format.
==============04C534C9DA3D2899107EB703
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Stas Busygin wrote:
> Dear Fellows!
>
> A new paper has just been published in Stas Busygin's Repository
> for Hard Problems Solving. It is "An Efficient Algorithm for the
> Minimum Clique Partition Problem" by A. Plotnikov. Please find this
> proposal on efficient solving of an NP-hard problem at:
> http://www.busygin.dp.ua/clipat.html
> http://www.geocities.com/st_busygin/clipat.html (mirror)
>
> The publication policy of the repository may be found at:
> http://www.busygin.dp.ua/call.html
> http://www.geocities.com/st_busygin/call.html (mirror)
>
> Best regards,
>
> Stas Busygin
> email: [EMAIL PROTECTED]
> WWW: http://www.busygin.dp.ua
I have tried to read the paper, some notions are somewhat difficult to
undestand, but I have seen a point that I find crucial:
The step 5 of the algorithm VS at page 12 loops on all maximum
antipaths (or I have misunderstand). How many can they be?
I know that there are graphs with an exponential number of maximum
cliques, their complement have an exponential number of maximum
independent sets and I suppose that we can found an orientation to
obtain an exponential number of antipath. Can such graphs appear in the
algorithm?
On the other way does the algorithm always terminate?
By the way, The partition of X by (1) on page 7 can be made in general
in several ways and with a lot of different values of m, ranging from 1
to n/2.
What happens to the algorithm above if the partition contains no maximum
independent sets (i.e. only maximal ones)
I tried with C_8 and a partition with m=3 (with 3,3 and 2 nodes): the
algorithm VS seems to loop.
Daniele
==============04C534C9DA3D2899107EB703
Content-Type: text/x-vcard; charset=us-ascii;
name="degiorgi.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Daniele Degiorgi
Content-Disposition: attachment;
filename="degiorgi.vcf"
begin:vcard
n:Degiorgi;Daniele Giorgio
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;0
fn:Daniele Giorgio Degiorgi
end:vcard
==============04C534C9DA3D2899107EB703==
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Memory map Visual C (MS)
Date: Mon, 6 Nov 2000 14:14:12 -0000
"kihdip" <[EMAIL PROTECTED]> wrote in message
news:8u6beo$l5c$[EMAIL PROTECTED]...
> This is somewhat far from topic, but I figured that some of you have had
> experience with this:
>
> In Twofish, you're able to choose different levels of computations of the
> subkeys. this affects the codesize, and the authors have made functions to
> calculate the codesize.
> But I'm not certain that tables and vars are included.
>
> Does anybody know if Microsoft Visual C++ 5/6 outputs a memory map during
> the link-operation ??
Yes
Brian Gladman
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Brute force against DES
Date: 6 Nov 2000 14:18:41 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
John A. Malley wrote:
>First, the plaintext is known (per the OP.)
I don't understand. If the plaintext is known, we can just compare
the result of the trial decryption to the known plaintext. Why bother
with anything more?
I'm lost. I thought we were talking about a ciphertext-only model of
exhaustive keysearch.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: CHAP security hole question
Date: 6 Nov 2000 14:21:37 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
> > That SRP, EKE, and so forth do not solve the
> > authentication problems most
> > of people is not merely ignorance and inertia.
>
> I think it is exactly ignorance and inertia.
Well, I suspect patents and other intellectual property restrictions
are a third reason that the EKE, SRP, etc. protocols aren't more widely
deployed.
------------------------------
From: [EMAIL PROTECTED] (Anwar Hasan)
Subject: Re: ECC choice of field and basis
Date: 6 Nov 2000 14:22:42 GMT
In article <8u4l6n$1i9$[EMAIL PROTECTED]>,
Anwar Hasan <[EMAIL PROTECTED]> wrote:
>The Oct issue of the IEEE Transactions on Computers has an
>article on a hardware implementation of a versatile GF(2^m) processor.
>It reports GF(2^192) multiplication and inversion times
^^^
it is 191. Sorry for the typo.
>as 2.41 and 4.81 micro-seconds at 75 MHz. It processor
>can add two GF(2^191) elliptic curve points in about 25micro-sec.
>
>-AH
>
>
>
>In article <Mo%L5.12208$[EMAIL PROTECTED]>,
>Michael Scott <[EMAIL PROTECTED]> wrote:
>>
>><[EMAIL PROTECTED]> wrote in message news:8tpumv$hd9$[EMAIL PROTECTED]...
>>> Hello,
>>>.....
>>> 1) What are the advantages and disadvantages of choosing GF(2^m) or
>>> GF(p) (and why not GF(p^m) in general)?
>>>
>>
>>Good questions. Generally, and rather surprisingly, GF(p) is significantly
>>faster in software, not pushed by any commercial interest, much less subject
>>to patents. GF(2^m) is faster in special hardware, certain interests are
>>pushing it hard, and is more likely to involve patents. Some restricted
>>variants of GF(2^m) curves allow fast implementations, but some of these
>>have been found to be weak (giving the whole field a bad name).
>>
>>> 2) What are the advantages and disadvantages of choosing polynomial
>>> basis or optimal normal basis? Where can I find a good description of
>>> optimal nornmal basis?
>>>
>>
>>Polynomial basis faster in software. Optimal normal basis (if one exists)
>>faster in hardware. Do a Web search for IEEE P1363 (which has been trying to
>>standardise various PK technologies) for more information. Also I think
>>P1363a covers GF(p^m) curves.
>>
>>
>>Mike Scott
>>
>>Fastest is best.
>>MIRACL multiprecision C/C++ library for big number cryptography
>>Free implementations of Schoof's Algorithm for Elliptic Curves
>>http://indigo.ie/~mscott
>>
>>> Any references?
>>>
>>> Thank you all.
>>>
>>>
>>> Sent via Deja.com http://www.deja.com/
>>> Before you buy.
>>
>>
>
>
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Brute force against DES
Date: 06 Nov 2000 14:39:18 GMT
[EMAIL PROTECTED] (David Wagner)
>John A. Malley wrote:
>>First, the plaintext is known (per the OP.)
>
>I don't understand. If the plaintext is known, we can just compare
>the result of the trial decryption to the known plaintext. Why bother
>with anything more?
>
>I'm lost. I thought we were talking about a ciphertext-only model of
>exhaustive keysearch.
>
Nope, the plaintext is known. The guys just want to speed things
up a bit by testing and eliminating candidate keys after partial
decryptions. It's a little quicker than doing a full decryption with
each key. Malley's method should work.
I think the original poster wanted, also, some suggestions
on which keys to test first. Any ideas for him? Apparently, he
knows some of the key, too.
I think he is doing an experiment with another DES cracker.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: Thanx alan
Date: Mon, 06 Nov 2000 14:34:29 GMT
Thanx alot Alan
In article <8u6cis$62u$[EMAIL PROTECTED]>,
Alan Rouse <[EMAIL PROTECTED]> wrote:
> Sun's JCE implements blowfish... see
>
> http://java.sun.com/products/jce/
>
> There are several open source projects implementing the Sun JCE spec.
> Try
>
> http://www.openjce.org/
> http://www.cryptix.org/
> http://www.bouncycastle.org/
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Brute force against DES
Date: 6 Nov 2000 15:10:59 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
JPeschel wrote:
>Nope, the plaintext is known. The guys just want to speed things
>up a bit by testing and eliminating candidate keys after partial
>decryptions. It's a little quicker than doing a full decryption with
>each key. Malley's method should work.
Then why not just test the partial trial decryption result directly
against the appropriate part of the known plaintext? Why compare
bytes of the trial decryption result against themselves?
------------------------------
Date: Mon, 06 Nov 2000 08:25:00 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Microsoft's script encoder
Which is a good reason not to get into such a "marriage!" :-)
The only time you can put your trust into a scrambling system is when
you thoroughly understand how it works. Your adversary can download a
cracker from a warez site faster than you can blink. And =you= will be
"the only fool who doesn't know he's naked" because of course your
adversary will never clue you.
The problem with most encoding schemes is that =they= must be able to
decode the file, in order to execute it, with zero-knowledge of the key
(in plain or encrypted form) from the user. This means that the key
must be present, and concealed. Which means that a determined hacker
can find it. Which means that a cracker-program can, and has, been
written to find it automatically.
Microsoft is famous for their "XOR-table" security and at first blush
I'd just assume they've done the same thing again. But people look at
the Microsoft� logo and simply assume that "if it's from Microsoft, it's
gotta be good." That's the power of a brand.
>Richard Heathfield wrote:
> > Richard Heathfield wrote:
> > > You probably can't learn how it works, because reverse-engineering it
> > > probably contravenes the terms of your licence agreement.
> >
> > Except where such license agreements are nullified by law...
>
> Perhaps. But it seems to me that, when one agrees to a contract, one is
> morally bound by that contract even if one is not legally bound by it
> (unless there are overwhelming considerations to the contrary, such as
> in the case of, say, a forced marriage).
>
------------------------------
Date: Mon, 06 Nov 2000 08:30:21 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Memory map Visual C (MS)
I'm a wee bit confused how vars and tables would affect code-size unless
you are referring to constant-tables statically linked into the
program. As far as I know the code-map (which is available from =all=
compilers and linkers if you ask for one) always include such things in
the output. You can, in a few minutes, determine if the formulas you
have account for that.
One other small twist is that compilers give you some discretion about
"space vs. speed" in laying out arrays. For instance, x86 processors
like word-aligned data and record structures; some compilers will
intentionally insert "slack" bytes into the structure if you allow them
to. (You can also turn it off.) There's also the issue of the assumed
size of an 'int.' This might affect your calculations. But, literally,
one compile with your chosen compiler, and a look at the linker map
produced, will tell you immediately how much correction, if any, =you=
must add to the formula's result.
>kihdip wrote:
>
> This is somewhat far from topic, but I figured that some of you have had
> experience with this:
>
> In Twofish, you're able to choose different levels of computations of the
> subkeys. this affects the codesize, and the authors have made functions to
> calculate the codesize.
> But I'm not certain that tables and vars are included.
>
> Does anybody know if Microsoft Visual C++ 5/6 outputs a memory map during
> the link-operation ??
> Or another way to get the exact code-size ??
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: [newbie] Is PGP 7.0 hash extension secure?
Date: Mon, 06 Nov 2000 16:31:50 +0100
Benjamin Goldberg wrote:
>
> Thomas J. Boschloo wrote:
> > During a web search I found this document on the extension of a RIPEM
> > hash:
> > <http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html#extensions>.
> > I don't get this! (Sorry) Why would anyone want to get a 320 bit
> > result from a hash function, if it only has a security of 160 bits?
>
> The cited document states:
> "Remark that the security level of the 320-bit extension of RIPEMD-160
> is only guaranteed to be the same as that of RIPEMD-160 itself, and
> similarly for the 256-bit extension of RIPEMD-128 with respect to
> RIPEMD-128 itself."
<pnip>
> > It is unclear to me if the RIPEM-320 hash is generated from the same
> > input buffer as RIPEM-160 (allowing 'PGP tricks'), or only from the
> > RIPEM-160 hash output (resulting in a fixed 2^160 on 2^320 mapping).
>
> RIPEMD-160 has 10 32-bit integers to which the input is stirred, and as
> a final step before output, pairs of those integers are added to create
> a 160 bit output.
>
> RIPEMD-320 skips the final combining, and outputs all 10 integers
> directly.
Thank you for your detailed explanation. RIPEMD-320 is thus likely far more
secure than RIPEMD-160 and still a little bit faster too!
Thank you,
Thomas
--
We live in the Matrix <http://www.whatisthematrix.com>
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x225CA009
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: [newbie] Is PGP 7.0 hash extension secure?
Date: Mon, 06 Nov 2000 16:48:32 +0100
[EMAIL PROTECTED] wrote:
>
> "Thomas J. Boschloo" <[EMAIL PROTECTED]> writes:
> > I had a little e-mail conversation with Micheal Young on the hash extension
> > used in PGP (described in RFC 2440). I am not as knowledgeable as him, so I
> > can't see if his arguments are true.
> >
> > My statement was that in order to use Twofish or Rijndael to its full
> > potential of 256 bits security, you would need to have a 256 bit hash
> > function like they are creating a draft for in
> > <http://csrc.nist.gov/cryptval/shs.html>. Micheal Young however, claims that
> > the process used in PGP to extend the SHA-1 algorithm to 256 bits is secure
> > enough. In PGP you have a large ammount of random data in your entropy pool
> > and a 256 bit session key is generated by taking the SHA-1 hash on this
> > data. Then the extra missing 96 bits are generating by feeding that same
> > pool, with a '/0' character prepended to it, to the SHA-1 function.
>
> This is not correct. You are confusing the method used by PGP to
> generate keys from passphrases with the method used to generate random
> session keys.
Sorry, I was generalizing too much.
So that leaves you guys with examining _two_ methodes for generating
symmetric keys ;-)
> PGP generates session keys in one of two ways. Either the key is
> based on a user passphrase, or it is generated from the internal
> random number generator.
>
> The mechanism of passing data through a hash twice, prepending a zero
> the second time to get more bits out than the hash size, is used for
> turning a passphrase into a key. Assuming your passphrase has 256
> bits of entropy, this method should produce 256 bits of random output,
> within a bit or two.
Does _should_ mean should as in:
1] RIPEMD-256 should be 256 bits secure, but might be only as secure as
RIPEMD-128 if you're unlucky.
Or should as in:
2] SHA-1 should be 160 bits secure, but might be less secure if someone
finds a succesful attack on SHA-1.
This matters to me because I trust the creators of RIPEMD-256/320 better
than the programmers and designers at PGP. And at least the guys at
Leuven are honest about a possible weakness in their algorithm (Al Gore
Rythm <grin> Only realizing that now).
> If you are generating a random session key (as when encrypting to a
> public key), the PGP random number generator is used. The code for
> this is complicated and involves both hash and encryption transforms.
> It does not use the simple structure you are worried about.
I am pleased to see that people have taken the trouble to go through PGP's
source code as I wouldn't be able to spot the difference between a secure
code and an insecure code if it is not based on simple things like reference
implementations of e.g. SHA-256.
Yarrow would also be nice in PGP and like Tom McCune wrote in A.S.P., the
new PGP 7.0 also uses the RNG on Pentium III's so it would probably be
secure enough for a simple soul as myself :)
Sorry for all the questions,
Thomas
--
We live in the Matrix <http://www.whatisthematrix.com>
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x225CA009
Email: boschloo_at_multiweb_dot_nl
------------------------------
** 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
******************************
