Cryptography-Digest Digest #115, Volume #13 Tue, 7 Nov 00 14:13:00 EST
Contents:
Re: hardware RNG's (Alan Rouse)
Re: ECC choice of field and basis (Robert Harley)
Re: Give it up? (James Felling)
Re: XOR Software Utility (freeware) available from Ciphile Software (James Felling)
Re: XOR Software Utility (freeware) available from Ciphile Software (those who know
me have no need of my name)
Re: Give it up? (SCOTT19U.ZIP_GUY)
Re: Psuedo-random number generator ("Trevor L. Jackson, III")
Re: Hardware RNGs (Alan Rouse)
Re: Brute force against DES ("Douglas A. Gwyn")
Re: Brute force against DES ("Douglas A. Gwyn")
Re: A new paper claiming P=NP (Stas Busygin)
Re: XOR Software Utility (freeware) available from Ciphile Software (Tom St Denis)
Re: MORE THAN FULLY BIJECTIVE ! (Tom St Denis)
Re: XOR Software Utility (freeware) available from Ciphile Software (Richard
Heathfield)
Re: [newbie] Is PGP 7.0 hash extension secure? (David Wagner)
----------------------------------------------------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Tue, 07 Nov 2000 15:04:09 GMT
David Schwartz wrote:
>However, you can measure the real physical randomness in the input
>directly.
That's not as easy as you make it sound. If a physical source produces
a sequence of 100 consecutive 1's, does that mean it is nonrandom?
The best you can do is to state the odds against that result coming
from a random source. But the odds against any other specific 100-bit
result from a random source are exactly the same. The Diehard
randomness tests require something like 2.9 million 32-bit integers to
draw conclusions, and even then those conclusions are debateable.
>Assuming you use a proper hash function, all that matters is precisely
> how much entropy is in the input.
My point exactly.
>If you know the maximum error bound in your estimate (at least in the
> downward direction), then hope is not needed.
"IF"... You can only hope that you know the maximum error bound in
your estimate. It is virtually impossible to know for certain that
there are no undiscovered biases in a physical source.
>If you use a PRNG with no known weaknesses, and you seed it with a hash
> with no known weaknesses, and you assume the lower bound for how much
> entropy in your input data, the resulting system will have no known
> weaknesses.
If you believe in fairies, clap your hands...
Some people think that the rand() function in their favorite language
produces real random numbers. Their ignorance of weaknesses does not
make the results random.
My point is that it is extraordinarily difficult if not impossible to
prove that a given random generation system is truly random. It is
certainly not sufficient to pipe nonrandom information (or information
of unknown entropy, such as the audio input that was suggested in the
beginning of this thread) into a hash function. Strong cryptography
requires very carefully designed random number generators. Failure to
do so can be very embarrasing. Just ask Microsoft.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: ECC choice of field and basis
Date: 07 Nov 2000 16:26:55 +0100
[EMAIL PROTECTED] (Anwar Hasan) writes:
> article on a hardware implementation of a versatile GF(2^m) processor.
> It reports GF(2^192) multiplication [...] as 2.41 [...] micro-seconds
> at 75 MHz
It takes about 0.64 microseconds on a 750 MHz Alpha... I'm surprised
that dedicated hardware is slower than a general purpose CPU and only
gains a factor of 2.5 or so even if you scale 10x for clock speed.
Rob.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Tue, 07 Nov 2000 09:33:54 -0600
Tim Tyler wrote:
> James Felling <[EMAIL PROTECTED]> wrote:
>
> : Agreed with reservations here. There are benefits to a 1-1(bijective)
> : compressor vs. the alternative, however the most important crireria are how
> : effectively it compresses the data, and how 'artifact' free it is. After
> : choosing on that basis, I'd take a bijective method vs a non-bijective
> : method.
>
> : Reasoning.
>
> [...]
>
> In principle, bijective methods allow smaller file sizes - but in practice
> the technique is relatively new, and imposes an additional constraint on
> the author of the compression program - so compression ratios are not yet
> as good as they could be.
> --
> __________ http://alife.co.uk/ http://mandala.co.uk/
> |im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
I realized upon a reread that it could be construed that I favor bijective
compressors vs. conventional compressors for the reasons given. In actuallity
what I was saying is that those criteria are how I judge compressors ( freedom
from artifacts and compressive efficiency) assuming that the bijective method was
equivalent to the conventional method on that score then I would chose the
bijective because of reasons 1-3. Since the situation at present is that in most
cases bijective compressors do not match up to conventional compressors on my two
primary criteria, I use conventional compressors for almost all of my compression
needs.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Tue, 07 Nov 2000 09:39:28 -0600
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > Tom St Denis wrote:
> > >
> > > In article <[EMAIL PROTECTED]>,
> > > Anthony Stephen Szopa <[EMAIL PROTECTED]> 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
> > > >
> > > > goto the Downloads Currently Available web page.
> > > > scroll to the bottom of the page.
> > > >
> > > > Click on the blue anchor tag: CiphileXOR_10.zip (155kb)
> > >
> > > How on earth did you make such a simple program take 155kb?
> > >
> > > Tom
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> >
> > Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
> > Software
> >
> > This updated XOR software utility Version 1.1 from Ciphile Software
> > now allows for the two input files AND the output file to each be
> > in a different directory if the user chooses.
> >
> > http://www.ciphile.com
> >
> > go to the Downloads Currently Available web page.
> > scroll to the bottom of the page.
> >
> > Click on the blue anchor tag: CiphileXOR_11.zip (156kb)
>
> Why didn't you answer my question?
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
The really 'neat'? thing about this program is it is GROWING between
versions, and not shrinking. This program even with the trash that windows
forces you to add is way too large unless you either have embeded images in
the file, or some other code is taging along.
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Tue, 07 Nov 2000 15:52:23 -0000
<8u58vu$bpe$[EMAIL PROTECTED]> divulged:
>How on earth did you make such a simple program take 155kb?
ms windows + borland windowing and gui crapolla.
--
okay, have a sig then
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Give it up?
Date: 7 Nov 2000 16:11:25 GMT
[EMAIL PROTECTED] (James Felling) wrote in
<[EMAIL PROTECTED]>:
>
>
>Tim Tyler wrote:
>
>> James Felling <[EMAIL PROTECTED]> wrote:
>>
>> : Agreed with reservations here. There are benefits to a
>> : 1-1(bijective) compressor vs. the alternative, however the most
>> : important crireria are how effectively it compresses the data, and
>> : how 'artifact' free it is. After choosing on that basis, I'd take a
>> : bijective method vs a non-bijective method.
>>
>> : Reasoning.
>>
>> [...]
>>
>> In principle, bijective methods allow smaller file sizes - but in
>> practice the technique is relatively new, and imposes an additional
>> constraint on the author of the compression program - so compression
>> ratios are not yet as good as they could be.
>> --
>> __________ http://alife.co.uk/ http://mandala.co.uk/
>> |im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
>
>I realized upon a reread that it could be construed that I favor
>bijective compressors vs. conventional compressors for the reasons
>given. In actuallity what I was saying is that those criteria are how I
>judge compressors ( freedom from artifacts and compressive efficiency)
>assuming that the bijective method was equivalent to the conventional
>method on that score then I would chose the bijective because of reasons
>1-3. Since the situation at present is that in most cases bijective
>compressors do not match up to conventional compressors on my two
>primary criteria, I use conventional compressors for almost all of my
>compression needs.
>
Actaully this is rapidly changing. PKZIP was a standard Matts BICOM
bets it in standard test files. Which current compressor do you
commonly use that is so great and how does it compare to Matts BICOM
for the files you tend to compress.
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:
------------------------------
Date: Tue, 07 Nov 2000 11:50:07 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Guy Macon wrote:
> 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...
>
> ;)
Hey! Microsoft(R) software doesn't have bugs, it has features.
Didn't you see the part in the FM about the User Blood Pressure
Maintenance feature?
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Tue, 07 Nov 2000 16:45:13 GMT
David Schwartz wrote:
>Let me give you an example. I have an input stream which is truly
>random but highly biased. Say one bit in a thousand is a '0' and the
>rest are all '1's. This stream is guessable in the sense that if you
>guess that a given bit is a '1', you'll be read 99.9% of the time.
>
>Now I take 1Mb of data from this stream and run a SHA1 on it. You
>couldn't guess a single bit in the output of that hash with a
>probability any better than half.
Agreed. But it is of more practical interest in the real world to
obtain the entire 160 bits than to obtain just one. And biases in the
input do make this easier to accomplish.
To make illustration easier, let's take 160 bits from the input stream
(same size as the output of SHA-1). An informed attacker would start
guessing with all bits = 1. Then he would try all the possibilities
with a single bit = 0. Then he would try all the possibilities with
two bits = 0. etc. He would expect to find the actual input value in
FAR FAR less than half of 2^160 attempts. Finding the input is the
easiest way to find the output.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Brute force against DES
Date: Tue, 7 Nov 2000 16:12:37 GMT
Dan Oetting wrote:
> Even when using a hardware DES cracker, a grey code search order will
> reduce the number of bits changing state and so reduce the power and
> cooling requirements.
Only by a negligible amount compared to the total computation.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Brute force against DES
Date: Tue, 7 Nov 2000 16:09:11 GMT
Sundial Services wrote:
> And it was actually a pretty good demonstration of just
> how strong the DES algorithm actually is.)
More a demonstration of the poor state of public cryptanalysis.
------------------------------
From: Stas Busygin <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: A new paper claiming P=NP
Date: Tue, 07 Nov 2000 20:08:47 +0200
Hi Daniele!
Tha paper is already peer-reviewed, and you may find now the review
at the same page:
http://www.busygin.dp.ua/clipat.html
http://www.geocities.com/st_busygin/clipat.html (mirror)
The vertex-saturation is correct and you may download a code
implementing it. The number of antipaths to be considered is not
more than the number of vertices in a given graph (as we consider
only those preceding all others containing a current vertex).
A detailed discussion on the paper may be found in theory-edge
list:
http://www.egroups.com/group/theory-edge
Best wishes,
Stas Busygin
email: [EMAIL PROTECTED]
WWW: http://www.busygin.dp.ua
Daniele Degiorgi wrote:
>
> 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.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Tue, 07 Nov 2000 18:06:29 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (those who know me have no need of my
name) wrote:
> <8u58vu$bpe$[EMAIL PROTECTED]> divulged:
> >How on earth did you make such a simple program take 155kb?
>
> ms windows + borland windowing and gui crapolla.
Well using CYGWIN or LCCWIN32 a similar program would take about 5kb...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: MORE THAN FULLY BIJECTIVE !
Date: Tue, 07 Nov 2000 18:07:32 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> 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.
Using CBC with a fixed IV is not particularly a good idea.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 07 Nov 2000 18:16:57 +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
Andre van Straaten wrote:
>
> In sci.crypt Richard Heathfield <[EMAIL PROTECTED]> wrote:
> > [alt.freespeech snipped from crosspost - my news server hates free
> > speech]
>
<snip>
> > [...] 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).
<snip>
>
> If you go to "Instructions" there is on the bottom a short sentence that
> the process will stop when the end of the shortest file is reached.
<grin> You don't think I'd actually run that program, do you?!?!?
<snip>
>
> BTW: I couldn't find that NG "alt.crypto.sources". Even on Deja.com I
> could find it.
My mistake. news:alt.sources.crypto is correct. (The code's there now.)
--
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, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: [newbie] Is PGP 7.0 hash extension secure?
Date: 7 Nov 2000 19:08:19 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
John Myre wrote:
>> 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.
>
>What sort of reasons?
Because the internal chaining value is just 160 bits wide, and because
SHA1 was only designed for 160 bit strength.
There has been an instance where such "doubled" hash functions have been
broken with not too much more effort than their "single" version, if I
recall correctly (I think it was Hans Dobbertin's work).
------------------------------
** 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
******************************
