Cryptography-Digest Digest #454, Volume #12 Tue, 15 Aug 00 22:13:01 EDT
Contents:
copyright on old papers (was Re: 1-time pad is not secure...) (Eric Smith)
Re: Looking for a DES or RSA chip with write-only key. (Paul Rubin)
Re: Best Enigma Book (Paul Rubin)
Quick Question ("Steven Knight")
Re: OTP using BBS generator? ("Trevor L. Jackson, III")
Re: BBS agreement? ("Trevor L. Jackson, III")
Test (Future Beacon)
Re: Quick Question (Merklo Iyan)
ECC Implementation (Charles Lucas)
Re: Quick Question (wtshaw)
Re: Not really random numbers (Anthony Stephen Szopa)
Re: 215 Hz five-qubit quantum processor ([EMAIL PROTECTED])
Re: OTP using BBS generator? (John Savard)
----------------------------------------------------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Subject: copyright on old papers (was Re: 1-time pad is not secure...)
Date: 15 Aug 2000 15:11:43 -0700
"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
> I don't think in 1970 an author had automatic copyright.
> I know I submitted my 1977 Master's thesis through
> appropriate channels to establish copyright for it.
> I seem to recall that it was around that time that the
> rules changed.
I think the change happened in 1986 when the US ratified
the Berne Convention.
Before that time, a work created or distributed without
a copyright notice was not copyrighted. There were
very limited exceptions made for accidental omission,
provided that the copyright owner made an effort to
correct the omission (on works already distributed).
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Looking for a DES or RSA chip with write-only key.
Date: 15 Aug 2000 22:25:18 GMT
In article <[EMAIL PROTECTED]>,
Sniggerfardimungus <ronb.cc@usu@edu> wrote:
>I'm looking for a DES or RSA chip with one unique quality - I want to be able
>to burn the key into the thing and have it permanant and non-readable... in
>some physical fashion, the key on the chip needs to be inaccessible. Is there
>any IC out there that does this, or am I going to have to go to the drawing
>boards on this one?
There are tons of products both at the chip and module level that do
this kind of stuff. Why don't you say what your requirements are
(speed, cost, security, etc.) if you want more specific
recommendations. If you want something slow and cheap with reasonable
security, your best bet is to use a smart card chip. If you want
something fast and highly secure, try something like an IBM 4758
secure coprocessor. And so forth.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Best Enigma Book
Date: 15 Aug 2000 22:26:56 GMT
In article <8nbste$29k$[EMAIL PROTECTED]>,
David C. Barber <[EMAIL PROTECTED]> wrote:
>What is the current best book on Enigma?
>
>It would be nice if it is still in print. :^)
My favorite is "Enigma" by W. Koczacuk but depending on what you're
looking for, others might be better for you.
------------------------------
From: "Steven Knight" <[EMAIL PROTECTED]>
Subject: Quick Question
Date: Tue, 15 Aug 2000 23:32:42 +0100
I know encryption uses algorithms but what are they?
And can anyone give me a SIMPLE example of one.
Forever yours
Steven Knight
------------------------------
Date: Tue, 15 Aug 2000 18:34:08 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Doug Kuhlman wrote:
> Terry Ritter wrote:
> >
> > On Thu, 10 Aug 2000 13:51:58 -0500, in
> > <[EMAIL PROTECTED]>, in sci.crypt Doug Kuhlman
> > <[EMAIL PROTECTED]> wrote:
> >
> > >Terry Ritter wrote:
> > >>
> > ><SNIP>
> > >>
> > >> No; a "negligable probability" means that some probability remains.
> > >> And with random selection, that result will eventually occur.
> > >>
> > >You should know better than that. The probability that the sound of air
> > >coming through a naturally shaped tunnel will play the entire
> > >VeggieTales collection is non-zero, but it's not gonna happen in the
> > >lifetime of the universe. Same thing applies here.
> >
> > Sorry, but *you* should know better than that. None of this is about
> > weakness in practice, it is about falsely appearing to claim strength
> > on the basis of mathematical proof. The short-cycle weakness is a
> > theoretical weakness in the sense that it almost never occurs in
> > practice. But it is a practical weakness in the sense that the reason
> > to use BB&S in practice is to achieve the results of the theoretical
> > claim. But theoretically, if long cycle operation is not guaranteed,
> > short cycle operation will occur, and the "proven secure" system will
> > be insecure, sooner or later.
> > <SNIP>
> > Nope, that seems to be *your* problem: Possibility and probability
> > are statistical terms. If something is *possible* under random
> > selection, it eventually *will* *happen*. This concept is important
> > and you need to understand it. The same concept occurs in computer
> > programming.
> >
> >
> First you argue that you're not claiming it's a weakness in practice and
> less than a page later, you're trying to claim that it will happen.
> Which is it?
> Can you pick the right atom of the Earth in the exact millisecond of the
> day? Your odds of landing on a short cycle are worse.
Can you provide some number/formulae that describe the incidence of short
cycles for a typical BBS generator?
------------------------------
Date: Tue, 15 Aug 2000 18:50:10 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: BBS agreement?
Doug Kuhlman wrote:
> Hey all! I'd like to try to bring some of the BBS discussion to some
> sort of agreed-upon conclusions. I *think* everyone has agreed to the
> following:
>
> 1. Finding a cycle (any length) in BBS allows factoring the modulus
> 2. Long cycles *do* exist with properly chosen BBS primes
>
> These two are a large part of the BBS paper.
>
> 3. Short cycles exist
> 4. The chance of landing on a short cycle is microscopic [1]
> 5. This chance is so small as to be unimportant in practice
>
> I think we have agreed to:
>
> 6. Using BBS with no cycle check gives an attacker no advantage in
> factoring
It's worth noting that the disagreement seems to hover around the issue of
whether using BBS with no cycle check gives an attacker any advantage in
recovering messages.
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Subject: Test
Date: Tue, 15 Aug 2000 19:29:33 -0400
This test is needed because my messages are not being posted and I
am not even getting a copy in my sent mail file.
I'm sorry for any inconvenience.
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Merklo Iyan)
Subject: Re: Quick Question
Date: Tue, 15 Aug 2000 23:43:45 GMT
"Steven Knight" <[EMAIL PROTECTED]> wrote:
>I know encryption uses algorithms but what are they?
An algorithm is a sort of recipe. It's a step-by-step procedure that might
be implemented differently on different computers and operating systems,
but generally gives the same result with the same input. Algorithms are not
restricted to cryptography. They are the methods that programmers use to
accomplish all sorts of tasks.
>And can anyone give me a SIMPLE example of one.
Well, you could rotate every letter of the alphabet by 13, thus resulting
in text like this:
Gur cebprqher, "Ebgngr rirel yrggre bs gur nycunorg ol 13", vf n fvzcyr
nytbevguz. Pbzchgre cebtenzf gung qb guvf jvyy qvssre va gur qrgnvyf bs
gurve vzcyvzragngvba, ohg gurl fubhyq nyy tvir gur fnzr erfhygf jvgu gur
fnzr vachg.
The procedure, "Rotate every letter of the alphabet by 13", is a simple
algorithm. Computer programs that do this will differ in the details of
their implementation, but they should all give the same results with the
same input.
--
"Merklo Iyan" is actually 0631 987452 <[EMAIL PROTECTED]>.
012345 6789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: [EMAIL PROTECTED] (Charles Lucas)
Subject: ECC Implementation
Date: 16 Aug 2000 00:34:57 GMT
Hello,
I'm looking for information from people who have had some experience
implementing elliptical encryption algorithms. I've been working on
one myself, and have a few questions:
How should you handle the "Omega" point, or is it even necessary? It
seems like if you're doing iterations of "adding" two elliptic curve
points, and then adding a point to the result, you run the risk of
adding two points that have the same X value.
Is any software available that will "multiply" an elliptic-curve point
by an integer (on the order of about 160 bits for each), so that I
could check my work?
Referencing the equation y^2 = x^3 + ax + b:
Where in the algorithm for "multiplying" an elliptic curve point by an
integer does "b" come in? The formula for doubling an elliptic curve
point uses "a", but "b" never appears to be a factor. Is it not
necessary, given that your input points take it into account?
Thank you,
-Charles
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Quick Question
Date: Tue, 15 Aug 2000 18:03:50 -0600
In article <8ncgee$cta$[EMAIL PROTECTED]>, "Steven Knight"
<[EMAIL PROTECTED]> wrote:
> I know encryption uses algorithms but what are they?
An algorithm is a relationship most often stated in source code, logical,
or mathematical terms. It helps greatly to be able to summarize if in a
text description. An algorithm that is not demonstrated may fail to
perform as described.
Cryptographic algorithms deal with the process of converting plaintext to
and from text, including use of keys.
>
Pt: And can anyone give me a SIMPLE example of one.
Ct: dnA nac enoyna evig em a ELPMIS elpmaxe fo eno.
Algorithm Description: Reverse the characters in each word.
--
Too bad from the party members point of view that Ventura has
gone, for what the Reform Party needs is a good referee and
someone who understands how to *fix* things, before hurt sets in.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Not really random numbers
Date: Tue, 15 Aug 2000 18:32:38 -0700
James Felling wrote:
>
> > <snip>
>
> >
> > >
> > > I must state this. Files of this nature can be manufactured by other PRNG's.
>They
> > > will be manufactured as quickly if not more so, and as securely, if not more so.
> May I
> > > suggest an apropriately tweaked RC4, or BBS for your use. The issue is it will
>take ~1
> > > hour of operator time to start generating good data with your mechanism, and it
>will
> > > also take more than a bit of time after that to actually generate the numbers.
>OTOH,
> > > it will take 1 minute to setup a good RC4 generator, and it will have generated a
> > > reasonable quantity of data( equivalent to your files) in under a half hour.( I
>think
> > > the fact that it takes less of MY time, and is done before OAP/OAR gets started
>is a
> > > HUGE advantage.) BBS is slower, but substantially more secure. It will
>probably take
> > > 5 minutes of my time to setup, and generate an amount of data sulficient to be
>useful
> > > in several hours. This is speed wise compeditive with your system, and is going
>to be
> > > more secure than your system in general.
> > >
> > > >
> > > >
>
> > <snip>
>
> >
> > > RC4, BBS, and all others when saved to files encrypt just as fast as your method
>-- The
> > > issue for the user is forufold
> > >
> > > 1) how much of my( the user) time do I wish to invest. (ideally as little as
>possible)
> > >
> > > 2)how much computer time do I wish to invest (ideally as little as possible)
> > >
> > > 3) how much space on my machine/ the remote machine do I want to use for this, (
> > > ideally as little as posssible)
> > >
> > > 4) How long is key data going to be lurking in an available form in my/remote
>PC. (
> > > ideally for as short a period as possible)
> > >
> > > versus RC4 you lose on all 4 points.
> > > versus BBS you lose on points 1,3,4 and cannot deliver security with an
>equivalent
> > > degree of confidence.
> > >
> > > You have a second rate stream cypher -- it is slower than most BLOCK
>algroithims. I
> > > admit that using large "random files" will give a speed enhancement, but they add
> > > secondary points of attack to your algorithim, and any other stream cypher, and
>most
> > > block cyphers can do the same trick faster.
> >
> > I think your confidence level is not warranted.
> >
> > "is going to be more secure than your system in general." This is
> > clearly over reaching.
>
> Does your system have a mathematic proof which indicates that a break of the system
>is
> equivalent to the solution of the QRP problem? Or tying a its dificulty of breaking
>to the
> same? If so then feel free to attack BBS, but for well chosen values BBS has a
>known minimum
> level of security, and cannot have "bad keys". Your system can have bad keys, and
>has no
> minimum guaranteed security level. I feel that this results in a system " more
>secure in
> general" than yours.
>
> >
> >
> > "1) how much of my( the user) time do I wish to invest. " This is
> > certainly a (modest) concern. It is answered by asking yourself how
> > much more secure is OAP-L3 than other methods.
>
> It is no more secure than any other PRNG. It is less secure than BBS( in general)
>and can
> probably compare to RC4 with a sulficient investment of operator time. OTOH RC4 is
>faster,
> takes less effort to setup properly, and is simpler to use for equivalent quality
>random
> numbers.
>
> > As you should know,
> > OAP-L3 uses no mathematical equations in generating random numbers.
>
> Really?
>
> >
> > There is no modulo operation, for instance.
>
> None by that name -- but you do out put your numbers with discarded values( I
>believe any
> value of 3*255 or higher is discarded in post processing when you are combining the
>three
> streams -- if that is not mudulo truncation what is it?
>
> > In other words, there
> > are no inherent constraints in the random number generation process.
>
> Please define "constraints" -- I think you constrain your generator in any number of
>ways --
>
> >
> > With no constraints there is no way to trivialize cracking the
> > random number generator.
>
> There are no such known ways of using such versus any other crypto grade PRNG
>
> > This may make the additional time worth
> > it. Besides, the time need be invested only once since you will be
> > able to generate more random numbers than you could ever possibly
> > need with very very little additional effort.
> >
> > "2)how much computer time do I wish to invest?" This point also
> > addresses the limited cost of using OAP-L3. You cannot simply look
> > at cost. As above you must look at what you are getting for your
> > cost. See below.
> >
> > "3) how much space on my machine/ the remote machine do I want to use
> > for this,..." This is a valid cost concern. See below.
> >
> > "4) How long is key data going to be lurking in an available form in
> > my/remote PC." This is valid security concern.
> >
> > Here is my response to the remaining concerns:
> >
> > You may be aware that OAP-L3 Version 4.1 / 4.2 is the original
> > implementation of the theory / concept. This implementation has
> > the cost concerns that you have a legitimate reason to point out.
> > And you may not be willing to incur these costs.
> >
> > My proposed implementation for Version 5.0 is available at
> > http://www.ciphile.com from the What's Ahead web page.
> >
> > Version 5.0 is explained in detail in the files available for
> > download by clicking the blue anchors located at the bottom of
> > this page: Version 5.0 Tables file and the associated Version
> > 5.0 Text file.
> >
> > Version 5.0 will not require you to generate random number files
> > beforehand. Permanent hard drive space will not be required because
> > the key / encryption data will be kept on floppy. This pretty much
> > dispels #2, #3, & #4.
> >
> > I addressed #1 initially, above.
> >
> > Depending on which variation of version 5.0 one uses, the
> > encryption time will vary.
> >
> > Here is a brief description. Full details by clicking the blue
> > anchors at the bottom of the What's Ahead web page.
> >
> > ("E" notation means that a number expressed as 5E6 = 5 x 10^6 or
> > 5,000,000.)
> >
> > With only 2920 data bytes you will be able to generate 9.2E15 random
> > numbers from 0 - 255 with a security level equivalent to 2000 bits;
>
> RC4 with a combiner
>
> with only 300 data bytes get security equivalent to 2000+ bits
>
> >
>
> >
> >
> > or with only 4600 data bytes you will be able to generate 2.3E17
> > random numbers from 0 - 255 with a security level equivalent to
> > 10,000 bits;
>
> RC4 with a combiner
>
> with only 2000 data bytes get security greater than 10000 bits
>
> >
> >
> > or with only 1,271,000 data bytes (fits on one floppy) you will be
> > able to generate 1.3E36 random numbers from 0 - 255 with a security
> > level equivalent to 100,000 bits.
>
> Imagine typing in 1271000 random characters. Sound fun to you. It sure does not
>sound fun to
> me.
>
> RC4 with a combiner
>
> with only 20000 bytes of data get security superior to 100000 bits.
>
> >
> >
> > The Version 5.0 Tables file and the associated Version 5.0 Text file
> > describe how this is done.
> >
> > You don't need to keep the key / encryption data on your computer.
> > Keep it on a floppy disk.
>
> Get the floppy stolen and copied. You still have a single point of failure which
>compromises
> the whole system, and which cannot easily be rekeyed.
>
> > Insert it when needed then remove.
> >
> > Thanks for your consideration.
>
> You just don't get it. your method is less effective, more difficult, and slower
>than other
> public domain methods. Why should it be used?
I said you are over reaching. What do you mean by less effective and
support why OAP-L3 is less effective? Are you saying it is less
secure. I say OAP-L3 is more secure because there are no inherent
constraints in the random number generation process and therefore no
constraints can be exploited to trivialize the cracking of the random
number process.
You cannot just say "less effective" in a vacuum. You must state
the proposed use for the software. What application did you have in
mind? Encrypting email messages?
I claim that the military could use OAP-L3 effectively. For
instance, the U.S. Navy could use it to encrypt communications to
the entire fleet. How many megabytes / gigabytes of data do you
suppose the entire Navy transmits to its fleet each day?
OAP-L3 is simple. And the security benefits outweigh your other
concerns which are of greatest concern in this first implementation.
They come down to generating the OTP files beforehand and storing
them. These concerns are easily dealt with.
And just because you cannot imagine using OAP-L3 effectively does
not mean that it cannot be done. You will admit you have no
interest in solving your issues with OAP-L3. So since you have
not thought about how to solve these issues for yourself, why should
anyone listen to you: someone who chooses not to think
yet make cursory superficial claims which I say again are easily
dealt with?
Why don't you just say you want to trash OAP-L3 and don't care to
support your position other than to give vague and general
statements with no specific situations.
Give us your biggest objection to OAP-L3 with a proposed use where
it would not be effective or where it would be less effective? And
how many people need this capability?
Perhaps Internet backbone service providers who wish to encrypt and
transmit terabytes of data per hour might find OAP-L3 unacceptable.
But how many users need to encrypt and transmit terabytes or even
gigabytes each hour through one server or portal?
I say again, you are overreaching to maintain your mostly untenable
and insupportable position.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
Date: 16 Aug 2000 00:53:39 GMT
>Since no one has mentioned it, the new quantum computer is being
>presented at HotChips 12. According to the program at
> http://www.hotchips.org/hotc12_tuesday.html
>first thing on Tuesday morning.
>
>I hope someone will post a summary.
>
>The article on IBM
>http://www.research.ibm.com/resources/news/20000815_quantum.html
>is flufy, but points to an exceptional good article at
>http://www.techreview.com/articles/may00/waldrop.htm
>and to HotChips.
Wow .. this technology is moving fast! In 2Q98 there were still
many physicists doubting that anyone could ever make a model that
could remain coherent for more than one or two operations at a time,
and now here's IBM in 3Q00 demo'ing a 215 Hz system!
It sounds like practical quantum computing might intersect the
domain of digital computing sooner than anyone expected 8-|
IBM's system is a one-function device, but what a function!
Finding the period of a function as a one-step calculation! It
makes me wonder how long it will be before our computers are
hybrid systems, with fast digital processors remaining at the
heart of the system, but with single-function co-processors
standing by to perform "hard" operations as needed.
It reminds me of the P/NP problems the professor would give us
in college, where he'd say "here, assume you have a conventional
computer that runs pascal, and a magic function that solves this
NP problem in P time. Write a function to solve this other NP
problem in P time by using this magic function."
Seems to me that if a quantum computer like IBM's can solve the
period of an arbitrary function in P time (indeed, in O(1) time),
then it might also be able to solve the halting problem in P time
for at least some subset of algorithms (or at least be used by a
conventional computer to solve the halting problem, a la AVG's
classroom exercises). The mind boggles at what we could do with
that.
Question -- is keeping an N+1 qubit computer coherent a *lot*
harder than keeping an N qubit computer coherent? IE, does it
get more difficult as an exponential, polymetric, linear, or some
other function of qubits, roughly speaking? Or is everyone still
scratching their heads and unable to say?
-- TTK
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: OTP using BBS generator?
Date: Wed, 16 Aug 2000 01:46:21 GMT
On 15 Aug 2000 16:54:32 GMT, [EMAIL PROTECTED] (Mark Wooding) wrote, in
part:
>Terry Ritter <[EMAIL PROTECTED]> wrote:
>> That's a wrong answer: The construction as described in BB&S first
>> guarantees that cycles of a given length must exist, and then shows
>> how to check that x0 is on such a cycle. The check is thus absolute
>> proof that a short cycle has not been selected.
>No, it only shows the cycle length for the sequence <x_i>, not the
>sequence of parity bits.
Since the BBS modulus can't be a power of two, I don't think you have
to worry about that.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
