Cryptography-Digest Digest #359, Volume #14 Tue, 15 May 01 17:13:00 EDT
Contents:
Re: Hughes DH variant (Randy Langer)
Re: Encryption/Hash Permissions ("Roger Schlafly")
Re: which public key algorithm is easy & gd to use? ("Roger Schlafly")
Re: Hughes DH variant (John Savard)
Comments appreciated. (Was, Bleaming Strock cipher) ("Paul Pires")
Re: which public key algorithm is easy & gd to use? (Kent Briggs)
Re: FYI: Results on EM attacks on smart cards (Mike Rosing)
Re: which public key algorithm is easy & gd to use? ("Roger Schlafly")
Re: Not a realistic thing to do......Why? (Doug Kuhlman)
Re: Hughes DH variant (Randy Langer)
More info on differential cryptanalysis on web site (John Savard)
Re: Hughes DH variant ("Roger Schlafly")
Re: OAP-L3: "The absurd weakness." (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: Randy Langer <[EMAIL PROTECTED]>
Subject: Re: Hughes DH variant
Date: Tue, 15 May 2001 16:45:44 GMT
Kent Briggs wrote:
> Tom St Denis wrote:
>
> > Good reason to invest in AC2..
> >
> > Page 515...
> > ------
> > (1) Alice choose a random integer x and generates
> > k = g^x mod p
> > (2) Bob chooses a random large integer y and sends Alice
> > Y = g^y mod p
> > (3) Alice Sends bob
> > X = Y^x mod p = g^yx mod p
> > (4) Bob computes
> > z = y^-1
> > k' = X^z mod p
>
> I've got some notes written in my AC2 margins on this protocol. I remember
> exchanging emails with both Hughes and Schneier several years ago on the
> subject:
>
> In Step 2, y needs to be relatively prime to p-1. If p is a strong prime such
> that (p-1)/2 is prime then y can be any odd number except (p-1)/2. If q is a
> prime factor of p-1 (as in DSA), then y can be any integer less than q. Then z
> = y^-1 mod q (using Extended Euclid) or z = y^(q-2) mod q using Euler.
>
> In Step 4, z = y^-1 mod (p-1)
>
> --
> Kent Briggs, [EMAIL PROTECTED]
> Briggs Softworks, http://www.briggsoft.com
Thank you! I'm collecting all this information. The input from various sources on
this newsgroup is much appreciated.
- RL
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Encryption/Hash Permissions
Date: Tue, 15 May 2001 15:58:43 GMT
"JustSoft" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi Mark,Roger
> We have a number of algorithms covering different encryption
> and hash routines, is there some definitve source like an
> association or organisation that we could peruse to determine
> the legitimate use of these algorithms in a commercial application.
Organizations that standardize algorithms (IEEE, NIST, ANSI,
ISO, etc) usually have some sort of statement about patents.
Nobody makes any guarantees tho.
> Our intention is to not use an algorithm where it has an active
> patent in force or a copyright notice excluding the use in commercial
> applications.
A copyright might cover an implementation, but it wouldn't restrict
use of an algorithm.
> Attempting to determine the right to use or restricted use in problematic,
> therefore any assistance in this area appreciated.
> Oh, I wondering if it helps to view the source to these routines, as these
> source files where downloaded from the internet.
Yes. Sometimes there are ambiguities in the description that are
only clarified by looking at source code.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: which public key algorithm is easy & gd to use?
Date: Tue, 15 May 2001 15:37:16 GMT
"Paul Crowley" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Kent Briggs <[EMAIL PROTECTED]> writes:
> > Paul Crowley wrote:
> > > I would vote DHAES for encryption, and Schnorr for signatures.
> > Isn't Schnorr still encumbered by a patent?
> Yes, unfortunately so; I meant only that it's the conceptually
> simplest secure signature scheme, not that I'd recommend it for real
> use.
Actually Schnorr signatures are not encumbered. Use them all you want.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Hughes DH variant
Date: Tue, 15 May 2001 17:25:53 GMT
On Tue, 15 May 2001 15:19:03 GMT, Randy Langer
<[EMAIL PROTECTED]> wrote, in part:
>Tom St Denis wrote:
>> I.e find someones public key y such that y = g^x mod p, then make up a
>> random k and send them g^k mod p, you can now both use g^xk mod p as a
>> private key. Simple effective and to the point. You can calc g^xk mod p
>> before talking to Bob as long as you know his public key .
>the variant you describe
>above is free of encumberences,
What he describes above _is_ Diffie-Hellman, the only difference is
that the public key of one party is posted in advance, rather than the
keys being exchanged during communications.
John Savard
http://home.ecn.ab.ca/~jsavard/
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Comments appreciated. (Was, Bleaming Strock cipher)
Date: Tue, 15 May 2001 10:41:37 -0700
First off, my appologies for the unfortunate
title of the the last thread. The post sat in my drafts
folder for a few weeks while I fretted over hitting
the send button. I had intended to change it before
posting.
So far, Scott Fluhrer found a "rather surprising
observation" The parity of a ciphertext block
correlates to a large degree with the parity of a
plaintext block. One small change and that goes
away entirely.
I was hoping for a few more comments or observations.
I realize that it is a rather bizzare construction but it does
run very fast (probably faster if I knew how to write code
better). An optimized version of this runs at 215 Mbits per
sec on my P2-233. ~ 8.6 clocks per byte.
I have copied the previous description below and the
one line that has changed is shown both ways, The old
line is bracketed with asterisks **.
The goal is to have a cipher that is:
1, relatively simple.
2, very fast.
3, internally obscure, one that does not reveal it's internal state
so easily for a chosen or known plaintext attack and one that
is safe against bit-flipping.
This cipher is simple (in code) and runs at 8.3 clocks per byte
Note: No file I/O.
The basic idea is to use two different sets of internal tables.
One table, "A", is dynamically changing and its values are used
only as location arguments for retriveing and storing values
from the plaintext, ciphertext and the other table, "B". Both
tables, A&B are split in two and handled seperately as A0,A1, B0,B1.
Each cycle, the operations performed on these table halves
alternate. Pointers are assigned to these table halves (A_old, A_new
& B_old, B_new) and to alternate, the pointers are just re-assigned
(swapped) for each cycle. So, here are the pieces:
"A0" and "A1" together comprise table "A" and are 64 element tables, each containing
the
values 0-63 initialized in a key dependent way. (unsigned char[75])
Note: 11 bits from the front of the array are duplicated at the end.
"B0" and "B1" together comprise table "B" and are each 64 element tables. Each element
is 32
bits wide and are also initialized in a key dependent way. (unsigned int[64]) .
"A_new" and "A_old" are pointers that can be set and reset to the A tables. (unsigned
char*)
"A_new_32" is a 32 bit wide pointer which is always set to the new "A" address.
(unsigned int*)
"B_new" and "B_old" are pointers that can be set and reset to the B tables. (unsigned
int*)
After every text block is processed (cycle) the pointers are re-set so that what
once was an old table becomes the new table and its values are then updated,
First "B" then "A". Cyphertext and plaintext are handled as 32-bit units and
are processed as blocks of the same length as a "B" table (64 elements).
To process a block:
Encrypt:
for (i=0, i<64, i++)
{
C[A_old[A_new[i]]] = B_old[A_new[i]] ^ B_new[A_old[i]] ^ P[i];
}
(Decrypt would be:
P[i] = B_old[A_new[i]] ^ B_new[A_old[i]] ^ C[A_old[A_new[i]]] ;)
Reset B pointers alternately. (odd is just the last bit of the cycle counter "x")
B_new = (odd) ? (unsigned int*) &B0 : (unsigned int*) &B1;
B_old = (odd) ? (unsigned int*) &B1 : (unsigned int*) &B0;
Update the Old (now named new) State B table. B1 in the case where the
cycle count "x" is even:
/* unsigned int wrapper = x ^ (B_new[0]<<27); Old code */
unsigned int wrapper = x ^ (B_old[A_new[0]]<<27); /* New*/
for (i=0, j = 1, k = 63; i<63; i++, j++, k--)
{
B_new[i] = (B_new[i]>>5) ^ P[i] ^ C[A_new[k]] ^ (B_new[j]<<27);
}
B_new[63] = (B_new[63]>>5) ^ P[63] ^ C[A_new[0]] ^ wrapper;
As before, find an "A" change argument (Tsel) from A vrs B
and smoosh it down to a 6 bit (0-63) value.
unsigned int Tsel = B_new[A_new[x & 0x3F]];
for (i=1; i<6; i++) Tsel ^= Tsel>>(i*6);
Tsel &= 0x3F;
Reset the A pointers alternately and set up the Byte shift according to Tsel:
A_new_32 = (odd) ? (unsigned int*) &A1[Tsel>>4] : (unsigned int*) &A0[Tsel>>4];
A_new = (odd) ? &A1[Tsel>>4] : (unsigned int*) &A0[Tsel>>4];
A_old = (odd) ? &A0[4] : &A1[4];
Update the Old (now new) A table. "Trans" is a table of 16
different relative permutations that could be inflicted on the
elements of A_new_32 by relocating four values (32 bit chunks)
at a time. One of the 16 transpositions will be selected and used
by the lower 4 bits of Tsel. The upper two bits of Tsel are used to
shift the pointer assignment (above) to one of four different byte
alignments. So, there are 64 different, relative element relocations,
for all 64 elements, one of which will be chosen by Tsel and used
to permute the values in the A_new table.
Tsel &= 0x0F;
for (i=0, j=1; i<16; i++, j++)
{
A_new_32 [Trans[Tsel][i]] = A_new_32 [Trans[Tsel][j]];
}
unsigned int swap = A_new_32 [0]>>24;
A_new_32 [0] = (A_new_32 [0]<<8) | swap;
A_new_32 [16] = A_new_32 [0]; A_new_32 [17] = A_new_32 [1];
One "block" cycle done, increment x and proceed until P or C is done.
Of course, there is no mention of how these tables are initialized in a key
dependent fasion, IV or salt usage or how the blocks are padded out
at the end of a message. A full description with simple and complete
versions of the source code is availiable. I'll have it up on a web site
for download soon but I'd be happy to E-mail to anyone who
wants it. PDF file ~250Kb.
If I have done this right, All an adversary gets from a known plaintext
is the knowledge that 64 pieces of each ciphertext relate to 64 pieces
of the plaintext in each corresponding block. He does not know the
mapping. Even if he did, he can extract the 64 pieces of internal state
that were XORed but these are composits of 128 pieces, constantly
changing and relocating dynamically and in a key and message
dependent way.
Paul
All rights are preserved. Some or all of this material may be
covered by patents held or filed for by the author or unknown
others. No presentment is made that the methodology contained
herein is suitable, safe or unencumbered for commercial use.
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: which public key algorithm is easy & gd to use?
Date: Tue, 15 May 2001 12:46:15 -0500
Roger Schlafly wrote:
> Actually Schnorr signatures are not encumbered. Use them all you want.
Isn't the Schnorr patent number 4995082? The title of it is "Method for
identifying subscribers and for generating and verifying electronic
signatures in a data exchange system". Or are you saying that RSA
Security does not charge license fees for its use?
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: FYI: Results on EM attacks on smart cards
Date: Tue, 15 May 2001 12:58:07 -0500
"Josyula R. Rao" wrote:
>
> As part of our work on side channel cryptanalysis, Pankaj Rohatgi and I have
> been investigating EM attacks on smart cards.
>
> At this stage, we are releasing part of our results in the form of a
> preprint. The gist of the preprint is that EM side channel carries more
> information than the power side channel and thus could be used to break some
> power analysis countermeasures. To avoid any controversy, the preprint only
> describes EM attacks on test code on an unspecified smart card.
>
> The paper entitled "EMpowering Side Channel Attacks" can be downloaded from
> either http://eprint.iacr.org/2001/037.ps
>
> or from our web site http://www.research.ibm.com/intsec/emf.html.
Before you submit it, add labels to your graphs. I think you've got frequency vs
amplitide in figs 1-3, but it's not clear. No, maybe it's sample time, or sample
number? At any rate, it's a good start and thanks for putting it up on line.
It's fun to read!
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: which public key algorithm is easy & gd to use?
Date: Tue, 15 May 2001 17:03:51 GMT
"Kent Briggs" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Roger Schlafly wrote:
> > Actually Schnorr signatures are not encumbered. Use them all you want.
> Isn't the Schnorr patent number 4995082? The title of it is "Method for
> identifying subscribers and for generating and verifying electronic
> signatures in a data exchange system". Or are you saying that RSA
> Security does not charge license fees for its use?
That is a patent on a smart card identification system, not a signature.
RSA Security does not charge fees for using Schnorr signatures.
------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Re: Not a realistic thing to do......Why?
Date: Tue, 15 May 2001 12:56:22 -0500
Keill Randor wrote:
>
<SNIP>
> at's it's 'best' - (depending on how you look at it), not even God
> would be able to crack it, or solve it - (i.e. if the key(s) and
> ciphertext were known)...
>
<SNIP>
Boy, I'd hate to be the intended recipient of that. If knowledge of the
key(s) and ciphertext don't allow you to decrypt, what does?
Doug
------------------------------
From: Randy Langer <[EMAIL PROTECTED]>
Subject: Re: Hughes DH variant
Date: Tue, 15 May 2001 19:39:53 GMT
John Savard wrote:
> On Tue, 15 May 2001 15:19:03 GMT, Randy Langer
> <[EMAIL PROTECTED]> wrote, in part:
> >Tom St Denis wrote:
> >> I.e find someones public key y such that y = g^x mod p, then make up a
> >> random k and send them g^k mod p, you can now both use g^xk mod p as a
> >> private key. Simple effective and to the point. You can calc g^xk mod p
> >> before talking to Bob as long as you know his public key .
>
> >the variant you describe
> >above is free of encumberences,
>
> What he describes above _is_ Diffie-Hellman, the only difference is
> that the public key of one party is posted in advance, rather than the
> keys being exchanged during communications.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/
I agree. But I've had it pounded into me that just about anything can be
patented, no matter how near-identical it is to some other patent. Some of the
software patents co-workers at prevous jobs have actually gotten away with have
left me stunned. I guess I'm not alone there, since Corporate Legal here is
somewhat hardlined about this. I know they're looking out for our interests, and
I don't buck them because of that, but this whole issue of software patents is
starting to get pretty irksome...
- RL
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: More info on differential cryptanalysis on web site
Date: Tue, 15 May 2001 19:44:34 GMT
On my web site, at
http://home.ecn.ab.ca/~jsavard/crypto/co041001.htm
I have added to my description of differential cryptanalysis.
Although I only define the techniques, without attempting to give
examples of why they might be used, I hope my definitions may be
easier to understand than those in the literature.
Having recently learned, through posts in this newsgroup, of the
importance of higher-order differentials, and truncated differentials,
in cryptanalysis, these are the techniques I've described there.
John Savard
http://home.ecn.ab.ca/~jsavard/
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Hughes DH variant
Date: Tue, 15 May 2001 18:53:42 GMT
"Randy Langer" <[EMAIL PROTECTED]> wrote
> I agree. But I've had it pounded into me that just about anything can be
> patented, no matter how near-identical it is to some other patent. Some of
the
> software patents co-workers at prevous jobs have actually gotten away with
have
> left me stunned. I guess I'm not alone there, since Corporate Legal here
is
> somewhat hardlined about this. I know they're looking out for our
interests, and
> I don't buck them because of that, but this whole issue of software
patents is
> starting to get pretty irksome...
Ok, fine, but the DH patent has expired. You can use DH or the
Hughes variant all you want. There are some variants of DH that
are patented, but none in common use AFAIK.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
Date: Tue, 15 May 2001 12:59:47 -0700
James Felling wrote:
>
> Anthony Stephen Szopa wrote:
>
> > James Felling wrote:
> > >
> > > Tom St Denis wrote:
> > >
> > > > "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> > > > news:3AF65E02.34D45
>>(SNIP)
> And if you believe that there is this bridge in NY you really need to buy.
There must be a very good reason why you have chosen not to
communicate.
Can't you just take one point then and explain yourself. Just
because you understand (?) what you mean you have not helped us
to understand what you mean by communicating it.
For instance, your idea of "Mixamixfile is a subgroup of the
generic permutation of 105 elements holding first element fixed."
Explain this in some detail as to what exactly you mean and how
this relates to your claims.
Just do this one point. Or choose perhaps a simpler one like,
"Scramble is a group" and tell us what you mean and how this
somehow supports your claims.
State your specific claim and describe what you mean by your
description then show us how this supports your claim.
I can't discuss what you are talking about if you cannot
communicate it.
Thank you.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
