Cryptography-Digest Digest #114, Volume #13 Tue, 7 Nov 00 10:13:00 EST
Contents:
Re: Hardware RNGs (Paul Crowley)
Re: Psuedo-random number generator (Guy Macon)
Re: Psuedo-random number generator (Guy Macon)
Re: Q: Computations in a Galois Field (Paul Crowley)
Re: XOR Software Utility (freeware) available from Ciphile Software (Guy Macon)
Re: Give it up? ("kihdip")
Re: XOR Software Utility (freeware) available from Ciphile Software (Richard
Heathfield)
Re: Blowfish with 64bit feedback (Tom St Denis)
Re: Give it up? (Tim Tyler)
MORE THAN FULLY BIJECTIVE ! (SCOTT19U.ZIP_GUY)
Authentication and taking credit (was Re: Protocol) (Paul Crowley)
Re: Hardware RNGs (Alan Rouse)
Re: [newbie] Is PGP 7.0 hash extension secure? (John Myre)
Re: Calculating the redudancy of english? ("Kristopher Johnson")
Re: XOR Software Utility (freeware) available from Ciphile Software ("Scott Fluhrer")
----------------------------------------------------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Tue, 07 Nov 2000 11:14:40 GMT
Alan Rouse wrote:
>
> >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.
Yes, I agree - I can't quite see why you think I don't! If all the bits
from the all the sources Yarrow uses are guessable, then the output is
guessable. I'm not trying to claim it adds entropy in any way, I'm just
saying it makes the best use of the entropy you've got. I recommend
reading the Yarrow paper for a comprehensive description of these
issues.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Psuedo-random number generator
Date: 07 Nov 2000 11:15:56 GMT
Mok-Kong Shen wrote:
>
>Your program processes physical randomness, while he meant
>that a stream from a PRNG (often realized in software)
>can't contain more entropy than the key (seed), because all
>that is derived deterministically.
>
I understand the theory, and I accept the logic, but part of me
keeps saying that Microsoft Windows just *can't* be deterministic.
Maybe I could make a RNG based on the time between crashes...
;)
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Psuedo-random number generator
Date: 07 Nov 2000 11:19:46 GMT
David Schwartz wrote:
>
>> Your program processes physical randomness, while he meant
>> that a stream from a PRNG (often realized in software)
>> can't contain more entropy than the key (seed), because all
>> that is derived deterministically.
>>
>> M. K. Shen
>
> My point was simply that his stated claim:
>
>> > > Running a computer program cannot generate entropy.
>
> Is false. Actually, every physical process generates entropy,
>contributing to the eventual heat death of the universe.
>
I think that you mean increases entropy, not generates entropy.
You do realize that the definition of "Entropy" just changed from
crypto usage to physics usage in mid-conversation, right?
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Tue, 07 Nov 2000 11:37:06 GMT
Mok-Kong Shen wrote:
> No. I mean exactly GF(2^m), the finite field of order 2^m
> (a Galois field that is known to exist). I don't know
> the mathematical object you referred to or its relationship
> to GF(2^m).
GF(2)^m is the space of vectors of bits. For example, Rijndael mostly
treats byte value as representing values from GF(2^8), but the affine
transformation in the S-box can (AFAIK) only be sensibly defined in
GF(2)^8 - ie treating the byte simply as a vector of bits and doing a
matrix multiply followed by a vector addition.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: 07 Nov 2000 11:45:41 GMT
Richard Heathfield wrote:
>
>Anthony Stephen Szopa wrote:
>>
>> This software simply performs the universally available logical XOR
>> process on two files chosen by the user and outputs the resulting
>> file.
>>
>
>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...
>
I would pick the following behavior
Default: output an error message and refuse to do the XOR
Optional (command line switch or some such) behaviors:
Truncate the longer file to match lenghts before XORing,
output a warning.
Loop through the shorter file again and again to get enough
data to match the longer file, Output a warning.
Optional extra feature: Implement additional combining methods
defined at the following URL:
http://www.io.com/~ritter/GLOSSARY.HTM#Combiner
http://www.io.com/~ritter/GLOSSARY.HTM#BalancedCombiner
http://www.io.com/~ritter/GLOSSARY.HTM#LatinSquareCombiner
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Tue, 7 Nov 2000 12:47:26 +0100
"Richard Heathfield" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "SCOTT19U.ZIP_GUY" wrote:
> >
> > [EMAIL PROTECTED] (Richard Heathfield) wrote in
> > <[EMAIL PROTECTED]>:
> > snip
> >
> > >I was not advocating RLE as a compression algorithm. It has other
> > >problems apart from cryptographic ones. I was simply pointing out that
> > >it would not necessarily be susceptible to the attack under discussion.
> >
> > But the point is that even in your simple example most RLE
> > do lend them selves to this kind of attack. I thought you would
> > appreicate that fact. BUt I gess not.
>
> Nope, I guess not. Fear not - I'm not going to contradict you here. Like
> I said upthread, I'm no cryptographer. I suspect you're talking about
> the fact that the actual RLE decoding scheme must be assumed to be known
> to Eve, and she can look for valid RLE encodings as potential
> plaintexts. If that's what you mean, then (although I don't /quite/ see
> how it would work in practice) I do at least have half a clue as to what
> you're talking about.
>
>
>
> --
> 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: Tue, 07 Nov 2000 13:28:06 +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
Guy Macon wrote:
>
> Richard Heathfield wrote:
> >
> >Anthony Stephen Szopa wrote:
> >>
> >> This software simply performs the universally available logical XOR
> >> process on two files chosen by the user and outputs the resulting
> >> file.
> >>
> >
> >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...
> >
>
> I would pick the following behavior
So many choices!
>
> Default: output an error message and refuse to do the XOR
Nah... too dull.
>
> Optional (command line switch or some such) behaviors:
>
> Truncate the longer file to match lenghts before XORing,
> output a warning.
Eeeee, data destruction! Nah...
>
> Loop through the shorter file again and again to get enough
> data to match the longer file, Output a warning.
Ah, Vigenere. That'll do.
Okay, as promised, I have posted the source code to
news:alt.sources.crypto (I think I got their name right this time) - be
sure to check the followup post (last-minute correction)!
The source is also available at
http://users.powernet.co.uk/eton/crypto/xor.c for those who don't want
to subscribe to a whole other newsgroup just to check out one article.
It turned out to be rather more than 20 lines; 113 altogether. Of
course, only one line of that is the actual algorithm.
>
> Optional extra feature: Implement additional combining methods
> defined at the following URL:
>
> http://www.io.com/~ritter/GLOSSARY.HTM#Combiner
> http://www.io.com/~ritter/GLOSSARY.HTM#BalancedCombiner
> http://www.io.com/~ritter/GLOSSARY.HTM#LatinSquareCombiner
Very sweet of you to offer, but I think I'll leave those as exercises
for the reader. :-)
Now, Mr Szopa, this is called Open Source.
If I've made a mistake in the source code I posted, it can be
identified, criticised and corrected by the community. And it will be my
job to fix my code when the corrections are communicated to me.
It's called peer review.
You should try it.
--
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Blowfish with 64bit feedback
Date: Tue, 07 Nov 2000 13:26:31 GMT
In article <8u8jgo$[EMAIL PROTECTED]>,
"P. Pascual" <[EMAIL PROTECTED]> wrote:
> Hi ...
> Anybody knows where I could find a java implementation of CFB mode of
> Blowfish with 64bit feedback?
>
> I have a program written in C that uses this algorithm and i have to
decrypt
> it from a java program.
Why not find a Java implementation of Blowfish and implement it
yourself?
Plus I would think that JCE includes a CFB mode of operation...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 7 Nov 2000 13:42:40 GMT
Richard Heathfield <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Richard Heathfield <[EMAIL PROTECTED]> wrote:
:> : #include "iamnotacryptographer.h"
:>
:> : Now, let's take a specific example: PKZIP. If Z is the compression
:> : function, then C = E(Z(P)).
:>
:> : Since PKZIP'd headers begin with the two octets 0x504B ("PK" in ASCII),
:> : we have a known plaintext attack against E(), do we not? [...]
:>
:> No. You have some known-plaintext in each message. I known plaintext
:> attack uses known plaintext to improve on a brute-force keysearch.
:> That's not what you have.
: I don't understand why I'm wrong, but I am quite prepared to accept your
: statement as true. Thank you for the correction.
I'm not sure how else to put it. A known-plaintext attack on a cypher
is normally taken to mean that *if* you are given known plaintext, you
can recover the key (or similar) faster than you could by iterating
through the keys looking for the right one.
The case you described was one where each message contained known
plaintext. However there was no reason to believe this would help anyone
to find the key to the encryption algorithm any faster than a brute force
search of keys.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: MORE THAN FULLY BIJECTIVE !
Date: 7 Nov 2000 13:59:48 GMT
Friends At least four of you have a working concept of fully
bijective. Matt I think seems to lament the fact that he is
using CBC mode encryption but the the IV is fixed. The question
is can one use a full CBC with IV and retain the fully bijective
feature. The answer is yes. But we have to Map from the input
space to the output space in some specail ways. So that many
possible output files map back to the same input file. Yet
have every file covered as in normal fully bijective methods.
Georg Cantor would be proud.
Method one: use my rotaten and DSC to do the work then call matts
crrent BICOM. the random number added during rotaten to the data
is taken off so that still all possible input files are covered
and all possible files can be thought of as either and input
file or an output file. Yet each input file can map to many
output files. While each output file maps to a single input file.
IN short for any possibe file X create X + R where R is random
data then if talking compression: uncompress ( compress ( X + R )) = X
and also for any FILE Y there exists an R such that
compress( R + uncompress( Y )) = Y
Method two: envolves changing Matts code to allow for random
IV he either enters it on a flag or whatever. But at end of
compression stage Matt has a fintiely odd file where the last
one is a fintite number of bits away from start. He even allows
it to be ZERO steps away meaning all ZERO. At this point in the
code add 16 bytes of data to the front of the finitely odd files
You still have a fintitely odd file. Thank you Cantor. Now you
could add it straight or shuffle it in with the data. I like
the shuffle but his choice. Now do the bijective CBC full Rijndael
as before. The output set is the same as before. Namely it can
be any possible 8 bit binary file. Since he still is encrypting
from the set of all possible finitley odd files. Blending in the
random 16 bytes of info did not change the input set to the
encryption so the output set does not change. And Matts compression
need not change. However when one decrypts and decompresses all
he has to do is trash the random data that was added and it goes
back to the oringal input file.
Comments welcome.
David A. Scott
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: Paul Crowley <[EMAIL PROTECTED]>
Subject: Authentication and taking credit (was Re: Protocol)
Date: Tue, 07 Nov 2000 14:27:32 GMT
(Posted and mailed)
David Wagner wrote:
>
>http://gatekeeper.dec.com/pub/DEC/SRC/technical-notes/abstracts/src-tn-1998-007.html
Thought-provoking paper. There's no point in trying to protect credit
in a protocol that does not encrypt content - you can simply steal the
content before it arrives and present it as your own. If you share
files with a protocol that tracks authentication but not credit, you
might be able to read files by forcing them to be written in your own
name rather than the name of the writer.
I think a better way to look at this might be as an issue of implicit
content. If I say "credit me with this contest-winning entry" or "write
this file in my name", the "me" is implicit content. Credit-stealing is
not an issue where messages do not have implicit content - if I specify
to whom the contest winnings are to go in the message claiming them,
then credit cannot be stolen. I would tend to feel that if you want
every message on a channel to have some implicit content (like to whom
it should be credited) along with the explicit content, you should
securely negotiate this when you set the channel up.
There's a paper by Ross Anderson which argues that signed content should
always err on the side of being as explicit as possible, though I can't
now find it (anyone remember?). I think credit-stealing attacks are
just one kind of attack that becomes possible if you don't follow his
advice. In that sense, credit assignment properly belongs to the layer
above authentication, and so authenticating protocols should be designed
with the role of assigning responsibility in mind, rather than assigning
credit.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Tue, 07 Nov 2000 14:25:19 GMT
Paul Crowley wrote:
>Yes, I agree - I can't quite see why you think I don't!
I think you and I agree completely. My original post was in response
someone else's suggestion that hashing less-than-random input resulted
in random output.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: [newbie] Is PGP 7.0 hash extension secure?
Date: Tue, 07 Nov 2000 07:41:23 -0700
David Wagner wrote:
<snip method for getting >160 bits out of SHA>
> Note that the last statement is an unproven assumption, and there are
> reasons to be skeptical that you will ever get much more than a 160-bit
> security level from these types of constructions.
<snip>
What sort of reasons? Ritter-like reasons, as in "you can't prove
strength", or something more concrete? I note, for example, that
NIST uses SHA as a source of pseudo-random numbers in FIPS 186 (the
digital signature standard).
JM
------------------------------
From: "Kristopher Johnson" <[EMAIL PROTECTED]>
Subject: Re: Calculating the redudancy of english?
Date: Tue, 07 Nov 2000 14:37:11 GMT
But dictionary entries still don't look much like real-world writings. For
example, every verb definition contains the word "to". And there are many
entries of standard forms such as "a person skilled in <whatever>", "a
member of a <whatever>", "an instrument for <whatever>", and so on. And
there are no complete sentences, which I presume would screw up the
frequencies of various parts of speech..
I'll agree that the letter frequencies are probably useable. But word
frequencies will be skewed.
-- Kris
"David C. Barber" <[EMAIL PROTECTED]> wrote in message
news:8u7e4p$9m4$[EMAIL PROTECTED]...
> I was speaking of dictionary entries *and* their following definitions,
> where common words would likely be more used than uncommon words.
>
> *David Barber*
> "Kristopher Johnson" <[EMAIL PROTECTED]> wrote in
> message news:5KFM5.16697$[EMAIL PROTECTED]...
> > Dictionary entries aren't representative of "real-world" letter or word
> > frequencies.
>
>
>
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Tue, 7 Nov 2000 06:59:46 -0800
Scott Craver <[EMAIL PROTECTED]> wrote in message
news:8u7koj$rh5$[EMAIL PROTECTED]...
> Tim Tyler <[EMAIL PROTECTED]> wrote:
> >In sci.crypt Andre van Straaten <[EMAIL PROTECTED]> wrote:
> >
> >: The disadvantage of the OTP is that only one added or left
> >: character in the key file or ciphertext file messes up the rest
> >: of the plaintext file. (E.g.: encrypting on Unix and decrypting on MS
> >: Windows)
> >
> >Hmm - this sort of error can usually be rectified with a small volume
> >of effort. I don't think this is "the disadvantage" of OTPs.
>
> Indeed, this is a disadvantage of both stream ciphers AND
> block ciphers, even in ECB mode. After all, block sizes are
> typically multiple bytes long, so a single missing character
> will misalign block boundaries.
That's what CFB mode is for -- it can resync after an added/deleted
ciphertext character, as long as the added/deleted material is a multiple of
the feedback size (which can be an octet).
--
poncho
------------------------------
** 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
******************************
