Cryptography-Digest Digest #851, Volume #12 Thu, 5 Oct 00 15:13:01 EDT
Contents:
Re: newbie pathetic question (Tom St Denis)
Re: It's Rijndael (Mok-Kong Shen)
Re: It's Rijndael (Mok-Kong Shen)
Re: My Theory... (Mok-Kong Shen)
Re: newbie pathetic question (Mok-Kong Shen)
Re: Q: does this sound secure? (Anton Stiglic)
Re: Microsoft CAPI's PRNG seeding mechanism ("Cristiano")
Re: Encryption problem ("Paul Pires")
Re: The best way to pronounce AES ("Paul Pires")
Re: Mathematical Problem (Mike Rosing)
Re: Encryption problem (Mike Rosing)
Re: Choice of public exponent in RSA signatures ([EMAIL PROTECTED])
Re: No Comment from Bruce Schneier? (SCOTT19U.ZIP_GUY)
Re: Encryption Project (Simon Johnson)
Re: On block encrpytion processing with intermediate permutations (Bryan Olson)
Re: Question on biases in random numbers & decompression (Herman Rubin)
Re: Simplified knapsack public key system (Mok-Kong Shen)
AES FIPS Ideas ("Brian Gladman")
Re: Democrats, Republicans, AES... (Albert Yang)
Re: Deadline for AES... (David Crick)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: newbie pathetic question
Date: Thu, 05 Oct 2000 17:00:00 GMT
In article <8rhk6u$r1u$[EMAIL PROTECTED]>,
"Danilo" <[EMAIL PROTECTED]> wrote:
> I wonder why is arithmetic coding not used to scramble messages ?
>
> If I arithmetic compress a message, but using a frequency table which
> is actually my key (both in the frequencies and in the order of the
bytes),
> wouldn't it be very hard to decrypt ?
>
> Excuse in advance for my pathetic ignorance of the matter.
Same reason why polyalphabetic ciphers are not secure.
Basically if you encode for example a english message with a huffman
code with a secret tree then I can exploit english biases in the output.
i dunno... plus block ciphers are funner.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Thu, 05 Oct 2000 19:26:09 +0200
Thomas Pornin wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > Dumb question: Would tripling with hardware also lead
> > to essential inefficiency? There could be a pipelining
> > effect, isn't it?
>
> Yes, but you triple hardware size, power consumption and latency.
> Another option is to divide by three the bandwidth.
>
> Either way, it is not an option on a gigabit ethernet.
Are you really so concerned about the hardware cost that
is constantly falling? Power cost may go up eventually
due to OPEC, but what's your bill? Through pipelining
there should be negligible effect on the throughput of
multiple encryption. What kind of critical realtime
applications do you have in which a latency really hurts?
(Are you sure that the transmission protocol wouldn't
sometimes give you inadmissible latency?) Just a few
thoughts of mine.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Thu, 05 Oct 2000 19:26:02 +0200
Volker Hetzer wrote:
>
> Mok-Kong Shen wrote:
> > Runu Knips wrote:
> > > If there would be another such contest in future, I would
> > > vote for making the round count a parameter, so everybody
> > > can choose higher or lower security, as they wish. This
> > > way one could select a higher number of rounds if one
> > > wishes. I don't know how much such a concept would
> > > actually cost in hardware implementations.
> >
> > I have expressed exactly the same wish several times.
> > There seems to be no reason why it can't be very readily
> > put into the standard.
> The AES's guys argument was that you can't simply attach or
> trim rounds without affecting key schedule and perhaps other
> properties too. So, each proposed number of rounds has to
> be analysed.
> Unless round flexibility is *designed* into the algorithm
> as proposed by Runu, modifying the round number makes
> IMHO little sense.
I have the impression that increasing rounds is no problem
for Rijndael. If this is done by its own team, it appears
to be not too risky in 'extrapolating' to say that the
result would also be o.k. just as at the present. Those
who are very conservative could apply a safety factor
to take into account of any presumed eventuality, I suppose.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: My Theory...
Date: Thu, 05 Oct 2000 19:25:56 +0200
Thomas Pornin wrote:
>
> My point is just the opposite. There are many organizations which
> have more resources than the NSA. Think about oil companies, for
> instance. Therefore there is no such thing as a cipher that only the
> NSA can break. Maybe, 30 years ago, the NSA was the only organization
> in the world to have both enough money and sufficient knowledge; but
> cryptographic knowledge is no more a military secret.
Even decades ago there were non-trivial attempts to
break that monopoly. Early in the eighties I was told
by an employee of a non-US bank that he was attempting
to use special hardware to break DES.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: newbie pathetic question
Date: Thu, 05 Oct 2000 19:42:51 +0200
Danilo wrote:
>
> I wonder why is arithmetic coding not used to scramble messages ?
>
> If I arithmetic compress a message, but using a frequency table which
> is actually my key (both in the frequencies and in the order of the bytes),
> wouldn't it be very hard to decrypt ?
Sometime back I suggested to prime the table of an adaptive
Huffman with a PRNG. Recently, I suggested to modify the
O/1 labels of a static Huffman with a PRNG. Both should
help. In my view such secret compressions are better to be
viewed as supplementary measures to enhance the security
rendered by a proper modern encryption scheme.
M. K. Shen
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: Thu, 05 Oct 2000 13:28:06 -0400
John Myre wrote:
>
> Anton Stiglic wrote:
> <snip>
> > This is a sort of a proof of a shared secret scheme.
> >
> > Anton
>
> Except the secret is too small: a 6 character password.
>
> JM
Right. I guess the ideal thing if you have such a small
secret is just to execute a secret key agreement scheme
to obtain a secret key K, and then have the client send
the password encrypted to the Server. Server computes
H(password) and compares that to what he has in the database.
In case attackers might have access to the database,
to avoid them brute forcing all the passwords (the passwords
are small as M. Myre
pointed out, so this is easy), you could have the Server
store H(ServerSecret || password), where ServerSecret is
something like a 128 bit secret that only the server
knows about.
Anton
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Microsoft CAPI's PRNG seeding mechanism
Date: Thu, 5 Oct 2000 19:23:02 +0200
> [...] do I have to trust Microsoft about their crypto capabilities ?
Without documentation is dangerous!
I use my implementation.
Cristiano
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Encryption problem
Date: Thu, 5 Oct 2000 10:36:28 -0700
ed dominguez <[EMAIL PROTECTED]> wrote in message
news:8ri6rs$kpk$[EMAIL PROTECTED]...
> What if this little game is web based, and if you
> found the correct price, you get instant feedback
> of your succcess ? You need to store the key
> someplace to check everytime someone makes
> a guess. So, the programmer, having access to
> the key, can copy paste it or write it down,
> take it home and do a brute force attack,
> and since the space is very small (its a number,
> a price), he will find the answer in no time).
I think you're missing something. You are implying that
1, A correct brute force can be confirmed easily.
2, There aren't many "good" answers to look for,
one of which is the right answer.
3, You are allowing them to guess an unlimited number
of times.
If I pad this secret out to 128 bits and encrypt
it with a 128 bit block cipher with a 128 bit key.
then you will (never) brute force it so stop worring
about brute force.
Richard Heathfield's suggestion had merit because
it commited each party to a single guess. The weakness
your problem has to brute force doesn't have to do
with encryption. The problem is that you are testing
an unlimited supply of guesses for them and you
have a small supply of wrong answers to hand out.
A Market driven approach is to charge for guesses.
This is frowned on in most states.
Paul
>
> Everyone can try a guess one time every day
> until one of them finds the correct price.
>
> btw, thanks to everyone for their answers.
>
> "Richard Heathfield" <[EMAIL PROTECTED]> escribi� en el mensaje
> news:[EMAIL PROTECTED]...
> > ed dominguez wrote:
> > >
> > > We were toying with the idea of creating a small "price is
> > > right" game at work. We have a hefty prize and we were deciding
> > > how to give it away and we thought about giving the price to
> > > that one that found out what the price is.
> > >
> > > Problem is, some always knows the price. So we decided
> > > to make this price random, although realistic. We decided
> > > to encrypt this and store it on a file. But then, brute
> > > forcing your way to the real price is trivial.
> > >
> > > How can I implement a program that will encrypt a random number but
> > > that its so secure that even the programmers cant brute-force it
> > > in small amount of time (days,weeks) ?
> > >
> > > I am not a student of crypto, so maybe this is a faq. I RTFF (faq)
> > > but couldnt find an answer for this.
> > >
> > > Thanks in advance
> >
> >
> > I'm not a cryptographer either, but I did think of a quick and dirty way
> > to do this, which has the makings of a fun "ritual"... (for people who
> > don't get out much).
> >
> > The program decides the random number. It doesn't display it, of course.
> >
> > The contestants are sorted into alphabetical order of surname (using
> > forename as a tie-break, and seniority or works number as a further
> > tie-break if need be). Each of them in turn walks solemnly past the
> > keyboard, and presses a single alphanumeric key (if there are very few
> > contestants, you might want them to press /two/ keys, or even three).
> > Each must remember the key(s) they pressed - and, if more than one, in
> > which /order/ they pressed it. The program then encrypts the number,
> > using their keypresses as a one-time pad, or via whatever symmetric
> > encryption mechanism you like (Serpent, TwoFish, AES, DES, or even CDX-2
> > ;-) - I nearly said RSA, which isn't symmetric, is it? Which shows how
> > much I know about crypto...). The ciphertext is stored on disk.
> >
> > A few days/weeks later, you collect your guesses. This is easy - each
> > contestant can write down their guess, and then they're all handed in at
> > once, in the time-honoured way of school examinations.
> >
> > Then - guess what? They all walk past the keyboard again, in the same
> > order, to rebuild the key. The program fetches the ciphertext off disk,
> > decrypts, and displays the answer.
> >
> > In other words, you divide the secret up amongst the contestants.
> >
> > Given that your secret need only last a few days or weeks, I'd guess
> > this is pretty secure, especially as the payoff for cracking it is,
> > presumably, relatively low (i.e. I presume we're not talking about, say,
> > ten thousand pounds/dollars). Nonetheless, I'd be interested to hear of
> > any high-speed, low-cost cracks against this proposed solution. (Let's
> > say, cracks that would take less than a week, with a modern PC, for ten
> > people with two letters each, giving us a keyspace of 20^(26 + 10).)
> >
> > [ Rubberhosing would work, of course... ;-) ]
> >
> >
> > --
> > Richard Heathfield
> > "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> > C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> > K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
>
>
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: The best way to pronounce AES
Date: Thu, 5 Oct 2000 10:43:59 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> JPeschel wrote:
> >
> > Mok-Kong Shen [EMAIL PROTECTED] writes:
> >
> > >As far as I know, the 'standard' British
> > >English is the Oxford English. Which is the corresponding
> > >one for American English?
> >
> > What do you mean by "the Oxford English?" You are
> > asking about dictionaries? You are asking about
> > formal, colloquial, or slang usage? Dialects?
>
> I think what I was questioning corresponds to 'dialects'.
> There is normally in each country a dialect which is
> considered by the majority to be in some sense pure,
> elevated, etc. and is prefered in theatres, news broadcasts,
> teaching, etc. For Chinese, for example, this is the
> Peking dialect. I like to know what is the corresponding
> one for American English.
You are going to think that this is a snide remark
but it is really what I believe. The name of the dialect
you are searching for is the Hollywood dialect. Once a
society develops Mass-media, All laws of language
evolution must change. Think about it. We, as a
country have only been stable (Not wildly expanding
and absorbing new identities) for about 100 years.
T.V. has been with us (in a major way) for 40 of them.
Paul
>
> M. K. Shen
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Mathematical Problem
Date: Thu, 05 Oct 2000 12:50:33 -0500
David A Molnar wrote:
> Ah, looks like it has. or at least the "original."
> Check Helger Lipmaa's excellent page of links:
> http://www.tml.hut.fi/~helger/crypto/link/public/mceliece.html
Yes, thanks for the pointer! For some reason I thought that was a
symmetric system.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Encryption problem
Date: Thu, 05 Oct 2000 13:04:37 -0500
ed dominguez wrote:
>
> What if this little game is web based, and if you
> found the correct price, you get instant feedback
> of your succcess ? You need to store the key
> someplace to check everytime someone makes
> a guess. So, the programmer, having access to
> the key, can copy paste it or write it down,
> take it home and do a brute force attack,
> and since the space is very small (its a number,
> a price), he will find the answer in no time).
>
> Everyone can try a guess one time every day
> until one of them finds the correct price.
Do 2 things. The first is to pick a unit of money
that requires a lot of digits. Like Yen or Lira,
but make something up is even better. If you have
a "realistic" price of 100,000,000,000 +/- 1e10
you have enough digits that brute forcing won't find
it too soon by 1 person.
The second thing is to have only 1 person encrypt
it and they can't win. As long as the programmers
don't have access to the key, they can't just unlock
the price.
Additional combinations of what others have said will
help too. Have fun!
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Choice of public exponent in RSA signatures
Date: 5 Oct 2000 14:09:55 -0400
> Thanks to Pierre Vandevenne for pointing out the paper:
> Arjen Lenstra, Eric Verheul: Selecting Cryptographic Key Sizes
> <ftp://ftp.sunet.se/pub/security/docs/crypt/cryptosizes.pdf>
> which contains:
"There is evidence that the equivalence (..of factoring and
RSA..) does not hold if the (..public exponent is small..).
Based on recent results in this area the public exponent for
RSA must be sufficiently large. Once popular values such as
3 and 17 can no longer be recommended, but commonly used
values such as 2^16+1 = 65537 still seem to be fine."
Well, not equivalent would mean that from finding cube roots one cannot
(in polynomial time from the cube roots) factor (while it is easy to find
cube roots from factoring). That doesn't mean finding cube roots is
"easier" - just not "equivalent."
Finding square roots is equivalent to factoring.
Is there evidence that finding cube roots mod n (n=pq, p,q distinct,
unknown, large primes) is *much easier* than finding square roots (that
is, than factoring)?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: No Comment from Bruce Schneier?
Date: 5 Oct 2000 18:10:42 GMT
[EMAIL PROTECTED] (Runu Knips) wrote in
<[EMAIL PROTECTED]>:
>Mok-Kong Shen wrote:
>> John Savard wrote:
>> > But he only visits sci.crypt to post occasionally, and he may be busy
>> > right now.
>> He might be scared away by the massive chosen plaintext
>> attack launched by someone to crack his recent post.
>
>Hehe.
>
>According to his "Applied Crypto", he uses killfiles.
>
>And he states the reader will learn to use them fast,
>if he or she starts reading sci.crypt, too.
>
>Hopefully I'm not in it...
>
I think his use of killfiles is phony. My understanding
is that he claims I am in a killfile but yet he complains
to others in private about what I write. I think he wishes
others would put me in killfiles since Mr BS does not really
want to learn all about cypto or have people exposed to views that
differ from his skillful guiding of new people trying to
learn somthing about encyption. I have only placed one person
in mine twice put after a week I take it out. I guess I
learned that from MR BS that I can read his comments and
pretend I did not. But even this little trick makes me
feel somewhat dirty. I guess that is why I never became
a manager. Its hard for me to lie. Except when playing poker
there is is a must.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Encryption Project
Date: Thu, 05 Oct 2000 18:19:26 GMT
Here is what i would do.
We can solve this problem easily by using Symetric and Asymetric
cryptography.
To start, the users file is encrypted with the hash (MD5) of the user's
login key, with some symetric algorithm. This system will allow the
administrator access to the user's file, while keeping cyber terrorists
out.
Here's how it works, there are two hashes, first there is an one-way
function and second there's a public key algorithm used as a hashing
function.
When a user requests to see their details. The two computer's first
collect the one way hash of the users password (obtained on the client
side by hashing the users key) and set this as the password to some
block cipher.
The two computers then send each other a randomly generated digit equal
in length to the size of the block. They XOR their own and the one they
recieved from the other party. This XOR becomes the IV (assuming CBC
mode) for this session.
The client sends the server the key. The server hashes thid key and
checks it against the users password hash. The server then decrypts the
user's information using the hash of the passkey as the key to some
symetric algorithm.
This (should :) )protects the system against a man-in-the-middle
attack, but what about the hashes -> they could be stolen?
To solve this we can use public/private key crypto.
First off, *ALL HASHES ARE ENCRYPTED USING A PUBLIC KEY*
The private key is encrypted using a symetric key algorithm on the
server. when the server starts up, it prompts the user to enter the
password to this encrypted key. Providing you're RAM is secure, the
resultant system should be.
That's it.
Any suggestions?
---
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Thu, 05 Oct 2000 18:27:28 GMT
Mok-Kong Shen wrote:
[...]
> Now please tell me what if there is no permutation
> at all and you have before you the original block cipher
> and you use a chosen ciphertext on it. Would that involve
> less work or more work than in the case with permutation as
> I described? I like to have a definite answer and a tiny
> bit explanation for that.
If you think your question is so important, why are you
unwilling to work on it? I think it's nonsense, based on not
studying the issues. How much work is it to break an
unspecified block cipher? Have you even thought about whether
the question is well-formed enough to make sense?
> Please do answer my question this
> time. If you really want to 'laugh', as you indicated in
> the following part that I snipped, you can do that much
> much better later on, if indeed you succeed to win your
> arguments. I am not used to discussions where people don't
> express their direct opinions. We are discussing science,
> not politics or theology, etc.
I see nothing in your writing that qualifies as science. I
explained one way your system fails as directly as I could in
my very first post in the thread. I later provided further
detail when it seemed unclear to you. I see no evidence that
you made any serious attempt to understand either what I wrote
or the subjects you brought up yourself. In one case, I
believe you deliberately played dumb, claiming that you could
not understand my language.
> > > The seed of PRNG is of course not to be reset, as I
> > > mentioned previously several times.
> >
> > Then you'll inevitably lose synchronization between sessions.
>
> There is fortunately a tradeoff of disadvantage/advantage.
> The loss of synchronization allows namely the detection of
> the attack, which cannot be detected for the original block
> cipher under the same chosen ciphertext attack. Depending
> on the application, the gain may even overweigh the loss.
The point is that the scheme inevitably loses synchronization
even in the absence of any attack. How would you handle two
simultaneous streams? If we have some stored ciphertext, how
would we know what state to use to decrypt? If we backs up
keys, how would we restore the PRNG state? If you need a
different state for each message or session, you can either
describe the mechanism that provides it or state that the
system depends on an outside means.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: Question on biases in random numbers & decompression
Date: 5 Oct 2000 13:30:49 -0500
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>Ray Dillinger wrote:
>> Ray Dillinger <[EMAIL PROTECTED]> wrote:
>[snip]
>> : or, you could try coming up with something sneaky... eight bits
>> : is a range of 256 numbers, and five trits is a range of 243 numbers.
>> : 256 = 243 (5 Trits) + 9 (2 trits) + 4 (2 bits). So you could take 8
>> : bits at a time and behave like this:
>> : 0-242 -- straight conversion to 5 trits, with no losses.
>> : 243-251 -- subtract 243, convert the difference into 2 trits
>> : 252-255 -- subtract 252, use these 2 bits in your next batch
>> An analogy of this in 32 bits exists, of course. It's just annoying
>> to find it.
>> 2^32 = 4294967296
>> 3^20 = 3486784401
>> so if the 32 bit number is 3486784401, you can take 20 trits out of it.
>> 2^32 - 3^20 = 808182895
>> 3^18 = 387420489
>> so if the 32 bit number is in the range 3^20 to 3^20 + 3^18,
>> you can push back a zero into your reserve of bits and get 18 trits.
>> if the 32 bit number is in the range 3^20+3^18 to 3^20+(2* 3^18)
>> you can push back a 1 and get 18 trits.
>> Et cetera.... the more you are willing to remember and work
>> with, the less throwing away you'll have to do. This approach
>> will actually "salvage" trits out of the reservoir of bits that
>> would otherwise be thrown away. It may be possible to make the
>> system yield more trits out of these thrown-away bits, but it
>> would be pretty hard to make sure in that case that the trits it
>> yielded were in fact unbiased.
>> Ray
>> Bear
>Thanks, this looks pretty cool. I think this is what I'll use for the
>part where I need to generate random trits.
There is a general way to increase efficiency, and it is
relatively easy to carry out. It does as efficient a job
as possible in producing random trits (or any other base)
if the bits (or whatever the input base is) cannot be
restored. The algorithm is simple and direct. Pushing
back bits will do even better.
So let us look at 32 bits; there are better choices. We
find that 2^32 = 102002022201221111211 in base 3. Now look
at a random number from 0 to 2^32-1, and compare it with
this number, which must be larger. There is a first place
where they differ. Then use all trits in less significant
places. The expected number of trits obtained is less than
the information bound by at most 3/2 (in general b/(b-1),
where b is the base, and this is without returning any bits.
This works in general. If one has random decimal digits
to generate bits from, use the procedure. Now it pays to
choose the parameters so the the number of equally likely
cases is just larger than a power of the output base, so
it would be better to use 2^27 = 100100112222002222.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Simplified knapsack public key system
Date: Thu, 05 Oct 2000 20:53:53 +0200
John Bailey wrote:
>
> US4306111: Simple and effective public-key cryptosystem
>
> Lu; Shyue-Ching , Chung-Li, Taiwan
> Lee; Lin-nan , Germantown, MD, assigned to:
> Communications Satellite Corporation, Washington, DC
> http://www.patents.ibm.com/details?pn=US04306111__
> Described as:
> A public encryption key (c1, c2, r) in which r is the product of two
> relatively prime numbers, and in which c1 and r, as well as c2 and r,
> are relatively prime numbers, is used in an encryption algorithm
> x=c1 m1 +c2 m2 (mod r). The decryption algorithm will be equivalent to
> solving simultaneous linear equations derived from the encryption
> algorithm. Thus, both encrypting and decrypting are quite simplified
> while still maintaining a high degree of security.
> (end quote)
A superficial look leads to a tiny point that I guess is
not entirely 'exact' in the document. They say that the
quantity a_11*a_22 - a_12*a_21 is required to be nonzero.
However, since the inverse of that in Z_r is needed to
decode, that quantity needs to be relatively prime to r.
I don't know but I conjecture that one needs to carefully
investigate whether the a's (and hence c1 and c2 that
give rise to them) are otherwise entirely free of
constraints that should be observed for avoiding eventually
conceivable weak situations.
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: AES FIPS Ideas
Date: Thu, 5 Oct 2000 19:43:50 +0100
The NIST team have put up an 'AES FIPS Ideas' area within the AES discussion
forum at:
http://aes.nist.gov/aes/default.htm
There have been several 'wish list' ideas discussed here in recent days
which could now be put to NIST using this mechanism.
Brian Gladman
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Democrats, Republicans, AES...
Date: Thu, 05 Oct 2000 19:02:42 GMT
For some reason, "warm fuzzy feelings" and Nazi soldiers don't seem to be
something I can utter in the same sentence without feeling a bit strange...
No?
Albert
Joseph Ashwood wrote:
> > As a historical query, does anyone know if "warm, fuzzy feelings" were
> > linked to cryptography before the publication of "Applied Cryptography"?
> Lacking proof, I'd say that Enigma gave the Germans warm-fuzzies (probably
> not that word), and they obviously trusted that above the information
> leakage.
> Joe
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: Deadline for AES...
Date: Thu, 05 Oct 2000 20:03:11 +0100
Mok-Kong Shen wrote:
>
> > Would you please point out what is incomplete in the documentation of
> > *any* of the finalists?
>
> The most conspicuous one and about which I have the
> most concern is that there are lots of numbers (numerical
> constants) whose derivation is not clear to the reader,
> i.e. these cannot be reproduced by them in some way. This
> provides an essential ground to nurish doubts about the
> absence of backdoors. Certainly it hinders a proper
> understanding and hence probably also analysis.
Section 7 of the Rijndael submission document explains the
reasons for the design choices. Is there anything in there
that you are not happy with?
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (OCT-2000 KEY) 0xE0F73D98 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
** 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
******************************
