Cryptography-Digest Digest #164, Volume #12 Wed, 5 Jul 00 13:13:01 EDT
Contents:
AEES-Cube Network ([EMAIL PROTECTED])
Re: Difference between A5/1 and A5/2 (Michael Schmidt)
Re: AEES-Cube Network (Mark Wooding)
Even an Amplified Boomerang Won't Cascade (John Savard)
Re: DES Analytic Crack (lordcow77)
RE: ANSI X9.62 and X9.63 (DJohn37050)
RE: Elliptic Curves encryption (DJohn37050)
Re: Help programming (dueyftw)
Re: Help programming ([EMAIL PROTECTED])
multiplication and inversion in finite fields (Stefan Karrmann)
Re: DES Analytic Crack ("Douglas A. Gwyn")
Re: AEES-Cube Network ([EMAIL PROTECTED])
Security of Adobe Acrobat Signature Handler ("Ed Suominen")
Re: A thought on OTPs ("Tony T. Warnock")
TRIPLE DES BENCHMARK ("Karim A")
Re: SV: SV: DES 64 bit OFB test vectors (Brian K. Ogilvie)
Re: AEES-Cube Network ("Paul Pires")
Re: Public-domain Blowfish ("Paul Pires")
Re: Security of Adobe Acrobat Signature Handler (David A Molnar)
libdes question (Bill Luckett)
Re: AEES-Cube Network (Mark Wooding)
Re: Diffie Hellman Primes : Speed Tradeoff Q (Anton Stiglic)
Re: multiplication and inversion in finite fields (Mark Wooding)
Re: Security of Adobe Acrobat Signature Handler (Larry Kilgallen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: AEES-Cube Network
Date: Wed, 05 Jul 2000 13:20:48 GMT
AEES-Cube Network is 1024-bit DES-like block cipher, where
cube looking composition of F-functions is used instead
of rounds.
Performance of AEES-Quadrate excluding I/O operations was measured
sending for encryption 410Mb in a loop. It is about 1.31 Mb/sec.
There is followning architecture of F-fubction:
F-function takes three input and three output
parameters and one additional integer parameter,
which means number of used sub-key.
256 byte key length
S-box is multiplication table of a group of the order 65536
8 sub-keys 256 bytes length
EP and P are sub-key dependent
XOR with current sub-key
XOR with left part of input
The Avalanche Effect of AEES-Cube Network.
A desirable property of any encryption algorithm is that a small
change in either the plaintext or the key should produce a
significant change in the ciphertext. Change only one bit in plain
text 1024 bit block leads to 46.3% changed bits in cipher text.
Change only one bit of key leads to 48.2% changed bits in cipher text.
Algorithm description and source code can be found
at <www.alex-encryption.de>
Please follow download or view link for 'AEES-Cube'.
Best regards.
Alex.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 05 Jul 2000 15:42:12 +0200
From: Michael Schmidt <[EMAIL PROTECTED]>
Subject: Re: Difference between A5/1 and A5/2
Hi,
The source code of both A5/1 and A5/2 is available at
http://cryptome.org/gsm-a512.htm.
Furthermore, http://www.scard.org/gsm contains info about A5/1.
I hope this helps,
Michael
Klaus Schmeh wrote:
>
> The A5 encryption algorithm (used for GSM cell phones) exists in the two
> versions A5/1 and A5/2. A5/2 is said to be less secure.
> Does anybody know what the difference between the two versions is?
>
> Regards
>
> Klaus Schmeh, [EMAIL PROTECTED]
--
===================================================
Michael Schmidt
===================================================
Institute for Data Communications Systems
University of Siegen, Germany
www.nue.et-inf.uni-siegen.de
===================================================
The 'Thin Client Security Homepage':
www.nue.et-inf.uni-siegen.de/~schmidt/tcsecurity/
===================================================
http: www.nue.et-inf.uni-siegen.de/~schmidt
e-mail: [EMAIL PROTECTED]
phone: +49 271 740-2332 fax: +49 271 740-2536
mobile: +49 173 3789349
===================================================
### Siegen - The Arctic Rain Forest ###
===================================================
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: AEES-Cube Network
Date: 5 Jul 2000 13:48:18 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Change only one bit in plain text 1024 bit block leads to 46.3%
> changed bits in cipher text. Change only one bit of key leads to
> 48.2% changed bits in cipher text.
So you have poor plaintext avalanche, and slightly better key
avalanche. That's not ever-so impressive.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Even an Amplified Boomerang Won't Cascade
Date: Wed, 05 Jul 2000 13:48:51 GMT
After reading Bruce Schneier's paper on the use of an amplified
boomerang technique for attacking 11 rounds of the inner core of MARS,
I wondered, since the amplified boomerang technique was only chosen
plaintext, if using the adaptive chosen ciphertext technique required
for the original boomerang method, whether this could be used to mount
an attack that could split a block cipher into _three_ pieces instead
of two.
Well, after playing with the idea, I saw why it still would not work.
However, even this failed attempt might be instructive, and so an
account of it is now added to my web page, at
http://www.ecn.ab.ca/~jsavard/crypto/co041001.htm
Note that the pages of my Cryptographic Compendium are now in a crypto
subdirectory. I needed to do this to keep my site organized, but it
does mean that many search engine links are broken for a while. Also,
while my site is still accessible without frames, I've changed, and I
believe improved, how you can use frames with the site.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Subject: Re: DES Analytic Crack
From: lordcow77 <[EMAIL PROTECTED]>
Date: Wed, 05 Jul 2000 06:54:17 -0700
I think that what he means by equations are the combinatorial
boolean relations that make up a specific instance of the well-
known NP-complete satisfiability problem for the case of DES;
that is one seeks to find a set of key values such that the
boolean relations between ciphertext and the known plaintext are
satisfied.
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: RE: ANSI X9.62 and X9.63
Date: 05 Jul 2000 14:07:26 GMT
The official copies are available for a (small) fee from www.x9.org. The
copies on the P1363 web site are old versions, used as input to P1363. If you
want a draft copy of active work items, you can attend a meeting, it is open to
public.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: RE: Elliptic Curves encryption
Date: 05 Jul 2000 14:08:31 GMT
Look at IEEE P1363 web site for latest version of P1363a which contains a
version of ECIES, based on Bellare-Rogaway's work.
Don Johnson
------------------------------
Subject: Re: Help programming
From: dueyftw <[EMAIL PROTECTED]>
Date: Wed, 05 Jul 2000 07:15:18 -0700
"Hans Husman" <[EMAIL PROTECTED]> wrote:
>
>"Jeff Moser" <[EMAIL PROTECTED]> wrote in message
>news:8jtaa6$iqo$[EMAIL PROTECTED]...
>> <[EMAIL PROTECTED]> wrote in message
news:8jt6ss$mlg$[EMAIL PROTECTED]...
>> > I have an idea for an encryption that takes one file to
encrypt
>> > another. So the key is the would be 3 pic files and each
byte of the
>> > pics would change the file to be encrypted. I have work out
an
>> > algorithm. And could use a lot of help to turn it into
code. Is
>> > their any other programs like this or am I wasting my time?
>>
>> Basically, it's a One Time Pad if you only use the pictures
once and only
>> once and therefore have new ones for each encryption. Also,
only the
>sender
>> and the receiver can know the pictures.
>>
> Better to use the picture to generate a key for a block
chiphers using a
>a secure
> hash function and a pseudo-random generator. If the picture
is secret it
>should
> be a better alternative compared to passwords used to
generate keys.
>Still if
> we have to keep the picture feel keept secret, so an even
better
>alternative would
> to generate a symmetric encryption key in a more
conservative way, by
>using
> several sources.
>
> At the RSA conferans in Europe a couple of presentations
was about the
> possibility to use pictures instead of passwords. Because
pictures might
> be easier to remember compared to traditional passwords.
>
> Hans Husman
> [EMAIL PROTECTED]
> Security Specialist
> Mynta Management & IT AB
> Sweden
>
>> If any of the above is not followed.. it'll be terribly
insecure.
>>
>> Cheers,
>>
>> Jeff
>>
>
> How come everone thinks of bits and not bytes? The progam
would take the first byte of each pic to change the first byte
of the file to be encrypted. First by adding pic1 first byte
then subtracting pic2, then adding pic3. Next using a offset
doing the same two more times. Each round would gen 3 bits for
each byte that would added to the file.
To brute force when the pics are 600x400 would be
1.10592e+17bits. Only the same three pics would decrypt the file
Duey
>
>
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Help programming
Date: Wed, 05 Jul 2000 14:34:01 GMT
In article <eId4hef5$GA.77@cpmsnbbsa08>,
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> It may be a good idea, it may be a bad idea. If the pictures
> to be used are in the public domain (as opposed to being
> completely secret and held only by the n parties involved)
> then the security is certainly not very good, I don't even
> have to look around to tell know that most websites house
> fewer than 2^32 (~4000000000) pictures, and under IPv4 there
> can be only 2^32 ip addresses, under these constraints, I
> can tell you quite certainly that there are fewer than 2^64
> (~16000000000000000000) pictures available, you can offer no
> more than 64-bits of security with publically available
> pictures, this is a problem since we currently consider
> anything under 80-bits to be too small to be usable.
> Joe
> Why 64bits? That a lot of pictures. The encryption would use all of
the bytes of three pictures. And would need the same three pictures to
decrypt. A one bit change in one of the pictures and you get mush for
an output.
Duey
> <[EMAIL PROTECTED]> wrote in message
> news:8jt6ss$mlg$[EMAIL PROTECTED]...
> > I have an idea for an encryption that takes one file to
> encrypt
> > another. So the key is the would be 3 pic files and each
> byte of the
> > pics would change the file to be encrypted. I have work
> out an
> > algorithm. And could use a lot of help to turn it into
> code. Is
> > their any other programs like this or am I wasting my
> time?
> >
> > Duey
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 05 Jul 2000 16:37:43 +0200
From: Stefan Karrmann <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.math.num-analysis
Subject: multiplication and inversion in finite fields
I am searching efficient algorithms to multiply and invert a number
in an given finite field. I know the extended Euclidean algorithm
to find the inverse and the multiplication using the representation
as polynomials. But these are not very fast on standard processors.
For finite fields with 2^(2^n) (n natural) elements, there is an
multiplication called Conway multiplication (see chapter 6
`The Curious Field On2' of the book `On Number of Games' by John
Horton Conway. XOR the addition and Conway multiplication are
known as "Nim sum" and "Nim product" respectively.) The multiplication
seems to be faster than the algorithm using the polynomials. Does
anybody know more about this.
Please CC to me directly,
thanks,
--
Stefan Karrmann
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: DES Analytic Crack
Date: Wed, 5 Jul 2000 14:19:53 GMT
> i.e. whether these are a set of equations that can be solved by
> simple methods of the genre of Gaussian elimination ...
No such luck. Why do you think it was a valid research project?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AEES-Cube Network
Date: Wed, 05 Jul 2000 15:13:58 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mark Wooding) wrote:
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > Change only one bit in plain text 1024 bit block leads to 46.3%
> > changed bits in cipher text. Change only one bit of key leads to
> > 48.2% changed bits in cipher text.
>
> So you have poor plaintext avalanche, and slightly better key
> avalanche. That's not ever-so impressive.
>
> -- [mdw]
>
Mark,
Thank you for your reply.
Let us clarify what is idea of Avalanche Effect.
I am not sure if all others and I understand it exactly.
What should be a change: a bit or known quantity of information?
For DES 64-bit one bit is 1.56% of information.
For AEES-Cube Network 1024 one bit is 0.098% of information.
To be able to compare with DES we should change 1.56% of information
in block that is 16 bit in AEES 1024.
I suppose that under such conditions Avalanche Effect of AEES-Cube
would be much better.
Another question may be if Avalanche Effect plays the same role in
the architecture of AEES-Cube Network?
Regards.
Alex.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Ed Suominen" <[EMAIL PROTECTED]>
Crossposted-To: comp.security
Subject: Security of Adobe Acrobat Signature Handler
Date: Wed, 5 Jul 2000 08:22:11 -0700
I am wondering about the security of Adobe Acrobat 4.0's signature handler.
It uses a 1024-bit RSA key and exports the public key to a PKCS #7
certificate, which gives you a 160-bit SHA1 "thumbprint." So far, so good,
but I'm not trusting my digital signature with anything but PGP right now.
Any comments on Acrobat or any other non-PGP signature software? Also, what
the heck is a PKCS #7 (.p7c file extension) certificate?
--
Ed Suominen
Registered Patent Agent
Web Site: http://eepatents.com
PGP Public Key: http://eepatents.com/key
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: A thought on OTPs
Date: Wed, 05 Jul 2000 09:29:12 -0600
Reply-To: [EMAIL PROTECTED]
"Douglas A. Gwyn" wrote:
> "Tony T. Warnock" wrote:
> > A simple version is to note that the characters of the key are independent
> > and identically uniformly distributed. Thus the probability of getting a
> > particular cyphertext character is independent of the corresponding
> > plaintext character and of the position in the message. This is based on
> > the fact that a convolution of a uniform distribution and any other
> > distribution on a circle is the uniform distribution.
>
> Unfortunately, that argument can also be applied to less secure systems.
Which less secure system satisfies the independence criterion? Identically
distributed is easy. Independence is rather difficult.
------------------------------
From: "Karim A" <[EMAIL PROTECTED]>
Subject: TRIPLE DES BENCHMARK
Date: Wed, 5 Jul 2000 17:41:56 +0200
Reply-To: "Karim A" <[EMAIL PROTECTED]>
Hi all,
Excuse me to disturb you with this fu@@*#g algorithm, but I had
to implement it for an application.
I've made several benchmarks on my PC P-II 450 196Mo,
and to encrypt a file of 12.4 Mo, the result is about 6 seconds.
What do you think about it ? Is it slow or quick, according to 3Des ?
Where can I found on the internet TripleDES benchmark results ?
Thanks in advance,
Karim
------------------------------
From: [EMAIL PROTECTED] (Brian K. Ogilvie)
Subject: Re: SV: SV: DES 64 bit OFB test vectors
Date: 05 Jul 2000 11:41:01 -0400
"Erik Olssen" <[EMAIL PROTECTED]> writes:
> > The smallest core will do up to 7.5 million encryption/decryption per
> > second(480 Mbits/s).
>
> > A fully pipelined ECB DES core will do up to 120 million enc/dec per
> second
> >
> > (7.68 Gbits/s).
> > This in FPGA, an ASIC will do better.
> That seem's fast enough!
>
> So do you have a retail source for this cores ?
We have fast DES cores, give me a call you want ASIC level
performance.
--
Brian K. Ogilvie LSI Logic Corp.
[EMAIL PROTECTED] Mail 200 West Street
781.290.0286 Tel Waltham, MA 02451
781.890.6158 Fax
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: AEES-Cube Network
Date: Wed, 5 Jul 2000 09:04:47 -0700
I'm sticking my neck out again but is seems to me that you're getting lost
in converting the units of a unitless measure. The avalanche in DES is (on
average) 32 out of 64 bits or 50%. Block size doesn't enter into it does it?
It's important to keep in mind what that 50% is a measure of. It is my
understanding that the architecture achieves "Full" diffusion, i.e. each bit
of the ciphertext has an equal chance of being changed by a change of one
bit in the key or plaintext. In my mind that means that 50% is the Ideal for
full diffusion. Why figure in some complex look at a bit unit being some
percentage of the information in a block? What does it get you?
Paul
<[EMAIL PROTECTED]> wrote in message news:8jvjb5$bg1$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Mark Wooding) wrote:
> > [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > > Change only one bit in plain text 1024 bit block leads to 46.3%
> > > changed bits in cipher text. Change only one bit of key leads to
> > > 48.2% changed bits in cipher text.
> >
> > So you have poor plaintext avalanche, and slightly better key
> > avalanche. That's not ever-so impressive.
> >
> > -- [mdw]
> >
> Mark,
>
> Thank you for your reply.
>
> Let us clarify what is idea of Avalanche Effect.
> I am not sure if all others and I understand it exactly.
>
> What should be a change: a bit or known quantity of information?
>
> For DES 64-bit one bit is 1.56% of information.
>
> For AEES-Cube Network 1024 one bit is 0.098% of information.
>
> To be able to compare with DES we should change 1.56% of information
> in block that is 16 bit in AEES 1024.
> I suppose that under such conditions Avalanche Effect of AEES-Cube
> would be much better.
>
>
> Another question may be if Avalanche Effect plays the same role in
> the architecture of AEES-Cube Network?
>
> Regards.
> Alex.
>
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Public-domain Blowfish
Date: Wed, 5 Jul 2000 09:19:14 -0700
Future Beacon <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> On Wed, 5 Jul 2000, Runu Knips wrote:
>
> > Future Beacon wrote:
> > > "Blowfish is unpatented, and will remain so in all countries. The
> > > algorithm is hereby placed in the public domain, and can be freely
> > > used by anyone".
> >
> > Whow. Three times the same answer for something which was
> > actually as clear as it can be.
> >
> > If the creator of the algorithm states it is free, who damned
> > who can have a patent on it ? You can't patent ideas which are
> > provably not your own ! And Blowfish is too simple to contain
> > something which is separately patentable.
>
>
> Runu,
>
> It used to be (and I think it still is the case) that one could
> patent a published idea within one year of the publication if
> there was evidence that the idea had been under secret development
> in accordance with patent rules. Apparently, Blowfish made it passed
> the year after publication. If it was fully disclosed, it would be
> in the public domain even if the inventor didn't say it should be.
1, Yes you have one year from publication or offer for sale IF you are the
inventor. Could be more complex if you are talking about filing foreign.
2, The inventors wishes are binding. If he had full rights to it and if he
published a clear declaration that the material was declared public domain
and if the material was clearly disclosed I wouldn't worry about it sticking
and I don't think the one year thing applies in this case. Any lawyers
listening it?
Note, he could still file on improvements if it had enough merit to stand
alone.
The problem (for the patent office, not the inventor) is that they have no
good way to record and research these grants along with the prior art when
they review new patents. Getting the patent and making it public domain
(Tovares?) does a much better job but you would have to be crazy to go
through that just to give it away.
Paul ( I second your disclaimer and hereby borrow it)
> I don't have recent updates of this part of patent law, I could be
> mistaken, I don't practice law, disclaimer, disclaimer, disclaimer.
>
> Be well.
>
> Jim Trek
> Future Beacon Technology
> http://eznet.net/~progress
> [EMAIL PROTECTED]
>
>
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: comp.security
Subject: Re: Security of Adobe Acrobat Signature Handler
Date: 5 Jul 2000 16:12:47 GMT
Ed Suominen <[EMAIL PROTECTED]> wrote:
> Any comments on Acrobat or any other non-PGP signature software? Also, what
> the heck is a PKCS #7 (.p7c file extension) certificate?
PKCS stands for Public Key Cryptography Standards. They are standards for
formatting and use of public key crypto produced by RSA Data Security in
cooperation with some other companies. There are a number of them; PKCS #1
specifies encryption padding techniques, for example.
Presumably the .p7c means that the cert's formatting and creation
conforms to PKCS #7.
Poking around on the RSA web site should turn up downloadable copies of
the standards.
-David
------------------------------
From: [EMAIL PROTECTED] (Bill Luckett)
Subject: libdes question
Date: Wed, 05 Jul 2000 18:32:31 GMT
Hi,
I hope this is not the wrong place to post this. I've checked most of
the posts and this may be only for implementers of encryption rather
than users. If so please acceopt my appology and exercise your right
to hate me. :)
I'm trying to write a function that will encrypt a string that's
passed in as a char *. I'm using Eric Young's libdes and the
des_ede3_cfb64_encrypt() library function. I'm casting the string to
an unsigned char * in the function call.
The documentation is a little schetchy and does not tell how to
innitialize the ivec and num parameters for des_ede3_cfb64_encrypt().
Can anyone enlighten me or point me to some example code? Keep in mind
that I'm a newbie to encryption so please keep any explanations basic.
Thanks, and again please forgive if this is not the proper arena.
Bill
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: AEES-Cube Network
Date: 5 Jul 2000 16:35:35 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Let us clarify what is idea of Avalanche Effect.
> I am not sure if all others and I understand it exactly.
>
> What should be a change: a bit or known quantity of information?
Let's consider a random permutation over n-bit strings E: { 0, 1 }^n ->
{ 0, 1 }^n (that is, a permutation chosen at random from the set of all
possible such permutations). Let x be any n-bit string. Then the
probability of any particular bit of E(x) being 1 is 1/2. Similarly, if
x' is a different n-bit string, then the probability of any particular
bit of E(x) XOR E(x') being 1 is 1/2. In other words, for random
permutations, we expect half the bits to change if we change the input.
That your cipher doesn't do this is unfortunate -- it means that it
doesn't behave like a random permutation.
> For DES 64-bit one bit is 1.56% of information.
>
> For AEES-Cube Network 1024 one bit is 0.098% of information.
Use DES and your cipher to encrypt 1 megabyte of information. Then each
bit of the ciphertext is the same proportion of the whole in both cases.
> To be able to compare with DES we should change 1.56% of information
> in block that is 16 bit in AEES 1024.
Do you see why this isn't the right thing to compare?
> I suppose that under such conditions Avalanche Effect of AEES-Cube
> would be much better.
I've just done a little experiment with DES. I picked a random DES key,
and some random plaintexts, and made single-bit differences in the
plaintext. I examined all single-bit differences in 512 plaintexts, and
took the mean of the Hamming distances between the ciphertexts, which
came out as 32.0143. I make that a bias of about 2^{-12}. You have
46.3% avalanche. That's a bias of almost 2^{-5}. Your block is 2^4
times larger than that of DES. Even if your argument were valid, which
it isn't, the block size isn't enough to explain your poor avalanche.
-- [mdw]
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Diffie Hellman Primes : Speed Tradeoff Q
Date: Wed, 05 Jul 2000 12:39:07 -0400
Mark Wooding wrote:
>
> David Hopwood <[EMAIL PROTECTED]> wrote:
>
> > Ideally yes, although it's worth pointing out that when p = 2q + 1 for
> > q prime, there's no reason to believe that working in the whole group of
> > size 2q is less secure in practice.
>
> Firstly, working in the subgroup means that exponents are one bit
> shorter, which improves efficiency to by an almost worthless amount. ;-)
When you work in the subgroup of order q, you don't want to take your
exponents
in the range [2, q-1], but in the range [2, e] where e << q-1 (with q:
1023 bits,
you can choose q to be 160 bits, like DSA does, or wathever you want.
You can
pick a bigger e latter on if you want, you can go up to e = q-1.).
>
> Secondly, consider an active attack against Diffie-Hellman whereby the
> adversary exponentiates both public values by q as they go by. i.e.,
>
> A --> M: g^\alpha mod p
> M --> B: g^{q \alpha} mod p
> B --> M: g^\beta mod p
> M --> A: g^{q \beta} mod p
>
> A and B will both compute the same shared value K = g^{q \alpha beta}
> mod p. They can confirm this by doing some test encryptions.
>
> M knows that g^{q \alpha} = +/-1 (mod p). If g^{q \alpha} = 1 (mod p)
> then K = 1. Otherwise, g^{q \alpha} = -1 (mod p), so K = 1 iff \beta is
> even, which is iff g^{q \beta} = 1 (mod p). Otherwise K = p - 1.
>
> Using a prime group order prevents this unpleasantness. (So does
> authenticating the actual Diffie-Hellman negotation rather than the
> shared secret.)
Yes this is was first described by van Oorschot and Wiener, in a
Eurocrypt 96
paper. It generalizes to using p = Rq + 1 (an attacker will have to
test R
values).
It's a good indication that one should work in the subgroup of order q.
>
> > It also makes parameter generation faster, because r can be fixed, and
> > then it's only necessary to find the smaller prime q such that 2qr + 1
> > is prime.
>
> Why do we have a problem if r is composite?
Lim-Lee primes, primes of the form p = 2*q_1*q_2*...*q_n + 1, where the
q_i's
are large work fine. You can simply work in one of the subgroups of
large prime
order.
Anton
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Crossposted-To: sci.math,sci.math.num-analysis
Subject: Re: multiplication and inversion in finite fields
Date: 5 Jul 2000 16:45:11 GMT
Stefan Karrmann <[EMAIL PROTECTED]> wrote:
> For finite fields with 2^(2^n) (n natural) elements, there is an
> multiplication called Conway multiplication (see chapter 6
> `The Curious Field On2' of the book `On Number of Games' by John
> Horton Conway. XOR the addition and Conway multiplication are
> known as "Nim sum" and "Nim product" respectively.) The multiplication
> seems to be faster than the algorithm using the polynomials. Does
> anybody know more about this.
I've seen a secret-sharing program for Linux which uses Conway
multiplication in a representation of GF(2^8) to do bytewise sharing.
It looked bizarre but interesting. I use a similar idea in Catacomb,
but using a standard polynomial representation. Both use precomputed
tables to make arithmetic in the field efficient, however: the Conway
version uses a big multiplication table and an inverse table; I use log
and antilog tables, which are much smaller but slightly slower to use.
Either method will work just as well for either representation.
For large fields, Conway's representation may be a win over polynomial
representations because the tables are unreasonably large. I'd like to
know more of the theory, though. I've not found any information on the
net despite throwing a few choice keywords at Google. For example, is
there an easy way to identify a generator of the multiplicative group of
a Conway-represented finite field?
Hmm. Has anyone patented doing cryptography in elliptic curves in
finite fields using Conway's representation?
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Re: Security of Adobe Acrobat Signature Handler
Date: 5 Jul 2000 13:49:12 -0500
In article <8jvmpv$hbj$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> writes:
> Ed Suominen <[EMAIL PROTECTED]> wrote:
>
>> Any comments on Acrobat or any other non-PGP signature software? Also, what
>> the heck is a PKCS #7 (.p7c file extension) certificate?
>
> PKCS stands for Public Key Cryptography Standards. They are standards for
> formatting and use of public key crypto produced by RSA Data Security in
> cooperation with some other companies. There are a number of them; PKCS #1
> specifies encryption padding techniques, for example.
> Presumably the .p7c means that the cert's formatting and creation
> conforms to PKCS #7.
PKCS #7 does not define a certificate format. It does, however,
define several message types and outline (loosely) a method of
using the PKCS #7 signedData type for transmitting a combination
of multiple certificates and crls from one entity to another.
RSA's web site provides the complete ASN.1 specification for PKCS #7,
and presumably ASN.1 is familiar to anyone who is attempting to write
software to read X.509 certificates in the first place.
------------------------------
** 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
******************************
