Cryptography-Digest Digest #738, Volume #11 Tue, 9 May 00 07:13:01 EDT
Contents:
Re: Scary Possibility: Ticklish Chips (Paul Rubin)
high speed public key crypto ("Mehdi Sotoodeh")
Re: Why no civilian GPS anti-spoofing? / proposal (Paul Rubin)
Re: Scary Possibility: Ticklish Chips (Volker Hetzer)
Extended Euclidian Algorithm In C, C++ or Java ("Lewis-Oakes")
Prime Generation in C,C++ or Java ("Lewis-Oakes")
Re: Extended Euclidian Algorithm In C, C++ or Java (Eric Hambuch)
Re: Generator for ElGamal? (Eric Hambuch)
Re: Prime Generation in C,C++ or Java (Eric Hambuch)
Re: high speed public key crypto (Eric Hambuch)
Re: Q: Searching for authentication protocols (=?iso-8859-1?Q?Tom=B4s?= Perlines
Hormann)
Re: Newbie question about primes ("JoeC")
Re: An argument for multiple AES winners ("Simon Johnson")
Re: An argument for multiple AES winners ("Simon Johnson")
RSA ("Simon Johnson")
Re: RSA (Soeren Mors)
Re: Extended Euclidian Algorithm In C, C++ or Java ("Simon Johnson")
F function. ("Simon Johnson")
Re: Is this random? ("Simon Johnson")
Re: F function. (Tom St Denis)
Re: Is there a Commercially Available Tranposition Program ("Simon Johnson")
Re: Is there a Commercially Available Tranposition Program (Tom St Denis)
Re: Making Java & C Serpent code compatible? (Gisle Sælensminde)
Re: Hardware RNG (Mok-Kong Shen)
Re: Extended Euclidian Algorithm In C, C++ or Java (John Bailey)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Scary Possibility: Ticklish Chips
Date: 9 May 2000 07:51:17 GMT
In article <8f802p$rdc$[EMAIL PROTECTED]>, zapzing <[EMAIL PROTECTED]> wrote:
>Here's something to keep you awake at night: What if some of the
>chips for doing DES etc. have been made "ticklish" , that is what if
>some sort of irritant, such as a dose of radiation or an electrical
>input that is out of band would prompt the chip to divulge its key.
>This could be bad if bad guys manage to steal your (otherwise tamper
>proof) encryption device. Any ideas on how to prevent this, (other
>than by just trying to make your packaging impervious to all possible
>tickles, which seems to me to be pretty hopeless) ?
That's called differential fault analysis and it's a serious problem
for smart card manufacturers. Several papers have been written about it.
For modules with more complicated packaging than smart cards, it's easier
to protect against, though I don't think any type of hardware tamper
resistance can stop a really determined and rich attacker.
------------------------------
From: "Mehdi Sotoodeh" <[EMAIL PROTECTED]>
Subject: high speed public key crypto
Date: Tue, 09 May 2000 07:59:37 GMT
I have found a new public key crypto system that is fast, easy to implement
and requires low level of system resources.
I am looking for someone who is interested to work on this as a joint
project. I specifically need help on evaluation and publication of the
project.
Please let me know if you are interested.
Mehdi Sotoodeh.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: sci.geo.satellite-nav
Subject: Re: Why no civilian GPS anti-spoofing? / proposal
Date: 9 May 2000 08:08:32 GMT
In article <M2aR4.59506$[EMAIL PROTECTED]>,
Mxsmanic <[EMAIL PROTECTED]> wrote:
>"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
>news:8f35o6$o7i$[EMAIL PROTECTED]...
>
>> I'd like to propose that civilian signals on
>> the new carriers have public-key digital signatures,
>> signed by the satellites.
>
>Just what part would you sign, exactly? Public-key encryption is not
>appropriate for every application.
Dunno. I leave that to GPS experts. I do see some of the obvious
obstacles but maybe not all of them. I have some ideas for getting
around the obstacles but they're probably naive.
>Since mission-critical navigation applications would supplement the
>satellite signals with a ground-based signal, spoofing of both would be
>no more likely than spoofing of VOR or ILS signals today, even without
>encryption. In fact, I don't remember terrorists ever spoofing any kind
>of navigation signal at all--have I missed something?
I know one thing, which is that the US military considers spoofing a
serious enough threat to PPS that the P-code encryption system is
called "anti-spoofing" rather than "encryption". That by itself makes
me feel that the civilian signal should also be authenticated, unless
there's a really strong reason not to do so.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Scary Possibility: Ticklish Chips
Date: Tue, 09 May 2000 08:09:15 +0000
zapzing wrote:
>
> Here's something to keep you awake at night:
> What if some of the chips for doing DES etc. have
> been made "ticklish" , that is what if some
> sort of irritant, such as a dose of radiation
> or an electrical input that is out of band
> would prompt the chip to divulge its key.
Much easier. You design a chip. You give
the design to a company for manufacturing.
Manufacturer has connections to government
and - your chip has an undocumented debug
feature triggered by a certain combination on
your 100+ pins or a specific fluctuation in the
power supply.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: "Lewis-Oakes" <[EMAIL PROTECTED]>
Subject: Extended Euclidian Algorithm In C, C++ or Java
Date: Mon, 8 May 2000 18:11:46 +0100
Does anyone have a good algorithm for performing inverse moduli calculations
with the extended Eulcidian algorithm? I need one for a piece of
cryptographic software I am working on, and have not been able to find
anything on the web.
Thanks
Justin Lewis-Oakes
------------------------------
From: "Lewis-Oakes" <[EMAIL PROTECTED]>
Subject: Prime Generation in C,C++ or Java
Date: Mon, 8 May 2000 18:13:29 +0100
Is there a quick and relatively short algorithm in any of these languages
for generating primes? The primes do not have to be huge, to the order of 5
to ten digits in decimal.
Thanks
Justin Lewis-Oakes
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: Extended Euclidian Algorithm In C, C++ or Java
Date: Tue, 09 May 2000 10:38:19 +0200
Lewis-Oakes wrote:
>
> Does anyone have a good algorithm for performing inverse moduli calculations
> with the extended Eulcidian algorithm? I need one for a piece of
> cryptographic software I am working on, and have not been able to find
> anything on the web.
> Thanks
> Justin Lewis-Oakes
/* erw. euklid. Algorithmus nach Buchmann: Einf. in die Kryptographie,
Springer */
#include <stdio.h>
int xeuclid(int a, int b, int x[], int y[])
{
int q,r,xx,yy,sign;
x[0]=1; x[1]=0;
y[0]=0; y[1]=1;
sign=1;
while (b != 0)
{
r = a % b;
q = a / b;
a = b;
b = r;
xx = x[1];
yy = y[1];
x[1] = q*x[1] + x[0];
y[1] = q*y[1] + y[0];
x[0] = xx;
y[0] = yy;
sign = -sign;
}
x[0] = sign*x[0];
y[0] = -sign*y[0];
return a;
}
int main(int argc, char **argv)
{
int a,b,x[2],y[2];
if(argc != 3)
{
printf("Aufruf: euclid2 <a> <b>\n");
return -1;
}
a=atoi(argv[1]);
b=atoi(argv[2]);
printf("ggT von %ld und %ld ist: %ld\n",a,b,xeuclid(a,b,x,y));
printf("Koeffizienten: %ld %ld %ld %ld\n",x[0],x[1],y[0],y[1]);
}
Sorry, comments are in German !
Eric
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: Generator for ElGamal?
Date: Tue, 09 May 2000 10:40:30 +0200
[EMAIL PROTECTED] wrote:
>
> I was just looking at a piece of code that purported to implement
> ElGamal, and noticed they weren't making any checks to make sure that
> the "g" was really a generator. I knew that they used Schneier's
> Applied Cryptography as a reference, so looked in there and he says to
> just use a random g (which they have faithfully implemented)!
>
> Surely this is a mistake, right? The public key must include a pair
> <g,p>, where g is a generator for p.
>
> I checked the errata for Schneier's book, and it didn't say anything
> about this. Am I missing something really obvious here?
Try the Handbook of Applied Cryptography
http://cacr.math.uwaterloo.ca/hac
As far as I remember it contains an algorithm to check or generate a
generator !
Eric
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: Prime Generation in C,C++ or Java
Date: Tue, 09 May 2000 10:47:35 +0200
Lewis-Oakes wrote:
>
> Is there a quick and relatively short algorithm in any of these languages
> for generating primes? The primes do not have to be huge, to the order of 5
> to ten digits in decimal.
> Thanks
> Justin Lewis-Oakes
Create a random number and then test if it is prime. This can be done by
a probabilistic algorithm
(see Handbook of Applied Cryptography,
http://cacr.math.uwaterloo.ca/hac) oder by dividing (for small prime
numbers).
Eric
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: high speed public key crypto
Date: Tue, 09 May 2000 10:56:15 +0200
Mehdi Sotoodeh wrote:
>
> I have found a new public key crypto system that is fast, easy to implement
> and requires low level of system resources.
Are you sure ? Did you find the holy gral?
> I am looking for someone who is interested to work on this as a joint
> project. I specifically need help on evaluation and publication of the
> project.
> Please let me know if you are interested.
I think we are all interested ?!
Eric
------------------------------
From: =?iso-8859-1?Q?Tom=B4s?= Perlines Hormann <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Q: Searching for authentication protocols
Date: Tue, 09 May 2000 11:40:20 +0200
Thanks a lot for these hints, but I guess strong password authentication
may not be enough as we need to exchange symmetric keys in order to have
a secure communciation channel during the authentication (handshake)
protocol.
Do you have any ideas how to manage it, specially in the 2nd case, where
students authenticate between each other?
Thomas Wu wrote:
>
> If you're doing password-based authentication, the current state-of-the-art
> consists of protocols like SRP and SPEKE. See:
>
> http://srp.stanford.edu/srp/
> http://www.integritysciences.com/
> --
> Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
> E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
> Phone: (650) 723-1565 exchange for security deserve neither."
> http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
--
Quick answering: mailto:[EMAIL PROTECTED]
Check it out: http://www.weh.rwth-aachen.de/~tomas
Do it Now!
:o) Tomás Perlines (o:
------------------------------
From: "JoeC" <[EMAIL PROTECTED]>
Subject: Re: Newbie question about primes
Date: Mon, 8 May 2000 21:08:25 +0100
Earl K. Nimoy <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "JoeC" <[EMAIL PROTECTED]> wrote:
>
> >As I understand it, one of the key factors(pardon the pun) in the
security
> >of PGP and similar is the time taken to factor a large prime number.
>
> It's impossible to factor a prime number. By definition, the only factors
a
> prime number has are itself and 1.
> --
> "Earl K. Nimoy" is actually 7640 519382 <[EMAIL PROTECTED]>.
> 0123 4 56789 <- Use this key to decode my email address and name.
> Play Five by Five Poker at http://www.5X5poker.com.
Thanks to all who replied, I actually understood most of the very cleary
expressed replies. (as a non-mathematician, thats a complement to those who
replied!!) Now, thats enough maths for one week....
Joe
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: An argument for multiple AES winners
Date: Mon, 8 May 2000 21:06:40 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Simon Johnson wrote:
>
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote
> > > I remember to have learned some time ago from
> > > discussions in this group that having multiple AES
> > > winners has the advantage of better coping with
> > > the case that one winner is eventually found to
> > > have certain weakness that is hiterto not
> > > discovered.
> >
> > Hmmmm, I kinda think that would defy the point of having a standard,
having
> > multiple standards is a contradiction. If the AES was compromised, I
believe
> > NIST would drop the standard, and start looking for a entries for a
> > replacement from scratch. (This has no factual basis, but would be
logical,
> > as it would be unfair to award '2nd' place etc....)
>
> Fine. But what should the users of AES worldwide do in the meantime?
> Wait and drink a cup of tee?
>
> > > It just occurs to me that the same applies in
> > > respect of hidden patent claims. If there are e.g.
> > > three AES winners, the chance of all of them have
> > > hidden patent claims is likely to be fairly small.
> > > So if NIST is not able to insure (free of charge)
> > > the absence of hidden patent claims to prevent
> > > the potential catastrophe of users worldwide
> > > having to pay someday patent loyalities, letting
> > > there to be multiple AES winners is definitely
> > > a good idea.
> >
> > A scary situation, but I think if someone did attempt this, it would
damage
> > their crediability so much that they would never be trusted again. I
think
> > the companies involved in the AES have too much to loose by using
attempting
> > this, and therefore they won't. Moreover, I think NIST would throw them
out,
> > since one of its specification is that the algorithm be freely
availible,
> > was it not?
>
> Patents are not necessarily owned by companies. The patent holder can
> be a private person. What should I care, if I could gain a milliarde
through
> enforcing a patent claim?
>
> > > BTW, I like to ask at this opportunity a probably
> > > dumb question. Is it certain that AES will be
> > > freely available to all people of the world?
> > > Would its use be restricted to applications such
> > > as banking and also confined to the 'friendly'
> > > nations? How about the Wassenaar Arrangements?
> >
> > Yes I believe it would, and even if it wasn't (available worldwide) , I
very
> > much doubt that would stop anyone for very long.
>
> It is indeed very noteworthy that the crypto clauses of the Wassenaar
> Arrangements, that are intended to limit export to algorithms with key
> length up to a maximum of 56 bits, came into being AFTER the AES
> project has been running. So, if the top-level people involved in
> crypto policy are not totally il-logical or forgetful, there must be
> something particular in this connection. Yet many people seem
> to be happy for the forthcoming benediction without questioning
> whether there could possibly be a catch.
>
> M. K. Shen
>
Looks like you've answered you're own question :)
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: An argument for multiple AES winners
Date: Mon, 8 May 2000 21:08:23 -0700
This is a multi-part message in MIME format.
=======_NextPart_000_0043_01BFB931.8B5B0F40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Anton Stiglic <[EMAIL PROTECTED]> wrote in message =
news:[EMAIL PROTECTED]...
Mok-Kong Shen wrote:=20
<...>=20
It just occurs to me that the same applies in=20
respect of hidden patent claims. If there are e.g.=20
three AES winners, the chance of all of them have=20
hidden patent claims is likely to be fairly small.=20
<...>
This point has been misunderstood by many.=20
You are calculating the probability in the wrong way.=20
It's not an *and*, but an *or*. If you have 3 algos,=20
with probability of p1 that the first will have a component=20
that is patented, p2 for the second and p3 for the last,=20
the probability that the whole has a component that is=20
patented is p1 + p2 + p3, which is >=3D to any single pi.=20
This comes from the fact that you are reliable for what=20
you have done in the past (if you used a patented=20
algorithm in the past, they can sue you).=20
The more algos you use, the greater the risk of having=20
a patent attack.=20
Anton=20
-> A nice way of putting it :)
=======_NextPart_000_0043_01BFB931.8B5B0F40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<DIV>Anton Stiglic <<A =
href=3D"mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</A>>=20
wrote in message <A=20
=
href=3D"news:[EMAIL PROTECTED]">news:[EMAIL PROTECTED]</A=
>...</DIV>Mok-Kong=20
Shen wrote:=20
<BLOCKQUOTE TYPE=3D"CITE"><...>=20
<P>It just occurs to me that the same applies in <BR>respect of =
hidden=20
patent claims. If there are e.g. <BR>three AES winners, the chance =
of all of=20
them have <BR>hidden patent claims is likely to be fairly small.=20
<P><A=20
=
href=3D"http://home.t-online.de/home/mok-kong.shen"><...></A></P></=
BLOCKQUOTE>This=20
point has been misunderstood by many.=20
<P>You are calculating the probability in the wrong way. <BR>It's not =
an=20
*and*, but an *or*. If you have 3 algos, <BR>with probability of =
p1 that=20
the first will have a component <BR>that is patented, p2 for the =
second and p3=20
for the last, <BR>the probability that the whole has a component that =
is=20
<BR>patented is p1 + p2 + p3, which is >=3D to any single pi. =
<P>This comes from the fact that you are reliable for what <BR>you =
have done=20
in the past (if you used a patented <BR>algorithm in the past, they =
can sue=20
you).=20
<P>The more algos you use, the greater the risk of having <BR>a patent =
attack.=20
<P>Anton=20
<P><FONT face=3DArial size=3D2>-> A nice way of putting it =
:)</FONT>
<P> </P></BLOCKQUOTE></BODY></HTML>
=======_NextPart_000_0043_01BFB931.8B5B0F40==
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: RSA
Date: Mon, 8 May 2000 21:21:45 -0700
Is the output from RSA 'random'?
If so is this the result of the massive number of multiplications in the
finite field?
After what exponent, modulo some number (n), would the output become
'random'?
------------------------------
From: Soeren Mors <[EMAIL PROTECTED]>
Subject: Re: RSA
Date: 09 May 2000 12:09:05 +0200
"Simon Johnson" <[EMAIL PROTECTED]> writes:
> Is the output from RSA 'random'?
No, it is uniquely determined by the input and the key. It might be
the case that the output is indistinguishable (by known methods) from
random data.
> If so is this the result of the massive number of multiplications in the
> finite field?
It`s the result of one exponentiation.
> After what exponent, modulo some number (n), would the output become
> 'random'?
Never. Composing two exponentiations just gets you another exponentiation.
--
Soeren Mors
Student of Computer Science at DAIMI [EMAIL PROTECTED]
For security this message has been encrypted with double ROT13
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Extended Euclidian Algorithm In C, C++ or Java
Date: Mon, 8 May 2000 22:41:03 -0700
I don't know if such an algorithm exists. But an easy way, though probably
slow is to computer (p-1)*(q-1) and use modulo expantion to compute the
inverse.
such that if your public exponent is e then u're private exponent is d:
d=e^(p-1)*(q-1) mod (p*q)
Lewis-Oakes <[EMAIL PROTECTED]> wrote in message
news:8f6s3f$c3g$[EMAIL PROTECTED]...
> Does anyone have a good algorithm for performing inverse moduli
calculations
> with the extended Eulcidian algorithm? I need one for a piece of
> cryptographic software I am working on, and have not been able to find
> anything on the web.
> Thanks
> Justin Lewis-Oakes
>
>
>
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: F function.
Date: Mon, 8 May 2000 22:51:39 -0700
This is a petty little F-Function. I am almost certain this is easily
breakable.
Here it is anyway:
y=(x+k) ^ 3 mod 256
X = some data, K = sub-key. (Function designed for Fiestel)
Logic: (Any flaws in my logic?)
Using the extended euclidean algorithm, I try to find the inverse of that
function.....
256 = (2^8), 0(256) = (2-1) ^ 8 = 1
d=3^1 mod 256=3, same as originial so no inverse?
I picked an exponent of 3 because i figured, rightly or wrongly :), that it
would be a harder problem the square-rooting in a finite field.
So why not an exponent of 4 or 17 or 23,000,000?
To get maximum speed out of the cipher.
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Is this random?
Date: Mon, 8 May 2000 22:56:43 -0700
Benjamin Goldberg <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I've come across a number generator written in java which claims to be
> "truly random" number generator (not a PRNG)... Could someone tell me
> how accurate (or inaccurate) this claim is?
Inaccurate, a computer is a finite-state, determinsitic beast. Eventually,
any "truly random number generator" will become periodic and therefore
predictable. (Unless of course you use something attached to you're computer
that records random noise or something along those lines.)
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: F function.
Date: Tue, 09 May 2000 10:24:51 GMT
Simon Johnson wrote:
>
> This is a petty little F-Function. I am almost certain this is easily
> breakable.
>
> Here it is anyway:
>
> y=(x+k) ^ 3 mod 256
>
> X = some data, K = sub-key. (Function designed for Fiestel)
That's not a function of the input since x^3 mod p (p = composite) is
not bijective. So it most likely has very bad characteristics.
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Is there a Commercially Available Tranposition Program
Date: Mon, 8 May 2000 23:21:19 -0700
If you're really stuck, right you're own.
Create a two dimensional array, fill left to right, top to bottom.
Then read off the collums.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Is there a Commercially Available Tranposition Program
Date: Tue, 09 May 2000 10:32:53 GMT
Simon Johnson wrote:
>
> If you're really stuck, right you're own.
>
> Create a two dimensional array, fill left to right, top to bottom.
> Then read off the collums.
Won't
for x = 1 to n
for y = 1 to n
M[x][y] = F(x, y)
for x = 1 to n
for y = 1 to n
Mt[y][x] = M[x][y]
Transpose the matrix (the first loop sets the values initially)?
Tom
--
Want your academic website listed on a free websearch engine? Then
please check out http://tomstdenis.n3.net/search.html, it's entirely
free
and there are no advertisements.
------------------------------
From: [EMAIL PROTECTED] (Gisle Sælensminde)
Subject: Re: Making Java & C Serpent code compatible?
Date: 9 May 2000 12:38:05 +0200
In article <[EMAIL PROTECTED]>, Mo Sherman wrote:
>Hi,
>
>I am trying to encrypt/decrypt info from a C environment to a Java
>environment, and visa versa. To that end, I've tried using C and Java
>implementations of Serpent - without success. They should be utilizing
>the same algorithm, but the code looks drastically different for each
>implementation. Does anyone have ideas on how to make them compatible?
If you read the key or the plaintext as a hex string using the
build in hex converter in the C package that may be the problem.
The original AES submission C hex to decimal converter stores the
32-bit numbers on the order (X3 X2 X1 X0), while the java version
use (X0 X1 X2 X3), where X[0-3] is the input words stored in little-
endian format. That mismatch caused me several houres of debugging.
--
Gisle Sælensminde ( [EMAIL PROTECTED] )
ln -s /dev/null ~/.netscape/cookies
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Hardware RNG
Date: Tue, 09 May 2000 12:53:59 +0200
Joseph Ashwood wrote:
>
> true randomness as possible. BTW can someone give me details
> on ANSI's Secure Random Number Generator standard? I know
Does anyone know the number of the standard document?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: Extended Euclidian Algorithm In C, C++ or Java
Date: Tue, 09 May 2000 11:08:41 GMT
On Mon, 8 May 2000 18:11:46 +0100, "Lewis-Oakes"
<[EMAIL PROTECTED]> wrote:
>Does anyone have a good algorithm for performing inverse moduli calculations
>with the extended Eulcidian algorithm? I need one for a piece of
>cryptographic software I am working on, and have not been able to find
>anything on the web.
>Thanks
>Justin Lewis-Oakes
/* This invert algorithm was developed as a model from which to build
a c based invert algorithm. Inverter2 is not a satisfactory model
because it multiplies and divides without regard to any truncation.
This algorithm avoids taking any product which cannot be truncated by
at most b, the modulus against which the inverse value is sought.
Another niceity of this algorithm is its use of array numbers in a
mode which closely follows the way a pseudo stack has to be used in
the c based program. While bc is reentrant, its returns are single
valued. Since the technique for avoiding larger than allowed
multiplication requires that both the remainder and quotient be used
to pass numbers, the single valued returns of bc had to be
supplimented anyway. */
define r(j) {
auto u , r
r = a[j] - (b[j] % a[j])
x[j] = (b[j] / a[j]) + 1
y[j] = 1
while( b[j] % r > 0) {
u = ( b[j] / r ) + 1
x[j] = x[j] * u % b[0]
y[j] = (y[j] * u + 1) % b[0]
r = r - (b[j] % r)
}
return(r)
}
define i(j) {
auto r
r = r(j)
if( r > 1) {
a[j + 1] = r
b[j + 1] = a[j]
i(j + 1)
z[j] = (x[j] * z[j + 1] - k[j + 1]) % b[0]
k[j] = (z[j + 1] * y[j]) % b[0]
return
}
z[j] = x[j]
k[j] = y[j]
return
}
define f(a,b) {
j = 0
a[j] = a
b[j] = b
i(j)
return(z[j])
}
Using this model, the c code at:
http://www.frontiernet.net/~jmb184/interests/cryptography/old_trunk/
was developed.
John
------------------------------
** 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
******************************
