Cryptography-Digest Digest #928, Volume #11 Sat, 3 Jun 00 01:13:01 EDT
Contents:
Re: XTR (was: any public-key algorithm) ("Paulo S. L. M. Barreto")
Re: Good ways to test. (Dennis Ritchie)
Re: Contest rule proposal (Terry Ritter)
Re: TC3 Update (Benjamin Goldberg)
Re: TC3 Update (tomstd)
Re: TC3 Update (Terry Ritter)
C implementation of CAST-256? (Dido Sevilla)
Re: Pomegranate, a simple base-independent generator (wtshaw)
Re: TC3 Update (David Eppstein)
Re: Cipher design a fading field? (wtshaw)
Re: Weak Keys in TC3 (David Hopwood)
PSS and PSSR patent status (was Re: XTR) (David Hopwood)
Re: TC3 Update (David Hopwood)
Notation (was Re: TC3 Update) (David Hopwood)
Re: No-Key Encryption (Greg)
Re: No-Key Encryption (Greg)
----------------------------------------------------------------------------
Date: Fri, 02 Jun 2000 23:19:01 -0300
From: "Paulo S. L. M. Barreto" <[EMAIL PROTECTED]>
Subject: Re: XTR (was: any public-key algorithm)
Sorry if this question has been already asked (no message I could
retrieve contained it).
Though the www.ecstr.com site doesn't make it clear, I guess XTR is in
the process of being patented. Am I possibly wrong?
Regards,
Paulo Barreto.
------------------------------
From: Dennis Ritchie <[EMAIL PROTECTED]>
Subject: Re: Good ways to test.
Date: Sat, 03 Jun 2000 02:27:33 +0000
Mark Wooding wrote:
> The most effective resource is a Good Cryptanalyst. Several of these
> can be contacted using the Net. They grow on trees.
Actually I think they are more like truffles than fruits.
Dennis
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Contest rule proposal
Date: Sat, 03 Jun 2000 02:33:17 GMT
On 2 Jun 2000 23:35:05 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>Terry Ritter <[EMAIL PROTECTED]> wrote:
>>
>> On 2 Jun 2000 22:14:27 GMT, in <[EMAIL PROTECTED]>, in
>> sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>>
>> >In fact, I'd go as far as to suggest that, while DES is a block cipher,
>> >DES-ECB (which maintains no extra state) is a stream cipher.
>>
>> I agree. It is certainly streaming the block.
>
>No. Not *the* block: the *sequence* of blocks which form the data to be
>enciphered.
The block *transformation*. It is the transformation which is
streamed. I don't know what it would mean to stream a block.
>ECB is a degenerate case, I'll admit, but once you look at
>it as a way to use a keyed permutation to encrypt an arbitarily-sized
>chunk of data my categorization may appear slightly more logical. Or
>maybe it won't and I'm just wrong and tired.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: TC3 Update
Date: Sat, 03 Jun 2000 02:52:03 GMT
Mark Wooding wrote:
> A finite field GF(q) (or, sometimes F_q, where the F is in
> blackboard-bold face, like Z when we're talking about the integers) is
> a set of q elements, upon which operations of addition and
> multiplication are defined. Both operations are associative and
> commutative; there exist additive and multiplicative identities
> labelled 0 and 1 respectively; each element has an additive inverse;
> each nonzero element has a multiplicative inverse; multiplication is
> distributive over addition. (Have I missed anything out?)
Umm, I might be mistaken, but *not* all nonzero elements have
multiplicative inverses... If an element has a common factor with q
that is greater than 1, then there is no multiplicative inverse, I
think. Consider GF(8), and the number 4. What number times 4 results
in the multiplicative identity? None, I think. If you were using a
prime number for q, THEN every nonzero element has a multiplicative
inverse, but that's not what you stated.
------------------------------
Subject: Re: TC3 Update
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 19:54:55 -0700
In article <[EMAIL PROTECTED]>, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
>Mark Wooding wrote:
>> A finite field GF(q) (or, sometimes F_q, where the F is in
>> blackboard-bold face, like Z when we're talking about the
integers) is
>> a set of q elements, upon which operations of addition and
>> multiplication are defined. Both operations are associative
and
>> commutative; there exist additive and multiplicative
identities
>> labelled 0 and 1 respectively; each element has an additive
inverse;
>> each nonzero element has a multiplicative inverse;
multiplication is
>> distributive over addition. (Have I missed anything out?)
>
>Umm, I might be mistaken, but *not* all nonzero elements have
>multiplicative inverses... If an element has a common factor
with q
>that is greater than 1, then there is no multiplicative
inverse, I
>think. Consider GF(8), and the number 4. What number times 4
results
>in the multiplicative identity? None, I think. If you were
using a
>prime number for q, THEN every nonzero element has a
multiplicative
>inverse, but that's not what you stated.
Actually he is technically right calling it "a field GF(q)" for
if q was not a primitive element (of some sort) there would not
be a multiplicative inverse (as you stated) making it not a
field.
So the implication is that q is prime?
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] (Terry Ritter)
Subject: Re: TC3 Update
Date: Sat, 03 Jun 2000 03:03:50 GMT
On Sat, 03 Jun 2000 02:52:03 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
>Mark Wooding wrote:
>> A finite field GF(q) (or, sometimes F_q, where the F is in
>> blackboard-bold face, like Z when we're talking about the integers) is
>> a set of q elements, upon which operations of addition and
>> multiplication are defined. Both operations are associative and
>> commutative; there exist additive and multiplicative identities
>> labelled 0 and 1 respectively; each element has an additive inverse;
>> each nonzero element has a multiplicative inverse; multiplication is
>> distributive over addition. (Have I missed anything out?)
>
>Umm, I might be mistaken, but *not* all nonzero elements have
>multiplicative inverses... If an element has a common factor with q
>that is greater than 1, then there is no multiplicative inverse, I
>think. Consider GF(8), and the number 4. What number times 4 results
>in the multiplicative identity? None, I think. If you were using a
>prime number for q, THEN every nonzero element has a multiplicative
>inverse, but that's not what you stated.
Clearly, GF(8) is not a field. See, e.g.:
http://www.io.com/~ritter/GLOSSARY.HTM#Field
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: C implementation of CAST-256?
Date: Sat, 03 Jun 2000 11:00:32 +0800
Does anyone know where I can find a reference implementation in C of the
CAST-256 algorithm described in RFC 2612? As you people can see from my
sig I do not live in the United States so it has to be from a source
that doesn't come from there, lest I and the site I get it from find
ourselves in violation of EAR. Thank you very much.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
Mobile Robotics Laboratory +63 (917) 4458925
University of the Philippines Diliman
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Pomegranate, a simple base-independent generator
Date: Fri, 02 Jun 2000 20:40:10 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> wtshaw schrieb:
>
> > In review of some classic ciphers, I again noted the means of generating a
> > numeric series part of the Gromark cipher. The method is simple addition
> > of digits and affixing the result to the end of the series. Be not
> > astonished, as a pseudorandom thingee, it repeats
>
> I believe that in our group I am probably not the single person who
> doesn't have access to books describing the Gromark cipher. Could
> you please give a sketch of the stuff involved here in mathematical
> terms? Many thanks in advance.
>
> M. K. Shen
I'm only interested here in part of it that refers to construction of a
digit series from a 5 digit seed. The book example is 23452 57977 26649
82037 02307 253.
To extend the sequence, add the first two character 2+3=5 to get sixth
digits, add the second and third digit 3+4=7 to get the seventh digit,
etc. the result is mod 10 so you only keep a single digit.
You could use A=0, Z=25, and mod 26 to get a series of values, but I
modified that. Look at the way the sequence below and see if you can
figure out what I am doing:
MKSYE SEYYE YEEEK KQWCO ASQUK MGYUG UCCYG CGKKS WEQCW UASWU QSMKG YSGSA
AUCWY AWAYY AYAAA CCEGI MQWEO CUSYO SOIIY SISCC WGAEI GOQWG OEWUC SYWSW
QQOIG YQGQY YQYQQ QIIAS KUEGA MIOWY MWMKK YWKWI IGSQA KSMEG SMAGO IWYGW
GEEMK S 183 MKS
At it so happen, MKS is a weak key, not any reflection on you. ABC is
better, even as you would not expect if to be:
ABCDF HKOTA JVLGI TQDLV QINAX PZOQP GHXPG OXWNV LKIXU HTDCY HCHLL UYHUH
DDMIR WBPZS QTKLF XSERY XRXQQ PIHZR ISBCV FZCGD KLPXC OBSRV LOIBY LBLOO
BERHX AGZIH JRSCL WPJNA YPAPR RIKBU NXJMI XWHVF ECLIP VZMWN KLZXM YLMLZ
ZMANO PDFUK BGNJV YGVGD DLIQV ANXPM ODCTH XCGBK JNVYK VKHHT QCLUP HLYUL
UHHDQ MVEJB PMSDG XLFKS RELXR KQDCV HZEIF OPVFM CTQXL PKCBO FRVYO VOLLB
........
DPYUP ULLHY UHUDD ZIEJO PZFQG XYFXF EELKR XDQCV UZRVS OPIFZ PGQXY PXPOO
FEVLB IOLYB LBOOR EHXNG MVUJR FCYJC JNNYC NCRRV KOHAX JZIKJ UVFRC YVCVZ
ZWAXY ZXZYY ZYZZZ AABC 1281 ABC
SHEN works:
SHENB NTQQI LIAVV KXSHJ RBSCU VWYRT WRMRP FFIWM PGKDX SPCRJ TVCEQ ZIWRJ
GPCRX TVQSQ NKKFZ WRGXP ZFOQG VGYDD GDILL NVYAK VAMHX OVGNL DVAQA XSSZR
MTSFH NZOWO PMMFD ATKFV FRCCY VGCVD KZAPL BRCOU VSKRP EDIVJ NFGYU NGUJV
CFGZJ NHKYW TKWRF IPYPZ PPQQG HIYPR IPIBZ ZLCAM PEODV UTARP VTIMQ DWEVB
........10980 SHEN
Some observations: If the alphabet is in normal order, it is easy to solve
for a long word that might occur if the series is used as a simple stream
key. You can work either way from a part that you know, rather convenient
if a long seed is used. You might coose a better set to actually hide
word lengths.
To muddy the waters, say that you used 36 alphanumeric characters, 10
digits and 26 letters. You could even use an alphanumeric seed. But, a
sequence of digits or letters harvested from the sequence, trashing
unneeded characters, would complicate breaking the generator. When you
try to hard for absoluted greatest efficiency in lots of cryptological
enterprises, you can simplify the attacker's job.
Just like LFSR's there are many possible plans, even with something like
non-binary logic involved.
One work note: To get a permuted alphabet, you could seed, waste some of
the sequence, then trap one of each usable character as it passed by,
tossing the others away; this is not most efficient, but, wayward in
concept, therefore useful. Consider that you could use a paragraph to
generate a series of alphabets based on words in a preselected size
range. I suppose that a random base alphabet is a must, which could be
based on a string seed itself.
--
If you wonder worry about the future enough to adversely limit
yourself in the present, you are a slave to those who sell security.
------------------------------
From: [EMAIL PROTECTED] (David Eppstein)
Subject: Re: TC3 Update
Date: 2 Jun 2000 20:44:18 -0700
tomstd <[EMAIL PROTECTED]> writes:
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > Umm, I might be mistaken, but *not* all nonzero elements have
> > multiplicative inverses... If an element has a common factor
> > with q
> > that is greater than 1, then there is no multiplicative
> > inverse, I
> >think.
GF(q) is NOT the same thing as the integers mod q, unless q is prime.
For instance, in GF(2^n), addition is bitwise exclusive or,
rather than addition mod 2^n.
In GF(q), it does not make sense to talk about common factors (the
elements are not integers) and really truly everything but zero has a
multiplicative inverse. In Z/q, as you note, there is no inverse when
gcd(x,q)>1. So this is another example of how GF(q) is not the same
thing as Z/q.
> So the implication is that q is prime?
No, there are fields GF(q) for any prime power like 2^128.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
[EMAIL PROTECTED] http://www.ics.uci.edu/~eppstein/
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Cipher design a fading field?
Date: Fri, 02 Jun 2000 20:54:47 -0600
In article <8h9c1b$cuv$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Sci.crypt,
>
> Given the results of the cipher contest, it appears that designing a
> strong block cipher is quite easy. Some 7 or 8 ciphers remain
> unattacked on the contest site. Even assuming that all of the ciphers
> have some weakness, it seems that finding a -practical- weakness is very
> difficult.
>
> That being said, is cipher design an obsolete enterprise? If a group of
> amateurs can design a strong cipher then certainly governments can.
> Since many government ciphers are available, what is the point of
> creating new ones?
>
I remember a local college that changed librarians. One holding her job
all too long, a few years, decided that she could save money by not
subscribing to anything she did not understand nor see a use for, you
know, all those technical journals. Many professors figured that the
issues they need were at the bindary, but they weren't.
We need a world full of self-defined security; the more people in on the
act, the more assurity that noone can keep track of everything.
Remember, those that want to control you are most likely to attack your
privacy, since they are the ones that need to hide their evil intent, and
cannot stand any conspiracy, or the threat of conspiracy, that might
undermine fulfilling their depraved vision of what the world should be.
--
If you wonder worry about the future enough to adversely limit
yourself in the present, you are a slave to those who sell security.
------------------------------
Date: Sat, 03 Jun 2000 05:13:30 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Weak Keys in TC3
=====BEGIN PGP SIGNED MESSAGE=====
"David A. Wagner" wrote:
> In article <8h8l53$964$[EMAIL PROTECTED]>,
> Scott Fluhrer <[EMAIL PROTECTED]> wrote:
> > tomstd <[EMAIL PROTECTED]> wrote:
> > > I found the first class of weak keys...If the 6 key words are
> > > all equal to -F(x+1), 0<x<7, then encrypting all zero makes an
> > > all zero output. The prob of getting this key is 2^-192 and it
> > > requires only one chosen plaintext to detect.
> >
> > If the weakness is "if you use a particular key, then encrypting a
> > particular plaintext will yield a particular ciphertext", well,
> > that's a "weakness" that's in all block ciphers. Or, in other words,
> > not particularly a weakness at all.
>
> Note that tomstd's weakness is a much bigger deal than yours,
> if you want to use the block cipher in Davies-Meyer mode to build
> a hash function. If you can find a key where 0 encrypts to 0 (and
> tomstd showed that you can, with much less than 2^192 workfactor),
> then you can start playing games with chaining attacks -- e.g., if
> the IV is 0, then prepending this special key to the message leaves
> the digest unchanged.
... which is arguably more a weakness of Davies-Meyer than of the block
cipher. Correct me if I'm wrong, but Davies-Meyer is a construction for
which it's difficult to prove anything concrete relating the security
of the resulting hash function to the security of the block cipher.
Personally, I don't like it at all; it assumes too much about the
cipher's key schedule (which is demonstrated by quite a few known attacks
against Davies-Meyer with particular ciphers, that do not significantly
affect the security of those ciphers for encryption).
> It will not be so easy to play these types of games if the special
> plaintext/ciphertext pair are unpatterned; the all-zeros plaintext/
> ciphertext have a lot of structure/symmetry.
I agree that a secure cipher shouldn't have structures like this,
although more because they may indicate deeper weaknesses, than because
they can be used directly.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOTiFrjkCAxeYt5gVAQGE3gf/TUSZu0prtzNSaGX6U4Z8pNCxC6VAZTZK
kvWeASyB9KbZjWRu+a1YpWZJmZ4g+iu5kxPjX5sXtKNrwK7dynkYd6EQoINbuCi5
K/1uL3uvUtoRYNPh6yUEUahp74xyD87hEdDlI73YvsSRKSYp0NLhpNWLAp2xdouF
azoTxsb54eHeEDCGDG9f7mFZyVg4kEaPmJONLHMTXdkkFmdbQIl96c55D9EKOmMN
MUpTjfIIHIPyG1eHkgsoGPjD4C8wUOzhtwk48JrGbPxaOwuCm5dGNc8JbAaGMOTZ
X2qcl93alwjiFk16+Ug6Vyaxkyszn041lVcJIWoGORkA1bnmhKT35A==
=i9I4
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 03 Jun 2000 05:15:01 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: PSS and PSSR patent status (was Re: XTR)
=====BEGIN PGP SIGNED MESSAGE=====
David A Molnar wrote:
> David A. Wagner <[EMAIL PROTECTED]> wrote:
[...]
> > All of these attacks are easily prevented by simply using padding,
> > which everyone should be doing anyway. As you say, they are not too
> > worrying in practice.
>
> As long as it's the right padding. :) Fortunately, as far as I know, OAEP
> is patent-free, and it has a proof of "being good padding" in the random
> oracle model.
>
> What dismays me is that the PSS signature padding does not seem to be
> patent-free...
PSS as standardised in P1363 is royalty-free; PSSR (the message recovery
variant) is not.
The patent pending on PSS is by the University of California; in a letter
to the IEEE archived at http://grouper.ieee.org/groups/1363/letters/UC.txt
it stated that:
If PSS is included in an IEEE standard,
[which it has been]
the University of California will, when that standard is adopted,
[which it has been]
FREELY license any conforming implementation of PSS as a technique
for achieving a digital signature with appendix. No registration fee
or other administrative procedure will be required.
The corresponding statement for PSSR is only that a license can be obtained
"under very reasonable terms and conditions."
Incidentally, my SCAN project (Standard Cryptographic Algorithm Naming), at
http://www.users.zetnet.co.uk/hopwood/crypto/scan/
includes patent references in algorithm entries (without any guarantee of
completeness, of course). These are linked to the corresponding pages from
the USPO's web site, or for non-US patents, IBM's site.
SCAN also includes references for the definition of each algorithm,
cryptanalysis, test vectors, reference implementations, etc. The categories
covered are
- message digests
- message authentication codes
- symmetric ciphers (with block cipher modes and padding methods)
- pseudo-random functions
- passphrase hashes and passphrase-based encryption methods
- asymmetric ciphers (with encoding/padding methods)
- signature schemes (with encoding/padding methods)
- various algorithms supporting public key schemes, such as key pair and
parameter generation (organised according to the Java Cryptography API,
which unfortunately is rather over-complicated in this area)
- random and pseudo-random number generators.
Corrections and suggestions for improvement are welcome.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOThTjTkCAxeYt5gVAQHYgQf9GDUtNvu3vSgkOUVQibS6mEDBpg3U42um
GBBWMMC9IPFtxfMps23Xge27piBxwxcqTNQ6ehd4uRouKAntjR7JmJsINM+kvAQT
YXtu5mDFSIrJlAx9IVbJbQ5jUFLFH4gKmo+yv+LGPO4ZILa/LvPU6aHeLwf8Iyu2
6QXYiW0V8gKdWwuSMAQ+nLXBbe4VIikAztB4AnfatvikOy9n3Hy+kY2vGVF+G/Kx
EGMuWSDx5Xdh/4iubO/kN2++NEnwjkJsy448RHuXJ0brBG7jParfAl7MDO5NfWYG
T2xBnTsCmB2RheqTceCpbcQojo7AyoW+704PJViVi7SD3SAN7E4oSw==
=oohl
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 03 Jun 2000 05:18:40 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: TC3 Update
=====BEGIN PGP SIGNED MESSAGE=====
tomstd wrote:
> In article <8h8vtp$p6m$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (David A. Wagner) wrote:
> >In article <[EMAIL PROTECTED]>,
> >tomstd <[EMAIL PROTECTED]> wrote:
> >> (multiplicative inverse in the galois field 2^128 mod p)
> >
> >Err, I can't see how to assign any meaning to that phrase.
> >Did you perhaps mean GF(2^128)? GF(p)? something else?
>
> Sorry... I am calculating the inverse of the input in GF(p)
> where p is a degree-128 polynomial (with coefficients taken mod
> 2).
>
> How should I have said that?
What I think you probably mean is that you take inverses in GF(2^128),
with elements represented in a polynomial basis, i.e. modulo a fixed
polynomial. "GF(p)" is almost always reserved for the case where
p is a prime integer, and you'll confuse people no end by using the
variable name p for other cases.
(As another poster pointed out, the representation of a group or
field element is important when the group/field operations are used
as part of a cipher with other operations, because there are
effectively implicit conversions that depend on this representation.)
Anyway, isn't this going to be *very* slow compared to other block
ciphers, if you need at least 4 inverses? (even using the "almost
inverse" algorithm in a polynomial basis, which AFAIK is the fastest
method in practice for software implementations)
Also, what makes you say that TC3 is provably secure against linear
and differential cryptanalysis? Just giving small bounds for the
probability of linear and differential characteristics *with respect
to a particular group and notion of difference*, is not a proof
of security against even reasonably straightforward LC and DC, much
less variants specifically adapted to that cipher.
(I'm inclined to be extremely skeptical of assertions that an algorithm
is "provably secure" that don't give a formal attack model, a precisely
stated set of assumptions, and a mathematical proof of the reduction from
an attack in that model to breaking the stated assumptions. I am a big
fan of the provable security approach to designing algorithms, which is
why I think it's very important that this term is only used where it
actually applies. Bounds on the probability of linear and differential
characteristics are not proofs in this sense at all, although they can be
the basis of an *argument* providing partial support for the security of an
algorithm.)
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOTiGzDkCAxeYt5gVAQFtvAgAy2WTvdWuL7rnyWmUP0IEW3GGRYXlrpmz
IYdnicMqxVJlSZibUdkzU3H9FXHxr40eEIcabgc90LMR67rCtkrvHZ8wXpgFAx2+
8ROD3xWSsJqCWK+CAvj4CITn4G/hSkOG3/kiqLXSfYibkJEu4Qij3qGxtTZA5/va
HTKMcx2uFNe+QcS+SkaZDN29EuyKQ6juJcpAJUD2UZFZRBrWDj9S8wLVL1wDDgUK
zlaagWk8FoB1QbDGSgVaE9jqqFihra3wbUGU3P5ipZ06n86cJkhgwGm+iznba44R
DBPLjuJBC5TRKskE2vzv1F/lkhvt+/NFYMAEuxPe2UPqUBxZ/IqYZw==
=gYHP
=====END PGP SIGNATURE=====
------------------------------
Date: Sat, 03 Jun 2000 05:20:03 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Notation (was Re: TC3 Update)
=====BEGIN PGP SIGNED MESSAGE=====
Mark Wooding wrote:
> tomstd <[EMAIL PROTECTED]> wrote:
>
> > 1. Explain the notation please :)
>
> A finite field GF(q) (or, sometimes F_q, where the F is in
> blackboard-bold face, like Z when we're talking about the integers) is a
> set of q elements, upon which operations of addition and multiplication
> are defined. Both operations are associative and commutative; there
> exist additive and multiplicative identities labelled 0 and 1
^ distinct
(This means that ({0}, +, *) is not a field, by convention.)
> respectively; each element has an additive inverse; each nonzero element
> has a multiplicative inverse; multiplication is distributive over
> addition.
[...]
> Also, F^*_q (the field without the zero element) is cyclic;
Technically F^*_q is the corresponding multiplicative group. I'm nit-
picking, though, because it has the same elements as the field without
the zero element, and the same definition of multiplication; it's just
that addition is not usually considered to be defined on F^*_q.
[...]
> Oh, yes, finally, if S is a set of elements, we tend to write that S x S
> is the set of pairs of elements of S, and, in general, that S^n is the
> set of n-tuples of elements of S, often represented, where S is an
> appropriate ring, as column vectors of n elements of S. And, just for
> completeness, P(S) (P is blackboard-bold again)
Actually it's normally in stylized italic - Unicode 2118h, FWIW.
(Oh, for decent Unicode support in mail/newsreaders.) Here is a somewhat
mangled ASCII-art version:
<pre>
/ --.
| / \
\| /
| __/
|
/ \
\_/
</pre>
> is the `power-set' of S, or the set of all subsets of S.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOTh5OjkCAxeYt5gVAQEP9Af+PduoXDl1BXteoqkddItrKZe8ThawKozO
FuAhdrPxNHCkn6Wjk+QAwSsbxtYKGim4ehXbY9+cnFVHsMUyjaPO/mBYw4KVp2Fs
q6zTpXCIjyVdkT17pH6Yf8GkdkozOnXF66Y8PXLS2iIziyqIOd0SKnO6Ql9xIixB
yfILuN0biSITwTp0as06bmZIgT+GHiESz8qWjNvRt7t0K3tAPu04W8W87TS89b3+
bqReqJY5ddw1bMeVwvit+hOIwlOGAzBuzQcjHZIIfn07OXspZab5TjnagMbHd07c
2NgbYuaiP/lv9HTXLixwlxYJMyTm6jLdDLfVQxxHn96SD9kEVYZQVw==
=i9AR
=====END PGP SIGNATURE=====
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: No-Key Encryption
Date: Sat, 03 Jun 2000 04:20:26 GMT
> > > 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 the 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.
Well, first they are keys because they unlock the secret. Second,
it is not a keyless cryptosystem but a keyless mistake. There is
no way that one can determine who is reading the message unless
a receiver's public key or a common secret key is known to the sender.
--
There is only one gun law on the books- the second amendment.
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: No-Key Encryption
Date: Sat, 03 Jun 2000 04:17:25 GMT
> >Unless I'm missing something, this doesn't make sense. An
> >eavesdropper would see M+A, M+B, and M+A+B,
> >and thus would able to recover M, A, and B.
> That's correct, and it is also true if multiplication replaced XOR.
Assuming that you can recover A+B from A and B. Given the
mixture generator, this is not a valid assumption.
> However, if exponentiation is used, then the Shamir three-pass
> protocol yields the Massey-Omura cryptosystem, which does work.
Yes, but does not MO use public keys? Otherwise, how can the
protocol ensure the correct audience? Without a public key
from the receiver, the sender has no way of assuring that the
send decryption phase is not going to yield the plain text to
an enemy. It is therefore useless.
> And I'm gratified to see that I correctly understood what he meant by
> "no-key encryption", although I'm still disappointed no one else seems
> to have done so.
You consider this a no key cryptosystem?
I would call it a no key mistake.
--
There is only one gun law on the books- the second amendment.
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
