Cryptography-Digest Digest #896, Volume #11 Tue, 30 May 00 15:13:01 EDT
Contents:
Re: No-Key Encryption (tomstd)
Re: any public-key algorithm ("Eric Verheul")
Re: driving me and friends nuts ([EMAIL PROTECTED])
Re: Small compression/encryption problem ("Joseph Ashwood")
Re: any public-key algorithm (tomstd)
Re: CAST Sboxes -- need help (Mike Rosing)
Re: very crazy code (Anton Stiglic)
Re: Is OTP unbreakable?/Station-Station ("Trevor L. Jackson, III")
Re: encryption without zeros (wtshaw)
Re: any public-key algorithm ("Eric Verheul")
Re: Small compression/encryption problem ("Trevor L. Jackson, III")
Re: driving me and friends nuts ("Colin Barker")
Re: CAST Sboxes -- need help (tomstd)
Re: any public-key algorithm (tomstd)
Re: NSA hardware evaluation of AES finalists (Jaap-Henk Hoepman)
Yes ... Ericsson seems to have a strategic alliance with some Microsoft technology
utilizers .... (Markku J. Saarelainen)
Re: any public-key algorithm ("Eric Verheul")
Re: any public-key algorithm (Roger Schlafly)
----------------------------------------------------------------------------
Subject: Re: No-Key Encryption
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 30 May 2000 10:25:04 -0700
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <mok-
[EMAIL PROTECTED]> wrote:
>
>
>DD wrote:
>
>> tomstd <[EMAIL PROTECTED]> wrote
>>
>> > If I get the 3-pass protocal it is:
>> >
>> > A wants to send B 'm'.
>> >
>> > 1. A sends m^e mod p
>> > 2. B sends m^e^d mod p
>> > 3. A sends m^e^d^-e nod p
>> >
>> > B recovers 'm' via m^e^d^-d^-e mod p
>> >
>> > Then 'e' and 'd' are your keys. This is hardly 'no-key'
>> > encryption.
>> >
>>
>> It is no-key in thye sense that neither user has a key.
>> It's generated on the fly (e.g. a session key) and exchanged
>> like in Diffie-Hellman.
>
>Still, these stuffs generated on the fly are 'fundamentally'
inaccessible
>to the analyst and hence are equivalent to (secret) keys. The
same
>doesn't seem to apply to using foreign languages.
That's not true, I have m^e, m^de and m^d, from which I could
plausibly solve if I knew 'm'. There is probably some math
trick you can do as well, that I am not aware of... (frankly
there is a lot I am not aware of, and that bugs me too).
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "Eric Verheul" <[EMAIL PROTECTED]>
Subject: Re: any public-key algorithm
Date: Tue, 30 May 2000 19:14:28 +0200
tomstd <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <w4SY4.3338$[EMAIL PROTECTED]>, "Dark
> Nebular" <[EMAIL PROTECTED]> wrote:
> >Hi !!
> >
> >Could anybody give me the description of a public-key
> algorithm, other than
> >RSA?
>
> Look up NRTU, ECC or ElGamal
Hey, don't forget XTR now! It has all the computational and communicational
benefits of
ECC (and more) but it's security is based on the DL problem in GF(p^6), i.e.
a sixth field
extension of a basic field of size 160-170 bits.
Which is considered rock solid like that of RSA.
Moreover, it parameter and key generation is very fast (upto 80 times faster
then RSA's,
if you really believe that in practice RSA key gen is a 4th power function
of key length).
Finally, XTR has a curious intrinsic resistance against Differential Power
Attacks.
See www.ecstr.com for a detailed description.
Eric
>
> Tom
>
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: driving me and friends nuts
Date: Tue, 30 May 2000 17:22:53 GMT
[apologies for crappy formatting -- I miss vi.]
In article <[EMAIL PROTECTED]>,
Yanko Leskovar <[EMAIL PROTECTED]> wrote:
> Can anyone with better decryption skills solve this encoded message ?
>
> MLWMZYZ VSG MLRHHRN WMZ MIFGVI LG VHZY
>
> it's driving me nuts. anyway just to point out some observations of
the
> above code, which
> may or not help are;
>
> * 7 words (but this may be a trick)
> * 32 letters (some repeated)
> * letters A to E are not used
> * lowest alphabet letter is G
> * highest alphabet letter is Z
> * The used letters, also form adjacent groups from the alphabet
> (ghi, lmn, rs, vw,yz) - hmm this must be something cluey?
> * Replacing each letter with it's ASCII-value and subtracting with
> values 1 (through to 26)
> does not reveal any sensible message, so substitution does not work
?
Yanko, with these notes here, you are well on your way to solving the
problem -- I suggest a book by Helen Gaines (I think I spelled that
correctly), _Cryptanalysis_. It covers all sorts of pre-computer ciphers
such as this one.
I found my copy of Gaines at Powell's Technical Bookstore, perhaps your
local geek store has a copy too. It is published by Dover, last updated
in 1955 or something like that. :) ($8 too! :)
Until you can find the book, make some frequency counts -- individual
letters, digrams, and perhaps trigrams, and compare against tables of
letter frequencies, digrams freqs, and trigram freqs, at which point
trial and error likely takes over.
The message really isn't long enough for multiple substitution alphabets
to be easily analyzed (remember your statistics courses -- fewer than
thirty samples leads to poor results) -- but it *could* be done.
(Without going over the effecient methods, just look at subsets of the
message, set off by 2, 3, 4, 5, etc letters. With this small a message,
it shouldn't be too bad.)
HTH
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Small compression/encryption problem
Date: Tue, 30 May 2000 10:38:10 -0700
Crossposted-To: comp.compression
While I certainly agree with Macon, I would like to point out some potential
errors. Although it is not necessary to protect against the potential of a
good attacker, it is not much more difficult to protect against them, so it
is useful as a thought process, if not as a resultant program.
My suggestion is to do the following:
Compute the relative frequencies of 1,2,3 and 4, assign them a space isn 256
accordingly, so if 4 occurs only 3 times out of 256, it should have the
space of 253, 254, 255.
Use a random numebr generator (Mersenne Twister should do quite well) to
place them in that space. The simplest way is to just keep pulling numbers
until one in the needed range comes out (253, 254, 255 in the above
example), replace the input number (1,2,3,4) with the output number
(0.....255). This balances the frequencies of the characters, making them
appear quite random.
Take these values, put them through RC4 (as suggested by using ciphersabre).
This provides cryptographic security, enhanced by the random appearing
string underneath, making it extremely difficult to uncover the original
even under good circumstances.
Then encode these however you want to. Attaching an ECC (error checking and
correcting, as used in DRAMs, talk to the computer science or electrical
engineering people) value to blocks, it is possible to build a stream that
is fairly strong (each input value is approximately balanced in likelihood,
and protected by strong cryptography), and error checked and corrected. The
resultant stream should actually be resistant to virtually all attackers (it
may be possible that the NSA could solve it, but it's not likely).
Joe
ps. The news server I'm on has lost it's stream for sci.crypt. Could someone
e-mail me privately with information on any other news servers (non web
based please, I don't appreciate their interfaces) that carry sci.crypt. The
more options I have the better, so don't be shy.
------------------------------
Subject: Re: any public-key algorithm
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 30 May 2000 10:42:31 -0700
In article <8h0tid$qv4$[EMAIL PROTECTED]>, "Eric Verheul"
<[EMAIL PROTECTED]> wrote:
>
>tomstd <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> In article <w4SY4.3338$[EMAIL PROTECTED]>, "Dark
>> Nebular" <[EMAIL PROTECTED]> wrote:
>> >Hi !!
>> >
>> >Could anybody give me the description of a public-key
>> algorithm, other than
>> >RSA?
>>
>> Look up NRTU, ECC or ElGamal
>
>Hey, don't forget XTR now! It has all the computational and
communicational
>benefits of
>ECC (and more) but it's security is based on the DL problem in
GF(p^6), i.e.
>a sixth field
>extension of a basic field of size 160-170 bits.
>Which is considered rock solid like that of RSA.
>Moreover, it parameter and key generation is very fast (upto 80
times faster
>then RSA's,
>if you really believe that in practice RSA key gen is a 4th
power function
>of key length).
>Finally, XTR has a curious intrinsic resistance against
Differential Power
>Attacks.
>
>See www.ecstr.com for a detailed description.
Fortunately I have no clue what GF(p^6) means. Does that mean
the modulus is a prime raised to it's sixth power?
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: CAST Sboxes -- need help
Date: Tue, 30 May 2000 12:43:39 -0500
tomstd wrote:
>
> I have read several of the CAST papers over and over and over
> and over, and I can't seem to grasp how they actually made the
> 32x32 sboxes (using four 8x32) or how their 'permute' function
> works to make bijective sboxes.
I thought they picked values at random and then checked to see if
the result passed all their tests. Been a long time since I've
read those papers tho. The "Good S-boxes are easy to find" paper
should explain it some.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: very crazy code
Date: Tue, 30 May 2000 13:53:11 -0400
GUSTAVO H MARTINS wrote:
>
> As Hugo said, give up and go home, or better, "ABANDON THE MISSION AND
> RETURN TO BASE".
>
> Use "Text" = 27 - "Code" and invert words.
>
> Gus
That was cute...
Anton
------------------------------
Date: Tue, 30 May 2000 14:32:21 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?/Station-Station
Joaquim Southby wrote:
> In article <[EMAIL PROTECTED]> Tim Tyler, [EMAIL PROTECTED] writes:
> >There's nothing terribly unusual about chosen plaintext attacks - or
> >man-in-the-middle attacks.
> >
> The unusual part is that he proposed obtaining plaintext and then somehow
> intercepting the corresponding enciphered text. Oh, and let's not forget
> the caveat that the interception must be performed so that the message
> doesn't reach the receiver and that neither the sender nor the receiver
> are aware of the act. Would this work if the sender secures his
> plaintexts? No. Would this work if the enciphered message was
> broadcast? No. Would it work more than once? No (unless you have some
> very obtuse targets).
These claims may be based on a limited view of the opportunities an
interceptor has. Consider that many comm techniques have a more sophisticated
infrastructure than a pair of tin cans connected by string. For example,
simple radio broadcasts imply that every message can, in principle, be
received by every listener. But who is the "listener"? Is it the radio
operator of the captain? The radio operator isn't really a listener, but more
a part of the infrastructure. He will ignore or discard traffic not aimed at
a a listener on his ship.
This means that changing a digit in a message header from PT109 to PT106 would
be the equivalent of blocking the message because the intended recipient does
not get the message.
Network switches and routers perform this kind of filtering all the time.
Even (especially) on broadcast messages as opposed to point-to-point traffic.
Point is that a robust communication channel has a great deal of designed-in
resilience. That resilience leaves room for attacks masquerading as human
errors, software bugs, or hardware glitches.
>
>
> >The ability to process information by intercepting all communication
> >through a cable provides room for a man-in-the-middle.
> >
> His original message did not posit the medium of transmission. Even if
> you have room in your cable for the man-in-the-middle, you still must
> have the original plaintext.
>
> >...and known-plaintexts have been used by cryptanalysts extensively since
> >the art was born.
> >
> >I don't see any coherent arguments against Guy's summary.
> >
> The arguments were not against the particular case he described, simply
> against the rather limited circumstances to which it would apply.
> Coherency is in the ear of the beholder.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: encryption without zeros
Date: Tue, 30 May 2000 11:08:06 -0600
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
> rick2 wrote:
> > I would like to use some strong encryption but need to have
> > the output not have any zeros (needs to fit into zero-terminated
> > data chunks). What would be the smallest and fastest way to mask
> > the zeros? I've seen some people expand every 7 bits to 8, but
> > that seems wasteful (expands to 114% of original size, or so) and
> > takes time (every output byte needs to be shifted).
>
> If you want to transform random data of an alphabet with 256
> characters into another alphabet with 255 characters (i.e. never
> with the NUL character), you cannot get a better average
> expansion factor than 0.4%.
>
> If you use a special escape character, where you transform a sequence
> { 0 } into { ESC 1 } and { ESC } into { ESC 2 }, you have 0.8%
> expansion in average. This is only 200% of the smallest expansion
> possible, and the implementation is really simple. Because you always
> work with the output of a cipher, which is random if the cipher is not
> next to useless, it is very very very unlikely (but not impossible!)
> that you will ever have the worst case of 100% expansion, especially
> for long sequences.
>
> So I think there can't be a better scheme for you. However, you always
> have to keep in mind the worst case MAY occur, which is not the case
> if one uses the 8 to 7 bit transformation, which always has the fixed
> expansion factor 1/7 ~ 14%.
I find this whole discussion rather humorous. With due respect(?), I'm not
sure whether it is possible to find a solution without zeros if sole
solution is vested in those thinking more as zeros. <|:-(
Depending of your actual data parameters and not on the assumptions being
introjected, there are apt to be a variety of solutions.
A simple example of actual data could be helpful. To work toward a
solution without knowing sufficiently about the problem puts various
people in orbit about their own conjectures.
--
If a privacy policy is longer that 250 words, it is already
deceptive; the longer the more deceptive.
------------------------------
From: "Eric Verheul" <[EMAIL PROTECTED]>
Subject: Re: any public-key algorithm
Date: Tue, 30 May 2000 20:11:58 +0200
> Fortunately I have no clue what GF(p^6) means. Does that mean
> the modulus is a prime raised to it's sixth power?
>
> Tom
No. The DL problem there is as hard of that of GF(p) itself, i.e. trivial if
|p| = 170. Let me
give a crash course in field theory.
I guess you know what a basic field GF(p) is? It's all residues modulo a
prime number p.
Not all (to put it mildly) sixt-th degree polynomials with coeficients in
GF(p) have zeros in the basic field itself.
In some cases polynomials with coeficients in GF(p) can not even be
factorized in a product
of lower degree polynomials. Such polynomial are called irreducible. By
formally adjoining a root
to it and doing all the "natural" artithmetic you obtain an extension field
of the degree of the irreducible
polynomial, i.e. GF(p^6) in case of a sixt-th degree polynomial. Compare
this to the situation where
you obtain the complex numbers from the real numbers by adjoining a root of
the polynomial X^2 + 1
(... the square root of -1 ...).
Extension fields are also finite fields and the DL problem "lives" there as
well. The DL problem is as difficult
(actually a bit more difficult) there than in a basic field of comparable
size. As |p|= 17-, the size of extension
field is 6*170= 1024 bits, i.e. the DL problem is as hard as breaking RSA of
1024 bits and the like
Now, XTR is based on the DL problem
in GF(p^6) but in a efficient and compact way. Whence the name Efficient and
Compact Subgroup Trace
Representation (ECSTR = XTR abreviated).
Eric
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!
>
------------------------------
Date: Tue, 30 May 2000 14:45:38 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Small compression/encryption problem
Joseph Ashwood wrote:
> While I certainly agree with Macon, I would like to point out some potential
> errors. Although it is not necessary to protect against the potential of a
> good attacker, it is not much more difficult to protect against them, so it
> is useful as a thought process, if not as a resultant program.
>
> My suggestion is to do the following:
> Compute the relative frequencies of 1,2,3 and 4, assign them a space isn 256
> accordingly, so if 4 occurs only 3 times out of 256, it should have the
> space of 253, 254, 255.
>
> Use a random numebr generator (Mersenne Twister should do quite well) to
> place them in that space. The simplest way is to just keep pulling numbers
> until one in the needed range comes out (253, 254, 255 in the above
> example), replace the input number (1,2,3,4) with the output number
> (0.....255). This balances the frequencies of the characters, making them
> appear quite random.
>
> Take these values, put them through RC4 (as suggested by using ciphersabre).
> This provides cryptographic security, enhanced by the random appearing
> string underneath, making it extremely difficult to uncover the original
> even under good circumstances.
>
> Then encode these however you want to. Attaching an ECC (error checking and
> correcting, as used in DRAMs, talk to the computer science or electrical
> engineering people) value to blocks, it is possible to build a stream that
> is fairly strong (each input value is approximately balanced in likelihood,
> and protected by strong cryptography), and error checked and corrected. The
> resultant stream should actually be resistant to virtually all attackers (it
> may be possible that the NSA could solve it, but it's not likely).
> Joe
>
> ps. The news server I'm on has lost it's stream for sci.crypt. Could someone
> e-mail me privately with information on any other news servers (non web
> based please, I don't appreciate their interfaces) that carry sci.crypt. The
> more options I have the better, so don't be shy.
I suggest the use of an ECC mechanism aimed at bursty errors rather than evenly
distributed errors due to the dominance of typographic mistakes. Some early
research in word processing typographic error rates at Wang Labs indicates that
something like 95+% of typographic errors are accounted for by only four kinds
of errors: 1) missing character, 2) extra character, 3) pair of consecutive
characters swapped, 4) wrong character.
Disk drive controllers often implement codes that can handle long bursts of
errors. (Fire codes?) Such a code for each line/record of input might be more
effective than a pure binary block ECC scheme.
------------------------------
From: "Colin Barker" <[EMAIL PROTECTED]>
Subject: Re: driving me and friends nuts
Date: Tue, 30 May 2000 20:42:01 +0200
Yanko Leskovar a �crit dans le message <[EMAIL PROTECTED]>...
>Can anyone with better decryption skills solve this encoded message ?
>
>MLWMZYZ VSG MLRHHRN WMZ MIFGVI LG VHZY
You abandoned too soon. Try reversing each word and start again.
ZYZMWLM GSV NRHHRLM ZMW IVGFIM GL YZHV
>
>it's driving me nuts. anyway just to point out some observations of the
>above code, which
>may or not help are;
>
>* 7 words (but this may be a trick)
>* 32 letters (some repeated)
>* letters A to E are not used
>* lowest alphabet letter is G
>* highest alphabet letter is Z
>* The used letters, also form adjacent groups from the alphabet
> (ghi, lmn, rs, vw,yz) - hmm this must be something cluey?
>* Replacing each letter with it's ASCII-value and subtracting with
>values 1 (through to 26)
> does not reveal any sensible message, so substitution does not work ?
>
>good luck,
>yanko
>
>
Colin
E-mail: mailto:[EMAIL PROTECTED]
Internet: http://perso.wanadoo.fr/colin.barker
------------------------------
Subject: Re: CAST Sboxes -- need help
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 30 May 2000 11:42:27 -0700
In article <[EMAIL PROTECTED]>, Mike Rosing
<[EMAIL PROTECTED]> wrote:
>tomstd wrote:
>>
>> I have read several of the CAST papers over and over and over
>> and over, and I can't seem to grasp how they actually made the
>> 32x32 sboxes (using four 8x32) or how their 'permute' function
>> works to make bijective sboxes.
>
>I thought they picked values at random and then checked to see
if
>the result passed all their tests. Been a long time since I've
>read those papers tho. The "Good S-boxes are easy to find"
paper
>should explain it some.
Problem is they don't explain how todo the walsh transform on
huge arrays in a realistic amount of time, etc...
I sorta get the math (basics) but not enough to turn it into
equivelent faster programs...
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: any public-key algorithm
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 30 May 2000 11:46:26 -0700
In article <8h111d$1dp$[EMAIL PROTECTED]>, "Eric Verheul"
<[EMAIL PROTECTED]> wrote:
>
>> Fortunately I have no clue what GF(p^6) means. Does that mean
>> the modulus is a prime raised to it's sixth power?
>>
>> Tom
>No. The DL problem there is as hard of that of GF(p) itself,
i.e. trivial if
>|p| = 170. Let me
>give a crash course in field theory.
>
>I guess you know what a basic field GF(p) is? It's all residues
modulo a
>prime number p.
>Not all (to put it mildly) sixt-th degree polynomials with
coeficients in
>GF(p) have zeros in the basic field itself.
>In some cases polynomials with coeficients in GF(p) can not
even be
>factorized in a product
>of lower degree polynomials. Such polynomial are called
irreducible. By
>formally adjoining a root
>to it and doing all the "natural" artithmetic you obtain an
extension field
>of the degree of the irreducible
>polynomial, i.e. GF(p^6) in case of a sixt-th degree
polynomial. Compare
>this to the situation where
>you obtain the complex numbers from the real numbers by
adjoining a root of
>the polynomial X^2 + 1
>(... the square root of -1 ...).
>From what I know in fields theory...
GF(2) means modulo 2 math, addtion = xor, mutiplication = and
GF(p) means modulo a prime math, a+b mod p, etc.
GF(2)^n means modulo a polynomial degree 'n' who's coefficients
are modulo 2
So does that make
GF(p)^6 means modulo a polynomial of degree 6 who's coefficients
are modulo p?
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Jaap-Henk Hoepman <[EMAIL PROTECTED]>
Subject: Re: NSA hardware evaluation of AES finalists
Date: 30 May 2000 16:47:15 +0200
On Thu, 18 May 2000 03:33:45 GMT [EMAIL PROTECTED] (Ken Lamquist) writes:
>
> [...]
>
> I now turn to implementation cost for the various finalists. The
> following table gives information on minimal size implementations.
>
> Area transistors time
> Twofish 9.15 134,997 2104.00
> Serpent 13.78 204,617 775.18
> RC6 13.97 217,008 6674.62
> Rijndael 20.74 275,485 472.1
> Mars 51.99 742,403 3872.26
>
> Twofish wins this one. I am not sure how important this metric is. I
> don't expect to see AES encryption and decryption instructions being
> built into microprocessors any time soon regardless of which candidate
> is selected.
I can very well conceive Intel including the AES finalist into its CPU core,
especially if the extra space requirements are not too high. It would, for one
thing, enable software copy protection...
Jaap-Henk
--
Jaap-Henk Hoepman | Sure! We've eaten off the silver
Dept. of Computer Science | (when even food was against us)
University of Twente | - Nick Cave
Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman
PGP ID: 0xFEA287FF Fingerprint: 7D4C 8486 A744 E8DF DA15 93D2 33DD 0F09
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.security,comp.security
Subject: Yes ... Ericsson seems to have a strategic alliance with some Microsoft
technology utilizers ....
Date: Tue, 30 May 2000 18:47:33 GMT
thr 057
Ericsson-China
Netalone & Ericsson to Jointly Develop M-Commerce
Hong Kong, May 30, Asia-Pulse-IRNA -- Netalone.com Ltd.
(HKSE:336) has announced a partnership with Ericsson to capture the
mobile e-commerce business in Greater China.
Netalone will provide its ASP technical expertise in e-commerce
applications and cross platform solutions & systems integration to
develop an m-commerce platform.
http://www.irna.com/newshtm/eng/10174239.htm
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Eric Verheul" <[EMAIL PROTECTED]>
Subject: Re: any public-key algorithm
Date: Tue, 30 May 2000 20:44:32 +0200
> From what I know in fields theory...
>
> GF(2) means modulo 2 math, addtion = xor, mutiplication = and
> GF(p) means modulo a prime math, a+b mod p, etc.
> GF(2)^n means modulo a polynomial degree 'n' who's coefficients
> are modulo 2
>
> So does that make
> GF(p)^6 means modulo a polynomial of degree 6 who's coefficients
> are modulo p?
Right! An irreducible polynomial, that is.
For instance Z^6 + Z^3 + 1 if p = 3 or 5 mod 9.
Eric
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: any public-key algorithm
Date: Tue, 30 May 2000 12:04:41 -0700
Eric Verheul wrote:
> Hey, don't forget XTR now! It has all the computational and communicational
> benefits of
> ECC (and more) but it's security is based on the DL problem in GF(p^6), i.e.
> a sixth field
> extension of a basic field of size 160-170 bits.
> Which is considered rock solid like that of RSA.
> Moreover, it parameter and key generation is very fast (upto 80 times faster
> then RSA's,
> if you really believe that in practice RSA key gen is a 4th power function
> of key length).
> Finally, XTR has a curious intrinsic resistance against Differential Power
> Attacks.
>
> See www.ecstr.com for a detailed description.
XTR looks interesting, and I even posted your URL on sci.crypt
previously, but ...
1. it hasn't had significant public scrutiny yet.
2. its only advantage over DL in GF(p) is shorter public keys.
3. you have patented it, so no one else can use it.
------------------------------
** 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
******************************
