Cryptography-Digest Digest #330, Volume #12 Tue, 1 Aug 00 17:13:00 EDT
Contents:
Re: Elliptic Curves encryption (Doug Kuhlman)
Re: C++ Plaintext To Block unsigned long (Joseph Stein)
Re: Small block ciphers (Mok-Kong Shen)
Re: PRNG cryptoanalysis (Mok-Kong Shen)
Re: Stream Ciphers (Mok-Kong Shen)
Plausible Word Generation via Trigram Statistics ("Steve Hollasch")
Re: Stream Ciphers (John Myre)
Re: Elliptic Curves encryption (Terry Ritter)
Re: Blowfish Implementation (John Myre)
Re: Sending Messages in Morse Code (Mok-Kong Shen)
Re: unbreakable code? Yes (JimD)
Re: Sending Messages in Morse Code (JimD)
Re: Encrypt string to produce a unique number (Matthew Skala)
Re: Blowfish Implementation (Daniel Leonard)
Re: Hardware based PK crypto device - University project (Paul Rubin)
----------------------------------------------------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Tue, 01 Aug 2000 13:26:12 -0500
Terry Ritter wrote:
>
> On Tue, 01 Aug 2000 09:30:22 -0500, in
> <[EMAIL PROTECTED]>, in sci.crypt Doug Kuhlman
> <[EMAIL PROTECTED]> wrote:
>
> >Terry Ritter wrote:
> >>
> >> On Mon, 31 Jul 2000 12:12:32 -0500, in
> >> <[EMAIL PROTECTED]>, in sci.crypt Mike Rosing
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >> >Terry Ritter wrote:
> >> >> Nope: Facts exist independent of belief. Convincing someone is not
> >> >> relevant to reality.
> >> >
> >> Facts need no belief, no propaganda, no agreement, no popularity.
> >> There is no vote on facts. Facts are there if you don't like them
> >> just as much as if you do. Any argument which implies correctness
> >> because many experts believe such a thing is a false argument. Facts
> >> don't care about experts or belief.
> >>
> >Please, then, give us an example of a "Fact". By your definition, no
> >such thing exists.... "1+1=2" True only because we define it that
> >way. "The Earth is a slightly squashed sphere." Sure appears that way
> >now, but maybe it exists in 4 dimensions and we can only see 3...maybe
> >the Earth really is flat and there are massive teleporters to make it
> >appear spherical.
> >
> >What is a fact?
>
> I don't care *what* a fact is, only that there *are* facts.
>
There are? Like what? Find me a fact....
> Apparently you missed the original context, which was:
> <[EMAIL PROTECTED]>:
> >>>>>[...]
> >>>>>I have an old Russian text that says "proof is our ability to convice
> >>>>>someone else we are right".
>
> If one of those facts is that a particular cipher is weak, it really
> doesn't matter who is convinced. And if we convince the world of
> something which is not a fact, that does not make it one.
>
I disagree with the Russian text. Convincing someone is completely
different from proof. Proof means that X postulates (better name than
assumptions, agreed) leads to Y conclusion...without any comment on the
truth of X postulates.
> If the issue is mathematical fact, we may be able to use some facts to
> derive additional facts. This process is called "proving," but it
> does not reach a usable "proof" of results until we have an acceptable
> basis for assuming the original facts. That basis does not exist in
> PK strength proofs.
>
Since you can never prove all your postulates, then proof as you wish it
does not exist.... What is an acceptable basis?
> >> >> I will believe a mathematical proof, if I can understand it, because I
> >> >> will have no choice. There are, however, many supposed "proofs" which
> >> >> I do not accept because they are only proofs if one accepts certain
> >> >> assumptions which I do not accept.
> >> >>
> >This is self-contradicting. *EVERY* mathematical proof is based on
> >asssumptions. Most people accept these assumptions, but some do not.
> >The Peano Postulates are the foundation of a lot of math. Other
> >branches make other assumptions. *EVERY* mathematical idea starts with
> >a series of "IF"s (some are just assumed) before reaching conclusions.
> >A mathematical proof can *NEVER* prove its assumptions.
>
> I agree that all mathematics is based upon assumptions. However, I
> assert that the sort of assumptions required by cryptographic proofs
> are not the fundamental, basic assumptions beyond which mathematics
> cannot be expected to go, but instead imply very complex logic systems
> which are glossed over by stating the needed result as an assumption.
> To use the same word, "assumption," in both cases, and then on that
> basis to assume they are equivalent, is a logic error, even for a
> mathematician.
>
Overusing a word is a common mathematical problem. I'd love solutions!
I tried using postulates for my proofs.... Certainly, assuming your
postulates are true is dangerous and that is, so some extent, what PKC
does (Course, both RSA and EC are even worse. They're not even shown to
be equivalent to factoring or to solving the ECDLP). To my knowledge,
only Blum-Blum-Schub (yes, I brought it up) is actually proven
equivalent to anything (namely, factoring). Does that mean it's hard?
I don't know. Certainly, the mathematics doesn't say so (CAN'T say
so...even NP-complete problems use various postulates). I know I can't
factor very large n and that the public crypto world can't either.
That's good enough for me. If you want more, you're welcome to look,
but I doubt you'll find it.
> >The problem arises when people assume mathematical conclusions exist
> >independent of their "IF" statements. "If 1=0 in the integers, then I
> >have a Ph.D. in computer science." This is a mathematically true
> >statement, but it says NOTHING about my degree or lack thereof in CS.
>
> How odd, then, that your are not criticizing the so-called Public Key
> "proofs of strength" yourself.
>
I've never seen anyone contend that PK is proven strong. Partial proofs
of equivalency or solving A => solving B are all that exist (to my
knowledge). However, I know that's the way things often operate. There
are holes...sometimes they're filled in as expected...sometimes they're
never filled, sometimes the expected answer is incorrect (lotsa things
were believed...one fairly famous one had its first counterexample
around 10^5^8).
At least PK has some work being done on it. Symmetric ciphers exist in
a mathematical vacuum. Sure, the work on PK doesn't prove anything
about real-life applications. Convincing someone that factoring is hard
is diplomacy/marketing, not math. Showing that breaking RSA is as hard
as factoring is a mathematical result (one not proven and probably
false, from what I understand).
> >Until you are willing to see that all mathematics is based on
> >assumptions, you will never be a mathematician.
>
> I'm not a mathematician, and I don't intend to be one. Mathematics is
> a tool used in cryptography; it is not the essence of cryptography,
> any more than it is the essence of everything else math can describe.
>
Agreed. I'd even go so far as to say the most important tool of the
encryption/decryption engines.
> But I doubt we could criticize PK proofs on a mathematical basis; the
> problem with them is not really mathematical. The problem is that the
> complex assumptions they require cannot be confirmed as fact, and so
> the mathematical results do not necessarily apply. That may not be a
> math problem, but it sure is a problem for people who take those
> results to have real meaning in cryptography, and there are many such
> people.
>
Agreed. But knowing that "breaking" BBS (for example) is equivalent to
factoring is SOMEthing. On the other hand, "breaking" Twofish means ???
I still would like you to present something to me as a fact.
Doug
------------------------------
From: [EMAIL PROTECTED] (Joseph Stein)
Subject: Re: C++ Plaintext To Block unsigned long
Reply-To: [EMAIL PROTECTED]
Date: Tue, 01 Aug 2000 19:02:21 GMT
That would give me one chunk.. How can I brake the data up into 2
so that it encrypts
and then from 2 back to 1 chunk so that it it can be casted back to a
string?
On Tue, 1 Aug 2000 11:44:30 -0700, "Joseph Ashwood" <[EMAIL PROTECTED]>
wrote:
>> That looks great but I still need to have it into the 2 unsigned long
>> chunks so that I can encrypt it? which is my goal however it is
>> accomplished
>
>Cast the pointer to a different pointer type.
> Joe
>
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Small block ciphers
Date: Tue, 01 Aug 2000 21:15:33 +0200
Mack wrote:
> Let see an actual example.
> This is rather long and uses ANF.
> It is rather simple but it shows the principle.
>
> This can be expanded to any number of bits T.
> B = bits of block size
> K = bits of key size.
> T = B + K
>
> The number of terms is equal to 2^T.
> The number of equations is B
> Obviously this is impractical for large T.
Isn't it that one can have B equations where on the left sides one
has the known values of the output bits , while on the left side one
has functions involving the K unknown values of the key bits and the
B known values of the input bits? If yes, then we have B equations
and K unknowns. Or I am missing something here?
> It also illustrates how a non-linear term can
> be assumed to be a variable. It shows
> how some pairs are better than others.
The point is whether, on introducing a non-linear term as a
variable, one takes away a previously existing (simple) variable,
or one has the non-linear term as an 'additional' (new) variable.
This is essential, since, if I don't err, your argument of imfeasibility
has to do with the count of number of variables with respect to
the number of equations. To use an analogous case, the equation
x^2+x+1=0 is normally considered to have only one variable.
Do you want to regard x^2, which is non-linear, to be a variable
and thus consider the equation to be of two variables?
> Finally it shows an example of a 'cipher'
> that is weak and can be solved with
> a carefully chosen ciphertext for certain
> weak keys. Even though my 'theory'
> says that we shouldn't be able to find
> the key.
>
> To make this easy I will use a 2 bit block size.
> We will do this with a 2 bit key.
>
> ok lets say we have a table of 2 bit permutations.
> The key selects the permutation we will use.
>
> There are 24 possible permutations.
>
> 00 = 0 1 2 3
> 01 = 1 0 2 3
> 02 = 0 2 1 3
> 03 = 2 0 1 3
> 04 = 2 1 0 3
> 05 = 1 2 0 3
>
> 06 = 0 1 3 2
> 07 = 1 0 3 2
> 08 = 0 2 3 1
> 09 = 2 0 3 1
> 10 = 2 1 3 0
> 11 = 1 2 3 0
>
> 12 = 0 3 1 2
> 13 = 1 3 0 2
> 14 = 0 3 2 1
> 15 = 2 3 0 1
> 16 = 2 3 1 0
> 17 = 1 3 2 0
>
> 18 = 3 0 1 2
> 19 = 3 1 0 2
> 20 = 3 0 2 1
> 21 = 3 2 0 1
> 22 = 3 2 1 0
> 23 = 3 1 2 0
>
> with a two bit key we only have four permutations
> available.
>
> Selected at random (flipping coins)
> Starting over if first two flips are both head (one).
>
> 0 = 22 = 3 2 1 0
> 1 = 03 = 2 0 1 3
> 2 = 11 = 1 2 3 0
> 3 = 21 = 3 2 0 1
>
> We can then write out the equations
>
> input bits AB
> key bits CD
> output bits EF
>
> A^B is A XOR B (lowest precedent)
> AB is A AND B (highest precedent)
>
> 0 = 3 2 1 0
> E = 1^A
> F = 1^B
>
> 1 = 2 0 1 3
> E = 1^A^B
> F = A
>
> 2 = 1 2 3 0
> E = A^B
> F = 1^B
>
> 3 = 3 2 0 1
> E = 1^A
> F = 1^A^B
>
> The final equations of E and F are (I think this is correct it was done by
> hand)
>
> E = (1^C^D^CD)(1^A) ^ (D^CD)(1^A^B) ^ (C^CD)(A^B) ^ CD(1^A)
> E = (1^C^D)(1^A) ^ (D^CD) ^ (D^CD)(A^B) ^ (C^CD)(A^B)
> E = 1^C^D ^ (1^C^D)A ^ D^CD ^ (C^D)(A^B)
> E = 1^C^CD ^ A^AC^AD ^ (C^D)A ^ (C^D)B
> E = 1^C^CD ^ BC ^BD ^A
>
> F = (1^C^D^CD)(1^B) ^ (D^CD)A ^ (C^CD)(1^B) ^ CD(1^A^B)
> F = (1^D)(1^B) ^ AD ^ CD ^ BCD
> F = 1 ^ D ^ B ^ BD ^ AD ^ CD ^ BCD
>
> The input selected at random (coin flipping) is 0
> The key is 3
> The output will be 3
>
> This gives
>
> E=1 = 1^C^CD
> F=1 = 1^D^CD
>
> Note that in this step we can assume G=CD giving
>
> E=1 = 1^C^G
> F=1 = 1^D^G
>
> which yeilds C=D
> since the system is degenerate we cannot do better with one text
> This gives us an expression of the inputs and outputs in reduced form
>
> E= 1^A
> F= 1^B^AC
>
With C=D, there are two possibilities, namely C=D=0 or C=D=1,
which correspond to the cases 0 and 3 you numbered above. These
have
E = 1^A E = 1^A
F = 1^B F = 1^A^B
as was derived above. If one has C=0, then your set of equations
immediately above should reduce to the first set and if one has
C=1, then that should reduce to the second set. I don't see that
can be the case. Is there a computing error on your part or I am
simply wrong or haven't correctly understood the matter? (Could
you please explain?) Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: PRNG cryptoanalysis
Date: Tue, 01 Aug 2000 21:43:26 +0200
Corrado Galdini wrote:
> I'd like to know if there is any site around dealing with cryptoanalysis
> of two common pseudo-random number generators known as "linear
> congruential" (maybe the easiest one around) and "linear feedback shift
> register" (or LFSR).
> I found many sites dealing with related theory and applications but none
> dealing with cryptoanalysis. :(
For such questions it is (in my experience) always advisable to
first consult standard works like AC of Schneier or HAC of
Menezes et al. to get the references and look up these in the
libraries.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Stream Ciphers
Date: Tue, 01 Aug 2000 21:43:34 +0200
Lisa Retief wrote:
> I just did a quick scan through the FAQs and couldn't find anything on
> stream ciphers. Have I missed it or does this newsgroup focus only on block
> ciphers? Are there any non-proprietry/patented stream ciphers out there?
Maybe my memory is wrong, but I think stream cipher is at least
mentioned in FAQ. We do talk about stream ciphers in this group.
Since the practice (for whatever reasons) is such that in symmetric
encryption block ciphers prevail, there is naturally more discussions
on block ciphers than stream ciphers. As to the last question, my
personal 'typical' answer is: Consult standard works like AC of
Schneier or HAC of Menezes et al.
M. K. Shen
------------------------------
From: "Steve Hollasch" <[EMAIL PROTECTED]>
Subject: Plausible Word Generation via Trigram Statistics
Date: Tue, 1 Aug 2000 12:46:15 -0700
[This post is rather off-topic, but based on cryptographic techniques
and tools. If you know of a better venue for this topic, I'd appreciate a
pointer. Thanks.]
It's a rather interesting exercise to find a plausible domain name these
days, and the rate at which squatters snatch up every plausible word is
astonishing and at times humorous (perineum.{org,net,com} are all taken!!
=^).
I've even heard rumors to the extent that folks are snooping on whois
searches and snatching up plausible queries as well (while admittedly
conspiratorial, I've had some spooky experiences that almost suggest this.)
The meat of this post is that it occurred to me that one could employ
standard English trigram statistics to generate a random stream of plausible
English words. Beyond securing easy-to-remember and meaningless domain
names, it would be a cool product name generator as well.
Does such a tool exist already? If not, is there a source of English
trigram statistics (plus any other statistical data I've not yet considered)
that would help me write such a tool?
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Stream Ciphers
Date: Tue, 01 Aug 2000 13:46:12 -0600
Benjamin Goldberg wrote:
<snip>
> The *shortest* cycle length is 2**40 32-bit values [that is a 2**62 bit
> cycle]
<snip>
Would you like to correct this arithmetic?
(Hint: 32 = 2^5, not 2^32)
JM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Elliptic Curves encryption
Date: Tue, 01 Aug 2000 19:58:12 GMT
On Tue, 01 Aug 2000 13:26:12 -0500, in
<[EMAIL PROTECTED]>, in sci.crypt Doug Kuhlman
<[EMAIL PROTECTED]> wrote:
>But knowing that "breaking" BBS (for example) is equivalent to
>factoring is SOMEthing.
No, it is not, and we just went through that a month ago. When the
supposed "BB&S" construction is used, there is a possibility --
admittedly very remote -- of having selected a short cycle. When that
happens, the system can be broken due to repetition of the cycle, and
that of course also allows the composite to be factored. Now, exactly
*how* has it helped us to know that the failure allowed factoring?
So "breaking" BB&S means that we have found it to be weak to the given
attack, and that -- my goodness! -- might not even overturn
mathematics as we know it.
>On the other hand, "breaking" Twofish means ???
That it is weak to the given attack. That they should have done more
testing. That they should have made a scalable cipher so their
testing could have been more rigorous. Things like that.
>I still would like you to present something to me as a fact.
How about this: That's a stupid request.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Blowfish Implementation
Date: Tue, 01 Aug 2000 13:53:10 -0600
Joseph Ashwood wrote:
<snip>
> Just tell the computer that it's a pointer to a different type, in this case
> long instead of char.
Ah, gee. Are you seriously intending to promulgate this practice
to programmers who plainly don't know any better? Or is this a
joke, and my sense of humor has malfunctioned? Not every computer
is an Intel x86.
JM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Sending Messages in Morse Code
Date: Tue, 01 Aug 2000 22:18:42 +0200
John Savard wrote:
> For all I know, the scheme I outline on
>
> http://home.ecn.ab.ca/~jsavard/crypto/mi060307.htm
>
> may be the subject of a patent somewhere...or the subject of a common
> homework problem in classes on information theory...or it might even
> have been considered once (but probably never used in practice) within
> the hallows of the NSA.
>
Do I understand correctly that you want to transform a random bit
sequence (almost uniformy distributed) into a sequence of Morse
code symbols and study the optimal transformation? (On the other
hand I read somewhere that the Morse code was designed to be
optimal for transforming normal English sentences.) I admit that
I haven't fully understood your article, hence the question: Do
you keep the set of the original Morse code symbols or do you
consider possible extensions, i.e. introducing more symbols?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (JimD)
Subject: Re: unbreakable code? Yes
Reply-To: JimD
Date: Tue, 01 Aug 2000 19:09:59 GMT
On Tue, 1 Aug 2000 00:23:55 -0400, "RecilS" <[EMAIL PROTECTED]> wrote:
>I've just finished a program that I'll be betaing soon. It involves CD
>pairs. You give one CD to a friend and keep one. They have real-random
>numbers generated from atmospheric noise, and i think you'll agree that
>650megs of key is enough to talk for quite some time and even transmit files
>using a OTP.
>
>I'll be selling the software and then extra CDPairs for a very cheap price.
>the software may be freeware for now, but we'll see.
Fine. Provided neither party ever re-uses any portion of the
key, it'll be absolutely and unconditionally secure, given
that your keys are unpredictable.
Dunno about the atmospheric noise though. How exactly do you
mean 'atmospheric'. Do you mean noise derived from sound or from
electrical/radio noise?
I probably wouldn't use it because you could well retain a copy
of my keys.
--
__________________________
Jim Dunnett.
g4rga at thersgb.net
------------------------------
From: [EMAIL PROTECTED] (JimD)
Crossposted-To: sci.math
Subject: Re: Sending Messages in Morse Code
Reply-To: JimD
Date: Tue, 01 Aug 2000 19:10:00 GMT
On Tue, 01 Aug 2000 10:32:32 GMT, [EMAIL PROTECTED] (John
Savard) wrote:
>For all I know, the scheme I outline on
>
>http://home.ecn.ab.ca/~jsavard/crypto/mi060307.htm
>
>may be the subject of a patent somewhere...or the subject of a common
>homework problem in classes on information theory...or it might even
>have been considered once (but probably never used in practice) within
>the hallows of the NSA.
>
>It addresses what technique one must use to solve a cute class of
>problems in information theory.
>
>Supposing one wants to send a message, for historical reasons, in the
>form of letters from the standard 26-letter alphabet to be transmitted
>by Morse Code.
I recall a system called 'Atbash' which encrypts binary files
to five-character groups using A-Z and 1-0. You might like to
do a Web search for it.
I'm not qualified to comment on its security.
It's probably not as spectrum efficient as it seems as it's
rather a bulky system. Unsurprisingly.
--
__________________________
Jim Dunnett.
g4rga at thersgb.net
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Encrypt string to produce a unique number
Date: 1 Aug 2000 13:50:52 -0700
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>In Standard C, unsigned long must have at least 32 bits; you seem
>to be measuring in terms of decimal digits, which is imprecise.
I'm sure you know this already and just didn't want to confuse the
original poster, but: measuring a word size in decimal digits can be just
as precise as measuring it in bits. The conversion factor between the two
is irrational, however, so a binary word won't ever be a nice well-behaved
number of decimal digits, and an n-digit decimal number won't pack nicely
into a word.
--
Matthew Skala
[EMAIL PROTECTED] I'm recording the boycott industry!
http://www.islandnet.com/~mskala/
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: Blowfish Implementation
Date: Tue, 01 Aug 2000 21:06:57 GMT
On Tue, 1 Aug 2000, John Myre wrote:
> Joseph Ashwood wrote:
> <snip>
> > Just tell the computer that it's a pointer to a different type, in this=
case
> > long instead of char.
>=20
> Ah, gee. Are you seriously intending to promulgate this practice
> to programmers who plainly don't know any better? Or is this a
> joke, and my sense of humor has malfunctioned? Not every computer
> is an Intel x86.
>=20
> JM
>=20
That is why he said as introduction (not exact quote) :
if you do not worry about endianness
with power comes responsability
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al Fax : (514) 343-2210
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW :
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Hardware based PK crypto device - University project
Date: 1 Aug 2000 21:07:32 GMT
Paul Morris <[EMAIL PROTECTED]> wrote:
>I am currently reading Electronic Engineering at Southampton University, UK,
>and as a major part of my degree course I must develop an electronics based
>project. Having read a little about encryption technology in general and
>having a general interest in the subject area I was hoping to base my
>project on some form of public key encryption system.
OK
>My initial idea revolved around designing a unit capable of conducting a
>secure transaction with an authenticated partner. This unit would consist of
>a PIC16 micro computer for general control and possible data crunching or
>the use of an FPGA board which could provide more sophisticated and faster
>data manipulation. Having read a little into SSLv3 I was considering basing
>the handshaking process on this model. Is that reasonable?
If you put an entire SSL stack into an embedded device, that might be
useful for secure web servers, but that needs a lot of software (available
over the net) and a serious processor to run it on (a StrongARM or MIPS
etc. Forget the PIC).
>If anyone has any experience in the area of hardware based encryption
>systems I would very much appreciate your assistance.
>
>a, Could a modern (secure) algorithm be implemented using the equipment
>described above and just how difficult a job would you rate developing it
>onto the hardware.
The standard public key algorithms (RSA etc.) are dominated by
multi-precision integer multiplication and in order to get reasonable
speed from your device, you'll mainly need a fast parallel multiplier
or multiply/adder, the type of thing you find in a DSP core. I don't
know if you can do that in a typical FPGA. The software
implementations you're competing with typically run on high end
Pentium III-class processors, which means they do a 32x32-bit multiply
with 64 bit result in 3 cpu cycles, and the current ones clock at around
1 GHz. Your FPGA implementation doesn't necessarily have to run that
fast if it has security advantages, but you still should know what
you're up against.
The main requirement of a hardware implementation is often security
rather than speed. Software solutions are extremely cost effective
these days, but they are not secure against having the computer
tampered with (you have lost all security if someone can walk up to
the computer and copy the file containing the private key). A
hardware implementation should be secured against tampering, timing
attacks, power consumption trace attacks, etc. You might look at the
FIPS 140-1 standard (find via www.nist.gov) for ideas.
Building secure hardware is tricky and maybe outside the scope of a
course project.
>b, Could you suggest a suitable, secure algorithm for this type of
>implementation.
If all you want to do is implement a public key algorithm in an FPGA,
the most interesting choice might be elliptic curve encryption over
GF(2^n). That gets rid of the high-precision multipliers: you'd
instead do standard boolean operations on wide registers (like 160 bits).
Note that Certicom has patents on some of the more important techniques,
but since this is for a school project and not for use or sale, it
should be ok (though IANAL, etc).
>c, Since the project is generally supposed to be of some academic or
>commercial value can you think of a specific requirement which could be met
>by a project of this nature or similar.
The elliptic curve FPGA implementation would hopefully run much faster
than a software implementation could.
>d, Could you suggest a good book or two for a relative newbie (hopefully not
>too much mathematical proof) that I could buy through normal channels
>(amazon etc.)
Cryptography in general: Applied Cryptography (2nd ed) by Bruce Schneier.
Elliptic curves: Certicom web site (www.certicom.com) white papers on ECC.
------------------------------
** 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
******************************
