Cryptography-Digest Digest #652, Volume #12 Mon, 11 Sep 00 04:13:01 EDT
Contents:
Re: Getting Started, advice needed (FAQs , yes I read them) ("Paul Pires")
Re: RSA Patent -- Were they entitled to it? (Terry Ritter)
Re: Getting Started, advice needed (FAQs , yes I read them) ("Douglas A. Gwyn")
Re: Getting Started, advice needed (FAQs , yes I read them) ("Douglas A. Gwyn")
PKCS7 ("Dmitry Kompaneets")
Re: Getting Started, advice needed (FAQs , yes I read them) ("Scott Fluhrer")
Re: RSA Patent -- Were they entitled to it? (Roger Schlafly)
Re: RC5-SAFE? - SAFEBOOT ("lala")
Re: RSA public exponent (Bill Unruh)
Extremely small DES - sanity check (Eric Furbish)
Re: RSA public exponent ([EMAIL PROTECTED])
Re: Getting Started, advice needed (FAQs , yes I read them) ("Paul Pires")
Weaknesses in this algorithm? (Patrick Schultz)
Re: Steganography and secret sorting (Mok-Kong Shen)
Re: RSA Patent -- Were they entitled to it? (Mok-Kong Shen)
Re: Camellia, a competitor of AES ? (Mok-Kong Shen)
MAC ([EMAIL PROTECTED])
Re: The ultimate laptop (Jeremy Buhler)
----------------------------------------------------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
Date: Sun, 10 Sep 2000 21:12:15 -0700
Why would anyone brute force the key. It seems to me that if
you can be made to encrypt some known material at the
beginning of a file, I get your key using only a pencil and
paper.
first tempKey = theKey;
> temp1 = data[counter] + tempKey;
> temp1 = ((temp1 << 19) | (temp1 >>13)) - 26087;
> temp1 = ((temp1 << 23) | (temp1 >> 9));
> tempData[counter] = temp1;
> tempKey = tempKey + temp1 - 26087;
Let's refrase the first cycle:
temp1 = plaintext + the honest to god key;
temp2 = ((temp1 << 19) | (temp1 >>13)) - 26087;
temp3 = ((temp1 << 23) | (temp1 >> 9));
ciphertext= temp3;
tempKey = tempKey + temp1 - 26087;
This is reversible.
If I have the first ciphertext block then...
temp2 = (Ctext>>23)|(Ctext<<9);
temp1= ((temp2+26087)>>19)|((temp2+26087)<<13);
If I have just the first plaintext block then:
temp1-plaintext = your key...
Unless I really screwed up here.
Feel safe?
Paul
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: RSA Patent -- Were they entitled to it?
Date: Mon, 11 Sep 2000 04:17:56 GMT
On Sun, 10 Sep 2000 16:14:36 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt Roger Schlafly
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>> In this section of law, I think the word "known" applies to an
>> invention "revealed without expectation of secrecy." In my view, even
>> if GCHQ had told NSA and NSA proceeded to implement the invention in
>> the US, the fact that it was kept secret would preclude the
>> application of 35 USC 102(b).
>
>Yes, the secrecy precludes application of 35 USC 102(b). But not
>35 USC 102(a).
Obviously I should have written (a). How irritating.
The idea that previously-secret development could invalidate an
existing patent seems a rather perverse reading of the law. Your
position could of course be supported by an actual case.
Once again, an invention obviously *is* "known" by many others beyond
the original inventor, and that amount of being "known" obviously does
not prevent a patent from being valid. We thus understand that
"known" is in fact not interpreted as *any* knowledge beyond the
inventor (as one *might* interpret "known"), but something else.
>If it makes you feel betters, patents are hardly ever broken
>under 102(a). Breaking the patent requires antedating the patentee's
>date of invention, and that date is not published with the patent.
Frankly, that sounds like a rather convenient explanation for why the
law does not in fact function as your interpretation would have it.
The issue certainly is *not* an inability to get date of invention:
Any time there is an interference, legal proof of dates is required of
both parties. The same issues occur in court when a PTO decision is
appealed.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
Date: Mon, 11 Sep 2000 00:32:33 -0400
Andy C wrote:
> Ok, now for the question - is this secure enough?
Assuming the obvious errors in the reconstructed source code are
fixed, the first observation is that the final swap of the first
and last (I guess?) words is readily reversed; it doesn't depend
on the key. That leaves just a loop that resembles a ciphertext
autokey, initialized by a 32-bit "theKey". It would be fairly
easy for an attacker to try all 2^32 possible theKey values until
one that works is found. If the words (including key) were wider,
then a more clever attack would be required, but one ought to be
possible since the algorithm is simple, consisting mainly of
constant operations (two fixed rotations, two fixed additions).
> I'm wondering about the "magic numbers" this appears to have in
> the << and >> and addition areas.
The << and >> are just used to obtain cyclic rotations of the word.
There is no particular reason -26087 (+39449) was used instead of
another constant with similarly nice bit pattern (1001101000011001).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
Date: Mon, 11 Sep 2000 00:41:40 -0400
Paul Pires wrote:
> This is reversible.
Yes, you got it essentially right. However, it does require that
the known plaintext be started from the end of the block, which
is a rather uncommon scenario. It does illustrate the general
danger inherent in using ciphertext autokey systems -- the effective
key (not the original seed key) is visible to the eavesdropper!
------------------------------
From: "Dmitry Kompaneets" <[EMAIL PROTECTED]>
Subject: PKCS7
Date: Mon, 11 Sep 2000 11:43:41 +0700
Hi all,
Does anyone know of a good pkcs7 implementation. I have got stuck with the
multi signature and multiwrappers in pkcs7.
A good example of encoded pkcs7 will also do. (Note: I have seen examples on
rsa, very poor ones)
I'd also like to discuss pksc7 with other implementors.
With best regards,
Dmitry Kompaneets
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
Date: Sun, 10 Sep 2000 21:52:39 -0700
Paul Pires <[EMAIL PROTECTED]> wrote in message
news:U_Yu5.60123$[EMAIL PROTECTED]...
> Why would anyone brute force the key. It seems to me that if
> you can be made to encrypt some known material at the
> beginning of a file, I get your key using only a pencil and
> paper.
>
> first tempKey = theKey;
>
> > temp1 = data[counter] + tempKey;
> > temp1 = ((temp1 << 19) | (temp1 >>13)) - 26087;
> > temp1 = ((temp1 << 23) | (temp1 >> 9));
> > tempData[counter] = temp1;
> > tempKey = tempKey + temp1 - 26087;
>
> Let's refrase the first cycle:
>
> temp1 = plaintext + the honest to god key;
> temp2 = ((temp1 << 19) | (temp1 >>13)) - 26087;
> temp3 = ((temp1 << 23) | (temp1 >> 9));
Actually, this should be:
temp3 = ((temp2 << 23) | (temp2 >> 9));
> ciphertext= temp3;
> tempKey = tempKey + temp1 - 26087;
Actually, this should be:
tempKey = tempKey + temp3 - 26087;
Neither of these affect your attack materially...
>
> This is reversible.
>
> If I have the first ciphertext block then...
> temp2 = (Ctext>>23)|(Ctext<<9);
> temp1= ((temp2+26087)>>19)|((temp2+26087)<<13);
>
> If I have just the first plaintext block then:
>
> temp1-plaintext = your key...
>
> Unless I really screwed up here.
>
Actually, this attack can be strengthened somewhat, in that it can be
applied to any block (and, it relies on a known plaintext block, rather than
a chosen one as you appeared to have implied). Suppose you know/guess the
value of plaintext block 10. Then, you use the above attack to derive the
value of tempKey at the start of the encryption of block 10. Then, looking
at the last two steps of the iteration for block 9:
tempData[counter] = temp1;
tempKey = tempKey + temp1 - 26087;
or, in other words:
NEWtempKey = OLDtempKey + CiphertextBlock - 26087;
(where NEWtempKey is the value of tempKey at the start of the encryption of
block 10, OLDtempKey is the value of tempKey at the start of the encryption
of block 9, and CiphertextBlock is the value of the 9th ciphertext block).
The attacker knows the ciphertext for block 9 (tempData[counter]), and he
knows the new value of tempKey, and so he can compute the previous value of
tempKey. And, he can work his way back to the beginning of the cipher.
> Feel safe?
As long as the attacker has no way of guessing a plaintext block, I
suppose...
--
poncho
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: RSA Patent -- Were they entitled to it?
Date: Sun, 10 Sep 2000 22:53:49 -0700
Terry Ritter wrote:
> The idea that previously-secret development could invalidate an
> existing patent seems a rather perverse reading of the law. Your
> position could of course be supported by an actual case.
You are welcome to post your own interpretation of 102(a).
> The issue certainly is *not* an inability to get date of invention:
> Any time there is an interference, legal proof of dates is required of
> both parties. The same issues occur in court when a PTO decision is
> appealed.
Yes, if there is an interference, there may be an invention date on
the record. But suppose you wanted to break the Amazon 1-click patent.
Assuming there was no interference (there usually isn't), then the
inventor might never have committed to a date. You could sue, depose
the inventor, and ask him. But then he might say that he had the
idea 20 years ago.
It is also hard to pin down what other people knew. Unless something
was formally written down or built, it is nearly impossible to say
that something really completely known.
So as a practical matter, patents get broken with published prior
art (102(b)).
------------------------------
From: "lala" <[EMAIL PROTECTED]>
Subject: Re: RC5-SAFE? - SAFEBOOT
Date: Mon, 11 Sep 2000 15:55:07 +1000
Thanks ++
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8phfvu$u4l$[EMAIL PROTECTED]...
> In article <xrVu5.55389$[EMAIL PROTECTED]>,
> "Paul Pires" <[EMAIL PROTECTED]> wrote:
> >
> > lala <[EMAIL PROTECTED]> wrote in message
> > news:8ph74o$t63$[EMAIL PROTECTED]...
> > > I didn't want start a flame war. But thanks both for advice. P.S.
> Tom when
> > > you say 'I would avoid the program at all costs.' - is this because
> it is
> > > trully insecure or too slow? I'm not trying to defeat the NSA here
> only
> > > ensure data is inaccessable from mid/large business for a year or
> two.
> >
> > My apologies for hijacking your question. Hope you got what you need
> > If not, follow up. My spleen is well vented and I promise not to
> nag :-)
> >
> > If I could guess at what Tom means, it would be that there are other
> well
> > regarded solutions out there that perform better. Kent Brigg's
> website seems
> > to be one good place to look. Just a guess, You didn't go into a lot
> of detail
> > about what your constraints, needs and preferences are.
> >
> > If I have miss-guessed him, I'm sure he'll gently correct me :-)
> >
> > Paul
>
> You guessed wrong, but that's quite alright.
>
> My problem is that it says a 1024-bit key and only uses 12 rounds.
> Personally anything under 16 rounds is not a good idea, and you can't
> use 1024-bit keys with RC5, well you could, but I wouldn't.
>
> It doesn't seem like a well thought out use of RC5.
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RSA public exponent
Date: 11 Sep 2000 06:23:23 GMT
In <8phdv0$s52$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Ed Pugh) writes:
]Bill Unruh ([EMAIL PROTECTED]) wrote:
]> If the same key is used to encrypt a number of messages of
]> a certain type and e is small then apparently there is a way of breaking
]> the key. So, yes, the messages can be important in breaking the key.
]Do I understand this correctly? This means that an RSA secret exponent
]can be determined by an attacker if "e is small" ? If so, this is news
]to me.
]How small is "small" ?
]Some older versions of PGP I think used 17 as a default value for e.
]So if I understand you, bill, then these keys can be broken by encrypting
]"a number of messages of certain type". Is there a specific method for
]doing this?
]Am I correctly interpreting your post, or am I misunderstanding something?
There was a thread here recently which argued that small exponent RSA is
weak in encrypting certain types of messages. However that the way in
which it is used to encrypt the secret key in PGP say is not weak.
The statement there was that e should have a length of about half the
length of N to be safe against these kinds of attacks. But remember that
the use of RSA in PGP is very specific-- it is only used to encrypt the
(random) secret key. Apparently the claim in that thread was that in
this use, the attacks used against small exponenet RSA did not work.
------------------------------
From: Eric Furbish <[EMAIL PROTECTED]>
Subject: Extremely small DES - sanity check
Date: Mon, 11 Sep 2000 01:28:18 -0500
Hello,
I'm looking to implement an *extremely* scaled-back version of DES in
hardware on a small integrated circuit (~5000 transistors, 2 metal
layers). I've been toying with the algorithm, and I've come up with a
design that should fit in my available space, yet still follow the basic
methodology.
I want to get the opinions of those much more experienced than I on
whether this is at all feasible. Obviously it will by no means be a
secure method, but that's not really the focus of the class (VLSI
design is). My design is as follows:
16 bit blocks, and 16 bit keys. The key would be permuted and reduced to
14 bits, split into 7 bit halves, and go through the normal rotation table
process. I'm assuming I would need to do 4 iterations (1/4 of the 16
rotations used for 28 bit halves). The (arbitrary) rotation table I've
chosen is:
Iteration Rotate By
1 1
2 2
3 2
4 2
The halves would be concatenated and permuted as normal.
The encryption process would operate on 8 bit halves, with 4 iterations as
above, following the normal Ln = R_(n-1), Rn = Ln_(n-1) xor
f(R_(n-1),Kn) process.
The f() function would expand its first argument to 12 bits, split it into
4 3-bit chunks (again, numbers arbitrarily chosen). The S-box lookup
would be done with (obviously) 4 S-boxes, using 2 bits as one reference
and the other bit as the other reference. The S1(B1)...S4(B4) would be
permuted as normal to produce an 8-bit output.
The final half-reversal and permutation would be as normal.
I suppose my real question is this: Can the S-boxes, permutation tables
and rotation tables be chosen arbitrarily and still maintain decryption
functionality? Obviously some choices would be much better than others as
far as security of the algorithm, but I'll worry about that later.
If these parts can't be chosen arbitrarily, is there a
(hopefully) simple method for choosing them?
Hopefully I haven't left out any details. I appreciate any feedback.
Thanks,
Eric Furbish
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA public exponent
Date: 11 Sep 2000 02:31:48 -0400
Rich Wales <[EMAIL PROTECTED]> wrote:
> Ed Pugh wrote:
> > Do I understand this correctly? This means that an RSA
> > secret exponent can be determined by an attacker if "e
> > is small" ? If so, this is news to me.
> My understanding of this attack is that if someone encrypts the same
> message "e" times, with "e" different RSA public keys, each of which
> uses the same public exponent "e", then it's possible to determine
> the original message without knowing any of the secret keys involved.
To be specific, suppose e=3 and the original message is x.
You have three messages: A=x^3 mod P
B=x^3 mod Q
C=x^3 mod R
where P,Q,R are the moduli.
NOTE that it is easy to find cube roots of integers.
The problem is finding cube roots MODulo P or MOD Q or MOD R (being able
to find square roots MOD n is provably enough to allow you to factor n
probabalistically - but anyone can find square roots of integers - use
your favourite routine, say, Newton Rhapson - and just use it until it
converges to the result (an integer, by assumption) - it is the
"mod n" which makes finding square roots mod n hard).
But one has the Chinese Remainder Theorem. You can find an M which is
M=A mod P, M=B mod Q and M=C mod R
or ... M=x^3 MOD (PQR)
(assuming P,Q,R are rel. prime in pairs - as they are certain to be (the
probability that they are not is infinitesimally small - and if they
weren't - one could use the Euclidean Algorithm to find a GCD which is a
factor of one of them and so factor at least one of the moduli and then
with the public exponent e=3, discover the private exponent for that
factored modulus and so be able to decode any message using that
modulus))
But ... x is between 0 and P, and between 0 and Q and between 0 and R.
So ... x^3 is between 0 and PQR.
Well, if you know that x^3 is between 0 and PQR and know an M=x^3 mod PQR
then M (actually its principal residue mod PQR) IS x^3 (IS x^3 - NOT just
x^3 mod something).
You now know x^3. NOT just x^3 modulo something.
Well ... once you know x^3 itself, it is easy to take its cube root and
find x. AHA! You found x! You decoded the original message.
This does not give you any of the private keys (unless the just about
impossible happens and P,Q,R are not rel. prime in pairs - that is, you
basically managed to guess a factor for one of the moduli).
[As mentioned, in PGP's RSA, for encryption to multiple recipients,
padding is used on the message=session_key so that one does not use the
"same" x.]
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
Date: Mon, 11 Sep 2000 00:17:06 -0700
Scott Fluhrer <[EMAIL PROTECTED]> wrote in message
news:8phpk5$plr$[EMAIL PROTECTED]...
>
> Paul Pires <[EMAIL PROTECTED]> wrote in message
> news:U_Yu5.60123$[EMAIL PROTECTED]...
> > Why would anyone brute force the key. It seems to me that if
> > you can be made to encrypt some known material at the
> > beginning of a file, I get your key using only a pencil and
> > paper.
> >
> > first tempKey = theKey;
> >
> > > temp1 = data[counter] + tempKey;
> > > temp1 = ((temp1 << 19) | (temp1 >>13)) - 26087;
> > > temp1 = ((temp1 << 23) | (temp1 >> 9));
> > > tempData[counter] = temp1;
> > > tempKey = tempKey + temp1 - 26087;
> >
> > Let's refrase the first cycle:
> >
> > temp1 = plaintext + the honest to god key;
> > temp2 = ((temp1 << 19) | (temp1 >>13)) - 26087;
> > temp3 = ((temp1 << 23) | (temp1 >> 9));
> Actually, this should be:
> temp3 = ((temp2 << 23) | (temp2 >> 9));
>
> > ciphertext= temp3;
> > tempKey = tempKey + temp1 - 26087;
> Actually, this should be:
> tempKey = tempKey + temp3 - 26087;
> Neither of these affect your attack materially...
Sorry for the typo's. I finally found an easy one to respond to
and was rushing like mad to post it before the real guns saw it :-)
>
> >
> > This is reversible.
> >
> > If I have the first ciphertext block then...
> > temp2 = (Ctext>>23)|(Ctext<<9);
> > temp1= ((temp2+26087)>>19)|((temp2+26087)<<13);
> >
> > If I have just the first plaintext block then:
> >
> > temp1-plaintext = your key...
> >
> > Unless I really screwed up here.
> >
>
> Actually, this attack can be strengthened somewhat, in that it can be
> applied to any block (and, it relies on a known plaintext block, rather than
> a chosen one as you appeared to have implied). Suppose you know/guess the
> value of plaintext block 10. Then, you use the above attack to derive the
> value of tempKey at the start of the encryption of block 10. Then, looking
> at the last two steps of the iteration for block 9:
>
> tempData[counter] = temp1;
> tempKey = tempKey + temp1 - 26087;
>
> or, in other words:
>
> NEWtempKey = OLDtempKey + CiphertextBlock - 26087;
>
> (where NEWtempKey is the value of tempKey at the start of the encryption of
> block 10, OLDtempKey is the value of tempKey at the start of the encryption
> of block 9, and CiphertextBlock is the value of the 9th ciphertext block).
>
> The attacker knows the ciphertext for block 9 (tempData[counter]), and he
> knows the new value of tempKey, and so he can compute the previous value of
> tempKey. And, he can work his way back to the beginning of the cipher.
Yep, that works too.
Thanks
Paul
>
>
> > Feel safe?
> As long as the attacker has no way of guessing a plaintext block, I
> suppose...
>
>
> --
> poncho
>
>
>
------------------------------
From: Patrick Schultz <[EMAIL PROTECTED]>
Subject: Weaknesses in this algorithm?
Date: Mon, 11 Sep 2000 00:25:25 -0700
I just had an idea of a way to combine the one-time pad concept with rc4
(i'm sure other symmetric ciphers would work too). I would like to know
if there are any weaknesses in this system that I'm not seeing.
encrypting:
1) xor the plaintext with a one-time pad
2) encrypt the one-time pad with rc4 using a random key that is the same
length as the passphrase.
3) xor the passphrase with the random key.
you would then create the message as a single continuous block of data
in this order: result of step 3, result of step 2, result of step 1
decrypting:
1) xor the passphrase with the beggining of the message
2) decipher half of the remaining message using the result of step one
as the rc4 key
3) xor result of step 2 with the remaining half of the message to
retrieve plaintext
if you use a good random number generator, the entire message should be
statistically random (I'm assuming that rc4, giving a random key and
random input, will generate random output; I'm not sure of that).
Therefore, a statistical attack based on patterns in the plaintext
shouldn't be possible. Also, because the ciphertext is all run
together, it would be impossible to tell the length of the key used,
making a keysearch attack that much harder. If anything I have said
here is incorrect, please tell me, I'm new to cryptography and this is
just an idea I had this afternoon.
-Patrick Schultz
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Steganography and secret sorting
Date: Mon, 11 Sep 2000 09:43:14 +0200
Matthew Skala wrote:
>
> Suppose you've got a file full of distinct records that don't have any
> particularly significant way of ordering them. As one example, some of
> the data files I'm dealing with for school right now are lists of
> combinatorial objects (in this case, graph embeddings) that don't have any
> really natural order: the interesting question is whether or not a given
> record is in the file at all, not where in the file it happens to be
> located. But when you store the file on a disk, you have to put the
> records in *some* order. A "standard" or "canonical" way of doing it
> would be to treat the records as binary or text strings and sort them
> lexicographically on that basis. But why bother sorting them at all?
> Why not just store them in whatever order they happen to be generated?
> Most of my files of such things are in apparently-random order.
[snip]
Transposition is one major technique of cryptography. So,
if you rearrange your items in some way unknown to the
opponent, you gain some security. A simple method is to use
a secret seed and a PRNG to do the permutation. The recipient
can inverse the permutation and get back the original stuff.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: RSA Patent -- Were they entitled to it?
Date: Mon, 11 Sep 2000 09:43:27 +0200
Terry Ritter wrote:
>
> Once again, an invention obviously *is* "known" by many others beyond
> the original inventor, and that amount of being "known" obviously does
> not prevent a patent from being valid. We thus understand that
> "known" is in fact not interpreted as *any* knowledge beyond the
> inventor (as one *might* interpret "known"), but something else.
I suppose 'known' means known to the general public (the trade,
the competitors). Of course, the colleagues of the inventor
know more or less of the invention, but that doesn't count.
If the colleagues are not friendly and turn to be competitors,
then the matter is complicated.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Camellia, a competitor of AES ?
Date: Mon, 11 Sep 2000 09:45:08 +0200
[EMAIL PROTECTED] wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > Why do you think that ISO should give priority to AES over
> > any other ciphers?
>
> 1. Because the US has, by far, the largest online economy. If the ISO
> simply ignored the existing US standard, we'd have the reverse
> situation to digital signatures. (Where the US standard is DSA, and
> the ISO standard RSA).
This is, I suppose, a highly US-centric view. In the general
assembly of United Nations, the US has one vote just as any
tiny country, if I don't err. Does one want to give priority
to e.g. MS so that its products dominate the market?
> 2. Because, overall, AES canidates have received _much_ more analysis
> than any other canidtaes.
It does not mean that a newcomer is inferior. The ISO has to
weigh and consider according to its guidelines. It is the
resposibility of each national standardization body
participating in the respective working group to forward
opinions and discuss and finally have the stuff determined
in the technical committee by country votes. The matter is
in fact rather complicated. Both science and politics are
involved, i.e. the decisions are only partly objective.
> 3. Because it's unlikely, in my opinion, that anything superior would
> suddenly crop up if submissions were solicited world wide.
Camellia, for example, is an improved E2, as far as I know.
It has quite good performances, if what it claims is true.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: MAC
Date: Mon, 11 Sep 2000 07:53:53 GMT
Hi all,
I have just been reading one of the post about MAC. However, i have no
idea what a MAC is? Could anyone explain it to me in a few lines?
Thank you,
Brice.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jeremy Buhler <[EMAIL PROTECTED]>
Subject: Re: The ultimate laptop
Date: Mon, 11 Sep 2000 08:03:22 GMT
Quoth Mok-Kong Shen <[EMAIL PROTECTED]>:
> to it in Science and New Scientists), claiming that a 1-kg
> ultimate laptop will be able to perform 10^51 operations
> per second on 10^31 bits and that that could be attained
[...]
> (and analysis) techniques. Matters like AES and its
> potential competitors clearly deserve more attention
> than what is going to be at the forefront of cryptology
> in the 22nd or 23rd century.
Actually, these kinds of bounds seem rather helpful for
cryptographers. Suppose I wanted to design a cipher to resist such an
"ultimate laptop". Assume that I'm sufficiently clever that any
attack has negligible advantage over a brute force keyspace search (if
we can build that laptop, we can do anything, right?). The machine
can perform 10^51 operations per second. Let's be conservative and
say that it takes only one operation and one bit of memory to check
one key (through the miracle of data compression?). Then in one
second, the machine will exhaust a keyspace of size 10^(51 + 31) ~=
2^269. The lifetime of the universe so far is on the order of 2^60
seconds. Thus, if my cipher has a key size of 269 + 60 = 329 bits, I
can feel fairly safe from future brute force attacks by a single
computer.
If I'm feeling paranoid about a really dedicated attacker with
multiple machines (say, Team Slashdot 2369), I would consider a search
time of 10^67 years (time until an open universe largely succumbs to
proton decay) and a computer with, say, 10^83 available bits (roughly
the number of atoms in the observable universe). Assuming the same
number of operations per second, I would need about a 695-bit key.
Heck, I might as well round up to 768 or 1024 bits, depending on how
much powers of two simplify the description of my cipher.
On the whole, it seems easier for attackers of future eons to build a
time machine, then go back and beat the key out of me with high-tech
futuristic rubber hoses. Or possibly, they could use a quantum
computer with 695 qubits? Someone needs to figure out comparable
physical limitations for quantum computers.
--
## Jeremy Buhler * peace through superior algorithms * U. Washington ##
------------------------------
** 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
******************************
