Cryptography-Digest Digest #65, Volume #10 Tue, 17 Aug 99 14:13:02 EDT
Contents:
Re: Blowfish algorithm - Is it full proof? (Helger Lipmaa)
Re: E2 (John Savard)
Re: How good is this quadratic sieve variation? (Mok-Kong Shen)
Re: NIST AES FInalists are.... (John Savard)
Re: Wrapped PCBC mode (Tom St Denis)
Re: Wrapped PCBC mode (Tom St Denis)
Re: CRYPTO DESIGN MY VIEW ("Douglas A. Gwyn")
Entropy in "modified" passwords (Nick Battle)
CRYPTO DESIGN MY VIEW (John)
compress then encrypt? (John)
Re: Kana, was occurrence of letters in english (Patrick Juola)
Re: Entropy in "modified" passwords (Mok-Kong Shen)
Back doors....(was: AES Finalists) (fungus)
Re: CRYPTO DESIGN MY VIEW (Patrick Juola)
Re: Academic vs Industrial (John Savard)
Re: crypto survey (Medical Electronics Lab)
Re: Please help a HS student with an independent study in crypto (Barry Herman)
Re: Cracking the Scott cryptosystems?
Re: Kana, was occurrence of letters in english (John Savard)
----------------------------------------------------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it full proof?
Date: Tue, 17 Aug 1999 14:29:52 +0000
David A Molnar wrote:
> What if we're not aiming at the target plaintext 67890, but just want
> *any* other plaintext than 12345 ? I agree that being able to pick the
> resulting plaintext would be a huge weakness! Except it's not at all clear
> to me why flipping bits in Blowfish (with the key staying the same)
> wouldn't produce a valid ciphertext which decrypts to some garbage
> plaintext...although the adversary wouldn't know which one.
Then pick *any* other ciphertext than A? :) It's a bijective business... Every
ciphertext decrypts to some (however you would define that) "garbage" plaintext.
You cannot get things like plaintext awareness without randomness and thus
increasing the output length. On the other hand non-malleability is always
tacitly assumed from the block ciphers (although in the block cipher world the
word NM is almost never used, it's a too trivial requirement).
Helger
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: E2
Date: Tue, 17 Aug 1999 15:29:33 GMT
[EMAIL PROTECTED] wrote, in part:
>Is anyone else disappointed that E2 was not chosen as an AES finalist?
It probably just barely missed out, since many people found it to be
one of the better designs.
RC6 and MARS were also classic Feistel designs which used
multiplication to provide nonlinearity and rapid diffusion in one
step, like E2.
The other three finalists are significantly different, and Twofish in
particular had one of the most comprehensive analyses of any
submission, and was designed to be suitable for a wide variety of
platforms.
Thus, if E2 had been accepted, one of RC6 or MARS would need to be
thrown out. (Similarly, if CAST-128 had been accepted, one of Serpent
or Rijndael would have needed to be thrown out.)
Both of those designs come from sources with very good reputations.
RC6 is interesting because of its extreme speed and simplicity, and
MARS has a complicated design, but perhaps that is what is needed for
security.
So E2, I think, got squeezed out not because there was anything wrong
with it, but because it just wasn't as exciting as the others.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: How good is this quadratic sieve variation?
Date: Tue, 17 Aug 1999 17:51:02 +0200
Bob Silverman wrote:
>
> The basic problem is that one hopes that values of Q(x) are smooth
> over an interval (say) [-M,M]. The best one can hope for is that
> these values are going to be equal to about M sqrt(N)/sqrt(8) for
> well chosen polynomials Q(x).
For f(x) = x^2 mod N, is there any empirical estimate (rough values
based on actual runs) of the probability of having f(x) smooth
for x, say, in [h, 2h] (h = sqrt(N)) ?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST AES FInalists are....
Date: Tue, 17 Aug 1999 15:16:52 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>That hardly qualifies as a "back door", because the opponent doesn't
>have the ability to alter the innards of your encryptor/decryptor.
No, it isn't the same thing at all, I admit.
It does qualify as an attack, though, if the opponent manages to limit
the key size of my encryptor/decryptor by ensuring that if I alter its
innards to make the key bigger, its security collapses.
While I agree that it's unlikely - verging on preposterous - that the
NSA is going to (or rather, has already) put a real backdoor into the
winning AES candidate, I merely seek to focus consideration on the
real and possible ways that their superior knowledge of these matters
could be put to use.
And one way is to design a 64-bit algorithm that indeed has 64-bit
security, but which can't be seized upon for use as the basis of a
128-bit algorithm with 128-bit security. This achieves the goal of not
promoting outside encryption that is too secure, but it also avoids
any blame - the original algorithm was never promised as anything but
what it was.
Instead of speculations about things the NSA almost certainly won't
do, I suggest people look at what they just possibly might do - and
which some properties of DES and Skipjack suggest they _may_ have
done.
As you rightly point out, of course, if a cipher design is engineered,
random alterations are likely to be unhelpful, so even here the
"smoking gun" may not be as impressive as it seems. But it makes more
sense to look into the *possible* than waste time on the fantastic and
paranoid.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Wrapped PCBC mode
Date: Tue, 17 Aug 1999 15:09:16 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> > 3. Doesn't delay key searches
>
> Actually it does slow them substantially-- his method is an example
of an
> all-or-nothing encryption method. As such the whole file must be
decoded in
> any attempt at a guess. On the other hand other such methods of
achieving
> the same result exist and are substantially faster than his particular
> construction.
>
Not really. Plug in a 128-bit key and brute force is out of the
question. Why encrypt the message 80 times if you can use one big'nuff
key?
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Wrapped PCBC mode
Date: Tue, 17 Aug 1999 15:13:39 GMT
In article <7p9vmk$2t18$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Well at least we agree that is does substantailly slow key searchs
> and that it is an all or nothing encryption method. And that it is
slow
> but I think it is secure so we differ there.
> But I think people fail to realize that in the real word messages
between
> people fall into patterns and if one is the kind of person that is
real formal
> and you use a weak AES type of method with the weak NSA approved
chainning
> then from information theory alone only the front part of file needs
to be
> looked at to brake the system. An all or nothing type of encryption
of my form
> prevents this common front end to being as large a weakness.
Are you completely off your rocker?
Just plug in a 128-bit key (or larger) and you make brute-force a non-
option. Original multiple encryptions were used because DES has a
small key. However you could use RC5 with larger keys...
Your 'all-or-nothing' method is solely dependant on the block cipher
for security. In this case why multiple encrypt? If I give you
C = Ek(P)
How are you going to determine P from C? In case you didn't know
that's what encryption is...
You have to pick from 2^n (n= block size) different messages,
especially if it's compressed and has a message specific IV.
I really don't think you understand how real life systems are
attacked. It's not only the block cipher, it's the entire system.
Netscape for example was attacked because of it's RNG ...
And dave, prove that any of the AES 5 finalists are weak. I would love
to see that.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Tue, 17 Aug 1999 15:27:50 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Actualluy huffman coding is a subset of arithmetic coding so the two are
> very close. Actaully if the letter frequency appears as a power of .5 then
> they are the same assuming the same values assigned to symbols.
Yes, but the fact is that most actual sources (of message text)
don't have symbol probabilities that use all the available
powers of 1/2. For example, the frequency of the letter "E"
(upper and lower case combined) in English documents is less
than 1/8, yet Huffman coding would represent it with enough
bits to cover a symbol that could occur with probability 1/2.
That's why in general arithmetic coding can achieve better
compression than Huffman encoding.
> Well not as much gain as there are in methods that recognize
> letter sequence as well as letter frequency.
Arithmetic coding can be applied that way, too. One of the
articles I ran across yesterday in IEEE Proc. on Comm. dealt
with this.
> I have a been playing with a version of adaptive arthimetic
> ... how to stop it to meet my no headerless file comstraints
> so that it would be useful as a first pass to encryption.
Well, good luck. I'd think it would be possible, and the
more compact the ciphertext the safer, generally speaking.
------------------------------
Date: Tue, 17 Aug 1999 17:21:19 +0100
From: Nick Battle <[EMAIL PROTECTED]>
Subject: Entropy in "modified" passwords
If I have a system that takes a small password and hashes it into (say)
a 128 bit key, I can see that the resulting key only contains a small
amount of entropy - that represented by the password's unpredictability.
The hash does nothing to alter this, though it "spreads it out" over
more bits.
Similarly, if I do something *predictable* to the password before I hash
it, such as run it through ROT13 or perform one of the well known
transformations (such as alternating cAsE), then this doesn't alter the
entropy in the resulting key either.
If I do something unpredictable - in effect defining a new
transformation function as part of the "password" - then it looks to me
as though this *does* increase the entropy in the system, not by
supplying more random data but by providing a function that modifies the
initial password in an unpredictable way (to someone who doesn't know
the password/function combination).
I'd like to ask two things: is it appropriate to talk about a function
representing a certain amount of entropy like this, and if so, how would
one go about evaluating how much entropy is represented by a given
function in this scenario?
Cheers,
-nick
------------------------------
From: John <[EMAIL PROTECTED]>
Subject: CRYPTO DESIGN MY VIEW
Date: Tue, 17 Aug 1999 09:14:22 -0700
A lot of good points. Of course, I will grant that the
cracker knows the phrase is there, but would probably not
in real life have any way of knowing. I would probably mix
all kind of noise, space or random stuff, and only the
receiver, after decryption, would know where to look for
the plaintext.
Maybe chi-square testing of the code would be of help, but only
for larger data sets. That would only give you an idea of
how things are dispersed, and you still are stuck with
brute force.
http://www.aasp.net/~speechfb
In your "real world view", why would anyone give up the
workings of an encrypter, unless they were only interested
in the science of it?
* 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: John <[EMAIL PROTECTED]>
Subject: compress then encrypt?
Date: Tue, 17 Aug 1999 09:31:10 -0700
It is true that less data, when encrypted, makes it harder
to guess. Yet, it seems that there must be some mathematical
formula to figure out the structure of the dataa. After all
it is only changing forms. Compression and encryption are
closely related. It seems the better thing, or first thing
to do is see how compressable your encrypted data is, that
gives you a good idea.
http://www.aasp.net/~speechfb
* 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] (Patrick Juola)
Subject: Re: Kana, was occurrence of letters in english
Date: 17 Aug 1999 11:19:07 -0400
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Patrick Juola) wrote, in part:
>
>>Most of these have multiple pronunciations;
>>the character "hon" can also be pronounced "moto" (with the same
>>meaning, more or less). There are about 60,000-ish of them, so an
>>exhaustive list is near impossible to compile and not known to most
>>native speakers.
>
>I can supply a bit of additional detail to this:
>
>Currently, the list of officially recognized Kanji is much smaller
>than 60,000; it is more like 2,000 or even 800 (for some reason, the
>number 841 comes to mind). This is a result of a language reform
>conducted by the Board of Education in Japan during the 1950s. Omitted
>from the official list were some Kanji found in people's names, which
>resulted in complaints which have appeared even in news stories here;
>recently, this situation has been rectified.
It hasn't been rectified particularly well; in particular, if you
only know the Ministry of Information's official 2,000 kanji, you
can't even read a Japanese newspaper. Personal and place names
are the two largest bugaboos.... for example, the city of Tsukuba
was officially named in hiragana because the mountain after which
it was named uses a non-approved kanji.
So although there *is* a Basic-English-like reduced list of kanji,
you'll find almost no documents for which this list is adequate.
-kitten
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Entropy in "modified" passwords
Date: Tue, 17 Aug 1999 18:57:03 +0200
Nick Battle wrote:
>
> If I do something unpredictable - in effect defining a new
> transformation function as part of the "password" - then it looks to me
> as though this *does* increase the entropy in the system, not by
> supplying more random data but by providing a function that modifies the
> initial password in an unpredictable way (to someone who doesn't know
> the password/function combination).
It is customary, however, to assume that this function, if fixed, is
known to the analyst. If this function is not a fixed one, e.g. having
some parameters that are variable, then supplying these parameters
supplies some entropy. (Usefulness of 'variability'.) This is
equivalent to having an additional 'password', in my humble opinion.
The situation is the same in principle, if you have a set of functions
and choose one of them. My humble knowledge unfortunately does not
enable me to evaluate the quantity of entropy thus introduced in given
constellations (your second question), sorry.
M. K. Shen
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Back doors....(was: AES Finalists)
Date: Tue, 17 Aug 1999 19:10:02 +0200
"Douglas A. Gwyn" wrote:
>
> Dammit, that's *not* a technical design, that's the same old
> unsupported assertion that "it could be done". *How* could
> it be done?
>
example:
Changing the S-boxes in DES makes it much more vulnerable to
differential attacks. We're fairly certain that the NSA knew
about differential attacks when DES was designed, but that nobody
else did. With different S-boxes, the NSA could have had an
invisible "back door" into DES.
Differential cryptoanalysis was eventually discovered. If DES
hadn't been resistant to this attack then it would have been
"broken" and the NSA would presumably have kept quiet, claiming
ignorance.
This wasn't the case but it showed us that the NSA knew some stuff
that we didn't. Maybe they've got some other tricks up their sleeves.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: 17 Aug 1999 11:14:46 -0400
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Douglas A. Gwyn wrote:
>>
>> Okay, while our local network was down today I did a bit of research
>> in the tech library, and found that "arithmetic coding" seems to be
>> the compression method of choice. The basic idea seems to be to
>> dynamically repartition the code space so as to always minimize the
>> expected size of the *next* symbol; if you have a good model of the
>> population statistics, this method is supposed to achieve nearly
>> optimal compression (better than Huffman coding). There is supposed
>
>I have only scanty knowledge about arithmetic coding. But I vaguely
>remember that arithmetic coding, because it operates on real
>numbers, could have some implementation difficulties if the real
>numbers supported by hardware are not long enough. I hope experts
>would comment whether this is true or false.
Not really a problem; implement it so that the encoding epsilon is
always greater than the smallest representable difference and
compress in chunks.
-kitten
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Academic vs Industrial
Date: Tue, 17 Aug 1999 17:10:42 GMT
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote, in part:
> Actually all the other block methods are a subset of the random S-box.
>If you can develop a method that works against a random S-box then you
>don't need any other methods of attack. Of course it is hard to work with
>really big S-boxes. I am not aware of anyone using one larger than 19 bits.
I'm not aware of anyone else but you even using one as big as 16 bits.
Blowfish, using a key-dependent S-box with an 8 bit address, is as big
as it gets.
I wouldn't mind trying to persuade people to consider 12 bits, just as
an extra safety precaution. But I would suggest even that very
hesitantly and politely; Blowfish is regarded as already being far
more than anyone really needs, and so I would not try to suggest that
12 bits was actually *necessary* for security. Just that it was
feasible on today's computers, and the extra safety margin is worth
going for.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: crypto survey
Date: Tue, 17 Aug 1999 12:32:32 -0500
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> Medical Electronics Lab <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> > >
> > > Simple question: Who is your enemy?
> >
> > Every government that exists :-)
>
> I hope this is meant as a joke. After all, governments only reflect the
Yeah, that's what the smiley is for!
> people they govern. There are people who view their government as an
> enemy and there are people in government who view the people as their
> enemy, or at least as their opponent. Both attitudes are not serious.
Unfortunatly, both attitudes exist and those who believe *are*
serious.
> I would say my enemy is inefficiency. Cryptography has a great
> potential for making the world a more efficient place - and therefore a
> more just place. For example, the generalized used of cryptography
> would give people an effective means for controlling their intellectual
> property. If we agree that in the future most labor and most wealth
> will be intellectual, then cryptography will make it more difficult to
> exploit others. An economy that is free to private iniciative but also
> free of exploitation is more efficient and stable.
Economies tend to evolve inspite of governments. In the US there is
a great deal of effort expended by the government to prevent the
distribution of some plants. Yet somewhere between 10 to 20 % of the
population can still buy the stuff. I think stability is more
important than efficiency. Unfortunatly again, it's pretty easy
to prove that dictatorships are more stable and efficient free
economies. They are not *dynamically* stable though, and I think
the ability to change and find new equilibrium is what keeps
free societies stable over the long run. Efficiency helps for sure,
but if there's no stability you can't develop efficiency.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Barry Herman <[EMAIL PROTECTED]>
Subject: Re: Please help a HS student with an independent study in crypto
Date: Tue, 17 Aug 1999 13:11:35 -0400
> BTW I am in HS and we don't even come close to any usefull linear
> alegebra. I am surprised to find other HS students here...
I'm mostly a lurker here, but I've been here since about 10th grade (now
junior in college). My HS had very, very basic linear algebra, Calc 3,
and differential equations.
- Barry
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: Cracking the Scott cryptosystems?
Date: Tue, 17 Aug 1999 19:00:03 +0200
On Tue, 17 Aug 1999, SCOTT19U.ZIP_GUY wrote:
> In article <[EMAIL PROTECTED]>,
><[EMAIL PROTECTED]> wrote:
> ...
> >
> >For a weak cipher it doesn't help too much not to use a checksum: If it is
> >neccessary to be able to check the integrity of the file wrapped PCBC
> >doesn't help and there has to be some additional check. In the other case
> >the attacker will be able to see whether he produced garbage or not.
> >
> I think a CRC or passpharse checker as in PGP is a bad idea. IF the
> the idea is to make it as hard as possible to break you should leave no
> hooks for an attacker to look at. IF you want a checksum or what ever
> as a first test to see if file ok add it after the encryption like when you
> ZIP a file.
> ...
>
> >This is why the AES candidates use more rounds than neccessary, why MARS
> >uses unkeyed rounds and so on.
> It is your not that they really use more rounds than needed. IT is just
> that they add more rounds than what seems to be best open literature
> attack. Nothing to say a few years from know they could be weak. THere
> strength is not based on information theroy ideas.
>
> >
> >Do you really think your cipher could be strong only because you are using
> >an unusual design?
> >
> >Why do you think, NSA wouldn't be able to break a cipher that was
> >developed without any cryptanalytic knowledge?
> The problem with most designs is it is possilbe to undue or analyze since
> they are made of simple operations or functions. However if one thinks about
> it most operations can be undone.
> About the only thing in theory that can not be is a random S-table.
As well the s- as the g-box of skipjack is invertible, but nevertheless
they are part of a strong algorithm.
I'm really not sure what you are trying to say.
Obviously you don't like key-independent s-boxes. But at least for small
s-boxes it is much simpler to get strong fixed boxes than to get strong
key-dependent s-boxes.
At least DES with random s-boxes is in most cases much weaker than the
original version.
> Yes it would be hard to desing a 64 or 128 bit S-table
> becasue the keys get so large so fast. But if one could have a random S-table
> for a 128 bit block then all the AES candidates are nothing more than a subset
> of this super method. So I am trying to use the largest possssible S-table
> that can easily run on a machine and still have a key that could fit on a
> floppy that is currently 19 bits.
I'd try the largest s-box that fits in the cache of my computer.
> History has shown us key size alone is not
> everything. The Enigma in certain forms had a very large key much
> larger than the AES candidates so one should strive for as large a block
> size.
I don't think larger blocks are producing stronger ciphers.
Biham mentioned it would be easier to analyce a cipher with very large
blocks.
> Well my block size is the whole file. This is where I am coming from
> large keys large S-tables and the file or unit underconsideration should
> be the whole block.
It would be interesting to have a look at files of a fixed size and do the
usual attacks on this version of SCOTTxxx.
> The next thing of conseideration is how to weave these
> blocks together. I like the shift and W-PCBC concept but there may be stronger
> also if one is worried about chosen plain text or slide attack schemes one
> should add a front and back round that is different to break these up.
> Look I may not have the best. But I am sure the best treats a whole file
> as a block and uses the largest S-table possible.
At least there are more strong large s-boxes than strong small ones - at
least such ones that are strong against known attacks.
> >
> >> So the design should use the most amount of computer resourses for the
> >> job that can be talerated while minimizing the possiblity of solutions.
> >
> >So you think your algorithm is secure because it is slow?
> No but I think that a sercure algorithm is slow. In the since that
> the less work you but into encrypting the easier it is to break.
The OTP is surely one of the fastest algorithms :-)
But I agree that it is simpler to get a strong algorithm that is very slow
than to get a strong one that is fast.
This is why NIST is interested in fast AES candidates: In most cases the
algorithm should need a minimum of computer power while producing a
maximum of security.
The job of the AES designers was to optimice this.
> That is not the same as saying just because it is slow it is secure
> it is very easy to write a slow program that does nothing.
> >
> >3DES is better than blowfish because it needs more time to do it's job?
> That is not what I am saying. But I am saying mine is better than blowfish
> if you want to encrypt a file and keep it secret. Because the nature of the
> S-block is such that there is no true fast way to do the encryption.
I'm not convinced.
> Blowfish does not treat the whole file as a block.
> If one wanted to use Blowfish in a
> safeway you could use it with out the pre and post routines
Whitening is always a good idear: At least it won't weaken the cipher.
> I have and use
> it with W-PCBC and a different key for each wrapping.
I think wrapped PCBC isn't interesting for less than three rounds.
How large are three different lookup-tables?
More than 4 Mbyte?
> However I am not sure
> people besides me knows how to do this.
I don't think it is hard to understand what you are doing: You are
starting with the first encryption block and move to the end, then
start the next round with the last block and move to the beginning and so
on.
> ...
Thinking about SCOTTxxx as a block cipher and using fixed blocksizes I
think it could be strong only because it is impossible to get a weak
cipher when using such a large s-box, but I don't think the design would
be nicer than that of other ciphers.
Let's go further and reduce the size of the s-box to SCOTT8 or even
SCOTT16 and fix the blocksize to 64 or 128 bit.
In this case it doesn't look like a strong cipher: At least SCOTT8 would
produce lots of weak s-boxes and you would have to use a huge number of
wraps to get something as strong as the commonly used blockciphers.
Enterrottacher Andreas
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Kana, was occurrence of letters in english
Date: Tue, 17 Aug 1999 17:25:54 GMT
[EMAIL PROTECTED] (Patrick Juola) wrote, in part:
>It hasn't been rectified particularly well; in particular, if you
>only know the Ministry of Information's official 2,000 kanji, you
>can't even read a Japanese newspaper. Personal and place names
>are the two largest bugaboos.... for example, the city of Tsukuba
>was officially named in hiragana because the mountain after which
>it was named uses a non-approved kanji.
So you were aware of this, and I was the one who was ignorant about
the real situation in Japan. Oh, well, now a more complete picture is
visible.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.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
******************************
