Cryptography-Digest Digest #396, Volume #13 Wed, 27 Dec 00 23:13:01 EST
Contents:
Re: PRNG ("Cristiano")
___MIPS rating of a Pentium II-400 MHz (kctang)
"Content Protection for Recordable Media" (David Hopwood)
Re: MD5 and hash127 questions (David Hopwood)
Re: Merry Christmas (Jonathan Lundell)
Re: What's better CAST in PGP or Blowfish 128bit? (Darryl Wagoner - WA1GON)
Re: Newbie (Darryl Wagoner - WA1GON)
Re: ___speak something fair (kctang)
Re: ___ MIRACL 4.43 (kctang)
Re: ___MIPS rating of a Pentium II-400 MHz (Bob Silverman)
Re: ___MIPS rating of a Pentium II-400 MHz (David Schwartz)
Quick CRT question: (Benjamin Goldberg)
----------------------------------------------------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: Re: PRNG
Date: Thu, 28 Dec 2000 00:20:08 +0100
> Could you say something about your experience with the
> NIST tests? Is the package user-friendly? Could you give
> some idea of how well your generator passes the tests?
I have adapted and optimized the NIST test according to my demands, for
which I could not tell much respect to the original version.
I could tell that the NIST test has helped me greatly for build the
transition function of my "strange" generator (that I have called QVC).
QVC is still in construction (the version that I have posted has already
varied slightly), for which before subject it to an endless series of test I
am me limited to verify that the distribution of the numbers to 32 bits is
uniform (with the test of Kolmogorov-Smirnov) and that the p-values gotten
from the NIST test are evenly distributed and within acceptable limits (for
example 0.001÷0,999).
This requires greatly time also because of the 32 values that it could take
on the variable QVC_ROL.
> BTW, your generator is commonly termed (true) RNG, since
> PRNG is understood by many to be a deterministic generator.
> There used to be experts who commented on generators
> based upon physical randomness. Perhaps they are currently
> on vacation.
I hope in their answer when they return from the vacations. :-)
Meanwhile thank you for yours.
Cristiano
------------------------------
From: kctang <[EMAIL PROTECTED]>
Subject: ___MIPS rating of a Pentium II-400 MHz
Date: Thu, 28 Dec 2000 10:03:14 +0800
Dear Forum,
(Excuse me! I posted this news to intel-xxxx newsgroups before but
received no reply yet.)
What is the MIPS rating of a Pentium II-400 MHz?
In fact, I am looking for the MIPS ratings of _VARIOUS_
Pentium-II, III or even AMDK7.
Where can I find such information?
Thanks, kctang
------------------------------
Date: Thu, 28 Dec 2000 02:00:13 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: "Content Protection for Recordable Media"
=====BEGIN PGP SIGNED MESSAGE=====
This has to be stamped on at least as hard as the PIII processor ID
was (it is actually a *much* more disruptive and dangerous misfeature).
http://www.theregister.co.uk/content/2/15620.html
Stealth plan puts copy protection into every hard drive
By: Andrew Orlowski in San Francisco
Posted: 20/12/2000 at 18:54 GMT
Hastening a rapid demise for the free copying of digital media, the next
generation of hard disks is likely to come with copyright protection
countermeasures built in.
Technical committees of NCTIS, the ANSI-blessed standards body, have been
discussing the incorporation of content protection currently used for
removable media into industry-standard ATA drives, using proprietary
technology originating from the 4C Entity. They're the people who brought
you CSS2: IBM, Toshiba Intel and Matsushita.
The scheme envisaged brands each drive with a unique identifier at
manufacturing time.
The proposals are already at an advanced stage: three drafts have already
been discussed for incorporating CPRM (Content Protection for Recordable
Media) into the ATA specification by the NCTIS T.13 committee. The
committee next meets in February. If, as expected, the CPRM extensions
become part of the ATA specification, copyright protection will be in
every industry-standard hard disk by next summer, according to IBM.
However, what's likely to create a firestorm of industry protest is that
the proposed mechanism introduces problems to moving data between
compliant and non-compliant hard drives. Modifications to existing backup
programs, imaging software, RAID arrays and logical volume managers will
be required to cope with the new drives, The Register has discovered.
The ramifications are enormous. Although the benefit to producers is
great - bringing the holy grail of secure content one step closer - the
costs to consumers will be significant. For example, corporate IT
departments will be unable to mix compliant and non-compliant ATA drives
as they try to enforce uniform back up policies, we've discovered.
Restoring personal backups to a different physical drive - a common
enough occurrence when a disk has failed - will require authentication
with a central server. Imaging software used by OEMs and large
corporates to distribute one-to-many disk images will also need to be
modified.
And the move casts a shadow over some of the hottest emerging business
models: the network attached storage industry, which relies on
virtualising media pools, the digital video recorder market currently
led by TiVo and Replay, and the nascent peer-to-peer model all face
technical disruption.
How it works
Today, CPRM is implemented on DVD and removable SD disks. But the SCSI
and ATA/ATAPI proposals incorporate an extension of the scheme to allow
the encryption to be used on hard drives, in addition to removable
drives and ATAPI devices such as CD-ROMs and DVD drives.
The proposal makes use of around a megabyte of read-only storage on each
hard drive that isn't usually accessed by the end user for a "Media Key
Block". According to research scientist Jeffrey Lotspiech of IBM's
Almaden Research Lab, this is a matrix of 16 columns and some 3000 rows.
A static "Media Unique Key" in a separate, hidden area of the drive,
identifies the individual drive. Making use of broadcast encryption and
one way key algorithms, would-be hackers face a daunting number of keys
to break. CPRM adds new commands into the ATA specification.
But because the system makes use of the physical location on the device
of the encrypted item, software designed for non-compliant drives will
break in some circumstance when encrypted data files are moved.
"It requires both drives to be compliant when data is to move from one
disk to another," says Lotspiech. "And a compliant application to get
all that data to the new drive". So a hard drive containing small
individual containing non-copyable files of say, Gartner reports, will
essentially be unrestorable using existing backup programs.
Similar problems arise with RAID arrays using IDE disks, acknowledges
IBM. "This may help IT managers when auditing for copyright compliance,"
suggests IBM spokesman Mike Ross.
However the decision to make an organisation CPRM compliant. Free
copying is no longer an option:-
"It's not up to us to determine or guess what the content provider might
permit," says Ross. "Nothing will handcuff proper backup and restoring
provided the content provider permits it. Some may not permit it - but
what will the customers reaction be then?"
Well, quite. Clearly key management becomes an urgent priority when
CPRM-aware drives are introduced next year, as CPRM-aware content will
surely follow. The decision to go with CPRM in an organisation is also
an all or nothing proposition - it can't be introduced gradually.
But for home users, the party's over. CRPM paves the way for
CPRM-compliant audio CDs, and the free exchange of digital recordings
will be limited to non-CPRM media.
The Register understands there is fierce opposition to the plan from
Microsoft and its OEM customers. Generating hundreds of thousands of
images each week, the PC industry relies on data going from one master
to many reliably and smoothly. Imaging programs face the same problem as
restore software: the target disk isn't the same as the originator disk.
Microsoft Redmond already has put in a counter-proposal that eschews
low-level hardware calls.
Where were you when they copy-protected the hardware, Daddy?
The intellectual property is owned by the 4C Entity, and administered by
License Management International, LLC - a limited liability company
based in Morgan Hill, California. Company founder John Hoy told The
Register that "LMI,LC holds no intellectual property. Entities are
granted a master license."
Per-device royalties are payable to LLI,LC. License fees of between 2c
and 17c have been mooted for each device, according to documents
circulated to the T.13 group. 5c is the current rate for a DVD device.
Three possible paths lie ahead. CPRM may be bounced out of the T.x
committees. Or manufacturers may choose not to implement it, and opt for
an incomplete ATA or SCSI specification. This is deemed unlikely. Or
thirdly, manufacturers may choose to implement the new command set, but
not activate it. Although it hardly has a prominent media profile - yet
- CPRM in hardware is the most comprehensive mechanism for enforcing
rights protection the industry has seen, and is likely to be viewed by
content producers as a magic bullet. Its progress depends on whether
its proponents can overcome industry and consumer opposition. Which
might be brewing right about ... now.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOkqaUjkCAxeYt5gVAQFd4Af/dXeGGojvOa7iR+HIjTbg6gx5wetvgk+O
MvkKRsECWQUt4K36YJyggWbeZT1OKPbfkKQszQ2nb+EKnajmiJhgsUm88bSHIN7o
HqxEHVKwcCFMa0Pcp0v/Iu0yx3nMQenVXV0vy795Jl6tDXWKiBqGbuqTGQZwvScW
EMwbYWUIbECWX1Yfzvy93XVuwOF3CmyojVu+FJanj7DAKsX7eEosum5tRTGj793A
UMdb7lr7fuHC1ZvSSeXVHZ0QfngLeSfShPeIrDteHAx2RTRveyEiQYMGYH5+LmTB
4P0ls421FDNxip5ygoI5XCQlTtCQAtks+GCQ5x9D25rqi4vfdBO/Hw==
=9ul+
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 28 Dec 2000 02:00:33 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: MD5 and hash127 questions
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> And what about this:
> > 2. Some oppinions about Mr. D.J.Bernstein's hash127 and sigs packages.
> > Can I make ASCII armored ciphertext with them?
Just apply base64 encoding to the output.
> Can hash127 be good MD5 alternative?
hash127 is a MAC, not a hash function. It could be a good alternative
in some cases to HMAC-MD5 or MD5-MAC, for example.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOkqauDkCAxeYt5gVAQFUYwf+N6BrJxv00PKypsDuZWnXWeWMVq3auJm1
5zSjAZOYzi6AH2zpUebyVCYYiZsDEr2QhHm4ap4O8aDXvxT2ZzSSM4bxCYizHkD0
DOu/4zD+aXIS9CA9iv19BbzJaU2xzMWq10ZXoVbTkcctkr+xZrdeWAXz9M3c/kOo
YG802d0WqsjDPbjh1SO/VmGArdex8q1B8a4m4oJKxPeE1Q2JbNXez/0c/T2U6GkK
VaGrHRHoQTjR+VzPXvwx8kpjeiFqv8MNiD16zJaBRIecNlWOg0eUPdUnJkSZeJVF
h3yXRji0CkRiJOkYrGyQO3dsZYoREgErvnWrAZp2TwB9BKxWMDOrZQ==
=jW1D
=====END PGP SIGNATURE=====
------------------------------
From: Jonathan Lundell <[EMAIL PROTECTED]>
Subject: Re: Merry Christmas
Date: Wed, 27 Dec 2000 18:26:12 -0800
In article <926tnf$q4g$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> wrote:
> That being said, happy holidays!
> (and a crypto question: what does Santa use to keep his list of
> "naughty" and "nice" children private? how does he look up a kid in the
> database?)
He does check it twice, a sort of automatic recount, I guess.
--
/Jonathan Lundell.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Darryl Wagoner - WA1GON)
Subject: Re: What's better CAST in PGP or Blowfish 128bit?
Date: Thu, 28 Dec 2000 02:40:45 -0000
[EMAIL PROTECTED] (Tom St Denis) wrote in <90tp0u$nko$[EMAIL PROTECTED]>:
>I would trust a "secure application" written by a real cryptographer.
>Just because "heart transplants" exist doesn't mean a IT specialist can
>perform them right?
So mean if a good software engineer that isn't a cryptographer
can't be trusted to create a secure application? This is type
of attitudes that creates the mystique that this is a black
art.
-darryl
------------------------------
From: [EMAIL PROTECTED] (Darryl Wagoner - WA1GON)
Subject: Re: Newbie
Date: Thu, 28 Dec 2000 03:12:08 -0000
[EMAIL PROTECTED] (Michael) wrote in
<iffW5.84970$[EMAIL PROTECTED]>:
>I am confused. Isn't it paramount to keep the algorithm secret?
Security thur obscurely gives you a false sense of security.
This is why Linux/Unix is such a security system. The sources
has been looked at by many eyes. That is why AES was publish
for peer review. Any security system has to be secure even if
the complete source code is disclosed.
-darryl WA1GON
------------------------------
From: kctang <[EMAIL PROTECTED]>
Subject: Re: ___speak something fair
Date: Thu, 28 Dec 2000 11:10:08 +0800
==============FC3506E53A809611FE6203F9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Robert Harley wrote:
>Stick to GF(p) and GF(2^n) with polynomial bases. Normal bases are
>slow. GF(p^n) may not be secure.
I am wondering how slow ONB is.
That would *DEPEND* ON the existing tricks and programming skills
used.
So much so that if one simply uses the standard polynomial
shift-and-add, and standard polynomial division for GF(2^n)
multiply, using polynomial bases over GF(2^n) for field
multiplications would be SLOW. But one CANNOT CONCLUDE that
polynomial bases are slow.
For EC multiplications performance comparison, it is obvious that
*NOT ONLY* the type of the finite field bases should be reported,
but the
o method for field multiplications,
o method for field inverses,
o method for "exponentiations",
o or method for sum, double of points,
should also be explicitly stated.
By the way are there any (not naive) results of EC multiplications
using normal bases have ever been reported?
>Who needs dedicated hardware with software this fast? =:^)
Maybe on a embedded device with a very small computing power.
Another reason is that many people simply DO NOT KNOW WHAT TO DO
even though they believe performance can be drastically improved
with better methods, and of course with more time in exercising
their brains. What they can do is to run the program with a better
computer, which is the hardware.
The same situation did occur to me. I wrote an e-mail to Mike Scott
in 1999 and told him: "MIRACL has become huge software that one
can't find the head nor tail despite that the source codes of MIRACL
are freely provided."
Thanks, kctang
p.s. I have learned ONB ECC by self-practicing with a book and
maybe can provide some results soon. This should not be a naive
result.
==============FC3506E53A809611FE6203F9
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Robert Harley wrote:
<p>>Stick to GF(p) and GF(2^n) with polynomial bases. Normal bases
are
<br>>slow. GF(p^n) may not be secure.<tt></tt>
<p><tt>I am wondering how slow ONB is.</tt><tt></tt>
<p><tt>That would *DEPEND* ON the existing tricks and programming skills</tt>
<br><tt>used.</tt><tt></tt>
<p><tt>So much so that if one simply uses the standard polynomial</tt>
<br><tt>shift-and-add, and standard polynomial division for GF(2^n)</tt>
<br><tt>multiply, using polynomial bases over GF(2^n) for field</tt>
<br><tt>multiplications would be SLOW. But one CANNOT CONCLUDE that</tt>
<br><tt>polynomial bases are slow.</tt><tt></tt>
<p><tt>For EC multiplications performance comparison, it is obvious that</tt>
<br><tt>*NOT ONLY* the type of the finite field bases should be reported,</tt>
<br><tt>but the</tt>
<br><tt> o method for field multiplications,</tt>
<br><tt> o method for field inverses,</tt>
<br><tt> o method for "exponentiations",</tt>
<br><tt> o or method for sum, double of points,</tt>
<br><tt>should also be explicitly stated.</tt><tt></tt>
<p><tt>By the way are there any (not naive) results of EC multiplications</tt>
<br><tt>using normal bases have ever been reported?</tt>
<br><tt></tt> <tt></tt>
<p><tt>>Who needs dedicated hardware with software this fast? =:^)</tt><tt></tt>
<p><tt>Maybe on a embedded device with a very small computing power.</tt><tt></tt>
<p><tt>Another reason is that many people simply DO NOT KNOW WHAT TO DO</tt>
<br><tt>even though they believe performance can be drastically improved</tt>
<br><tt>with better methods, and of course with more time in exercising</tt>
<br><tt>their brains. What they can do is to run the program with a better</tt>
<br><tt>computer, which is the hardware.</tt><tt></tt>
<p><tt>The same situation did occur to me. I wrote an e-mail to Mike Scott</tt>
<br><tt>in 1999 and told him: "MIRACL has become huge software that one</tt>
<br><tt>can't find the head nor tail despite that the source codes of MIRACL</tt>
<br><tt>are freely provided."</tt><tt></tt>
<p><tt>Thanks, kctang</tt><tt></tt>
<p><tt>p.s. I have learned ONB ECC by self-practicing with a book
and</tt>
<br><tt>maybe can provide some results soon. This should not be a naive</tt>
<br><tt>result.</tt>
<br><tt></tt>
<br><tt></tt> </html>
==============FC3506E53A809611FE6203F9==
------------------------------
From: kctang <[EMAIL PROTECTED]>
Subject: Re: ___ MIRACL 4.43
Date: Thu, 28 Dec 2000 11:21:43 +0800
==============E1BEFEFF10140A8908E21296
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Michael Scott wrote:
> Have a look at the paper by Hankerson et al "Software Implementation of
> Elliptic Curve Cryptography over Binary Fields" to be found at
>
> http://cacr.uwaterloo.ca/tech_reports.html
>
> Optimising the software for a particular bit-length of GF(2^m) curve, and
> unrolling all the loops, certainly helps a lot. However there seems to be a
> lot of fundemental disagreement as to the fastest way to implement. Some say
> Affine co-ordinates are faster, others projective. Perhaps point-halving is
> the way to go? Some say yes, others no. Karatsuba??
>
> Maybe we need a competition...
MIRACL 4.43 see http://indigo.ie/~mscott/
===========
Platform
========
450MHz Pentium III system, Compiled with Microsoft VC++ Version 5,
with standard /O2 compiler optimisation. Note that this is for the
standard version of MIRACL, with no special optimisations. MIRACL -
32 bit version No special optimizations NOTE: No
optimizations/assembly language apply to GF(2^m) Elliptic Curves
The performance of Elliptic Curve multiplications over GF(2^m)
==============================================================
bit ER (Elliptic Curve point multiplication r.P)
--- -------------------------------------------
163 bit 733 iterations 13.65 ms per iteration
233 bit 443 iterations 22.58 ms per iteration
283 bit 240 iterations 41.69 ms per iteration
Would Dr. Mike Scott please drop me a hint on the following
questions?
o the type of the finite field bases used,
o method for field multiplications, any special tricks,
o method for field inverses, any special tricks,
o method for "exponentiations", NAF or ...
o method for sum, double of points, affine or projective?
Thanks, kctang
==============E1BEFEFF10140A8908E21296
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Michael Scott wrote:
<blockquote TYPE=CITE>Have a look at the paper by Hankerson et al "Software
Implementation of
<br>Elliptic Curve Cryptography over Binary Fields" to be found
at
<p><a
href="http://cacr.uwaterloo.ca/tech_reports.html">http://cacr.uwaterloo.ca/tech_reports.html</a>
<p>Optimising the software for a particular bit-length of GF(2^m) curve,
and
<br>unrolling all the loops, certainly helps a lot. However there seems
to be a
<br>lot of fundemental disagreement as to the fastest way to implement.
Some say
<br>Affine co-ordinates are faster, others projective. Perhaps point-halving
is
<br>the way to go? Some say yes, others no. Karatsuba??
<p>Maybe we need a competition...</blockquote>
<tt>MIRACL 4.43 see <A
HREF="http://indigo.ie/~mscott/">http://indigo.ie/~mscott/</A></tt>
<br><tt>-----------</tt><tt></tt>
<p><tt>Platform</tt>
<br><tt>--------</tt>
<br><tt>450MHz Pentium III system, Compiled with Microsoft VC++ Version
5,</tt>
<br><tt>with standard /O2 compiler optimisation. Note that this is for
the</tt>
<br><tt>standard version of MIRACL, with no special optimisations. MIRACL
-</tt>
<br><tt>32 bit version No special optimizations NOTE: No</tt>
<br><tt>optimizations/assembly language apply to GF(2^m) Elliptic Curves</tt><tt></tt>
<p><tt>The performance of Elliptic Curve multiplications over GF(2^m)</tt>
<br><tt>--------------------------------------------------------------</tt><tt></tt>
<p><tt>bit ER (Elliptic
Curve point multiplication r.P)</tt>
<br><tt>---
-------------------------------------------</tt>
<br><tt>163 bit 733
iterations
13.65 ms per iteration</tt>
<br><tt>233 bit 443
iterations
22.58 ms per iteration</tt>
<br><tt>283 bit 240
iterations
41.69 ms per iteration</tt>
<br><tt></tt> <tt></tt>
<p><tt>Would Dr. Mike Scott please drop me a hint on the following</tt>
<br><tt>questions?</tt><tt></tt>
<p><tt> o the type of the finite field bases used,</tt>
<br><tt> o method for field multiplications, any special tricks,</tt>
<br><tt> o method for field inverses, any special tricks,</tt>
<br><tt> o method for "exponentiations", NAF or ...</tt>
<br><tt> o method for sum, double of points, affine or
projective?</tt><tt></tt>
<p><tt>Thanks, kctang</tt>
<br><tt></tt> </html>
==============E1BEFEFF10140A8908E21296==
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: ___MIPS rating of a Pentium II-400 MHz
Date: Thu, 28 Dec 2000 03:15:12 GMT
In article <[EMAIL PROTECTED]>,
kctang <[EMAIL PROTECTED]> wrote:
> What is the MIPS rating of a Pentium II-400 MHz?
There isn't one. Anyone who believes they have such a number
is deceiving himself.
>
> In fact, I am looking for the MIPS ratings of _VARIOUS_
> Pentium-II, III or even AMDK7.
See:
R. Silverman
The Mythical MIPS Year
IEEE Computer, Aug 1999
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: ___MIPS rating of a Pentium II-400 MHz
Date: Wed, 27 Dec 2000 19:49:41 -0800
Bob Silverman wrote:
> In article <[EMAIL PROTECTED]>,
> kctang <[EMAIL PROTECTED]> wrote:
> > What is the MIPS rating of a Pentium II-400 MHz?
> There isn't one. Anyone who believes they have such a number
> is deceiving himself.
Sure there is, you just have to remember what it means though.
Meaningless Information to Promote Sales.
DS
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Quick CRT question:
Date: Thu, 28 Dec 2000 03:57:59 GMT
Does anyone know if it's possible to use CRT in less than P(N^3) time,
where N is the number of (modulo,remainder) tuples?
Assume all modulo are irreducible GF(2)[x] polynomials of the exact same
order, and assume that we don't have to check for duplicates.
Or, equivilantly, all modulo are prime (or at least relatively prime)
integers, and all have the exact same number of bits.
--
Power interrupts. Uninterruptable power interrupts absolutely.
[Stolen from Vincent Seifert's web page]
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
