Cryptography-Digest Digest #65, Volume #13 Wed, 1 Nov 00 05:13:01 EST
Contents:
Re: Psuedo-random number generator (David Schwartz)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: Really Strong Cipher Idea? (Mok-Kong Shen)
Re: On introducing non-interoperability (Mok-Kong Shen)
Re: Give it up? (Mok-Kong Shen)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: how i decode this? (Paul Schlyter)
Re: Rijndael file encryption question. ("Brian Gladman")
Re: Newbie about Rijndael (Dido Sevilla)
Re: 3-dimensional Playfair? (Daniel)
----------------------------------------------------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Tue, 31 Oct 2000 23:54:43 -0800
David Schwartz wrote:
>
> By the way, you can find example code demonstrating this technique at
> http://youknow.youwant.to/~djls/entropy.c
>
> DS
Below is the middle of 10 seconds of jitter measured by sending the
same corrupt DNS query to a name server on the LAN right next to my
machine (the query is obviously invalid and the name server will send
back a failure message immediately). Both machines were quiet at the
time and the logging was done to memory and then dumped to eliminate
other sources of randomness. The offsets are against the machine's
600Mhz TSC (from the program in the URL above):
75c559f4420cf64c2cb03d370aae1e805e5b0e0a1382fb2c34c223ad3f65f9c560d2b9b786b7546b
d8566d8e66205168e39a386d9f6e33830ba6e4d2df2e666475dbabc881413b8ac4f9d8262f9e2bb6
8af21283583e307c64a7bb951905860dbdfb01ece4c48f1f8447256ce3db272c3f86af0fa0afddad
436010788be030687ec28501749565a103eb0a5fda18e4801199d5e2c576e7fa3f3f5203a453d5b8
f12f8ac17e3a2121aececb360e95dca5297ccd929531493becb94afecfb822bde4a8e85960d8dce5
999a9e159c65624487b8476fc550aaef9c6bfe44f7b8bca0df7452626a4812925383376d956e1fec
51cb4c6658a82ca0b7633b6b435104b51583177666132742cb5ee3e071c85eb2b1fdf78dcfe8a66a
b2aeb6689e6608df953320510a960d068ebe8c44dc5414d46474d5b786b9ba3911d11a1f834e3677
1e0a36262eaf7318cadf0a746ecfcd94c9651bb3b600420e0681b239b301810d4425dc645abc026c
cf07328b7b909edb1d8c13c5e8d3602373a3508d65b7ceed343b96bcbc13526be7e34b6840c0b55c
While not unbiased, the data is unpredictable.
DS
------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 01 Nov 2000 09:28:47 +0100
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> David Wagner wrote:
> >
> > Mike Connell wrote:
> > >Pa, Pb are RSA public keys. (X)Pi means data X encrypted under key
> > >Pi. Xa, Xb are random blocks of data of the same size as the public
> > >keys.
> > >
> > >1. a -> b : Pa
> > >2. a <- a : Pb
> > >3. a -> b : (Xa)Pb
> > >4. a <- b : (Xb)Pa
> > >
> > >Then a and b compute the XOR of Pa,Pb,Xa,Xb.
> >
> > I don't understand the "MITM attacks" others are posting on your
> > scheme.
> >
> > If you don't have any way to validate the public key that the other
> > guy is using, then any authentication protocol you use will be
> > susceptible to a MITM attack. That's just unavoidable, and is not
> > a flaw of the authentication protocol.
> >
> > The point is that secure authentication protocols tell you, at the
> > end of the protocol run, who you are talking to. An attack is where
> > the malicious guy Mallet can get you to think you are talking to Alice
> > when in fact you are really talking to Mallet.
> >
> > It is NOT an attack if at the end of the protocol you think you are
> > talking to Mallet and you are correct in this belief. If you send
> > secrets to Mallet, knowing that it is her that you're sending them to,
> > well, that's not the fault of the authentication protocol.
> >
> > In this case, when the protocol completes, I think you always know
> > the public key of the other person you are talking with. There are
> > other issues (like replay attacks), but I don't think MITM attacks
> > is one of them.
> >
> > Am I missing something?
>
> Yes. Since the public keys are transmited *as part of the protocol*,
> this implies that they are ephemeral, and were generated for this
> session only. You therefor can't know who they actually belong to. If
> the protocol said that, at some earlier time, a and b had exchanged
> public keys, and b trusts that the owner of "public key a" is a, and a
> trusts that the owner of "public key b" is b, then what you said would
> be absolutely 100% correct.
>
Both cases might apply. The keys might have been exchanged previously,
in which case both parties know that the key represents an actual
person.
If that wasn't the case, all the user knows about the "person" is what
they have said to the user, and what the user has said to them. I
think the MITM implications have been done to death now ;)
best wishes,
Mike.
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Really Strong Cipher Idea?
Date: Wed, 01 Nov 2000 09:20:15 +0100
John Savard wrote:
>
> Here is my idea for a cipher that is _merely_ strong, like an ordinary
> symmetric cipher - but a bit stronger than most.
>
> Two parties send messages in blocks of, say, 4,096 bytes.
>
> They share a secret key which is perhaps 6,000 bytes in length.
>
> When they communicate, they first send a public-key block which
> contains perhaps eight 512-bit session keys, so they can send a
> message which is up to eight blocks long.
>
> The session key is used to encipher a block of plaintext like this:
>
> Part of the session key is first used to encipher the 6,000 byte
> secret key by means of transposition, and then another part encrypts
> it using, say, a block cipher in CBC mode. (first block-sized piece of
> transposed secret key used as IV, and not included in the 'encrypted'
> key used later)
>
> The other part of the session key enciphers the message itself.
[snip]
Is the 6000 byte secret used for one single message, or
is it used again and again in combination with other
informations that vary from message to message (or session)?
I guess that it is the second case. Then your scheme
certainly cannot provide perfect secure communication till
eternity. (One could see this from the analogy of perpetum
mobile.)
You employed in the part that I snipped a palette of crypto
techniques. I have the impression that that's a bit too
complicated in some sense. High security for any practically
conceivable applications (from the point of view of
encryption alone) can be achieved in my view with symmetric
block algorithms through combination of some of the following:
(1) use of a sufficiently long key. (2) multiple encryption
with, say, 3 different ciphers of the quality of AES. (3) use
of sufficiently large number of rounds. (4) employment of
non-linear block chaining. (4) make use of non-interoperability (see a
recent post of mine).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On introducing non-interoperability
Date: Wed, 01 Nov 2000 09:20:07 +0100
Mok-Kong Shen wrote:
>
> wtshaw wrote:
...........
[snip]
Addendum:
I realize that I forgot to mention in this thread the most
simple (minimal 'invasive') way of modifying the
keyscheduling. I described that quite a time back in the
group, namely a (secret) permutation of the round keys,
i.e. using the i-th round key for the j-th round etc.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Wed, 01 Nov 2000 09:20:31 +0100
Tom St Denis schrieb:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > Tom St Denis wrote:
> > >
> > > Here is all you need to know about communication topology.
> > >
> > > Secrecy -> Cipher
> > > Efficiency -> Codec
> > >
> > > Codec != Cipher.
> >
> > Questions: (1) 'Topology' has a time-honoured and well-
> > established meaning. How does the above conform to that?
> > (2) Are you saying that one can't extremely increase the
> > strength of a cipher and yet remain very efficient like
> > one can't have a racing car at very low price, or do you
> > want to express some other novel idea? Thanks.
>
> Perhaps "topology" was the wrong word. But I just want to
> stress "leave security to the components designed for security".
In view of the text of your original post and the uncommon
title I still have trouble of understanding. (1) What
would you substitute for the wrong word? (2) The above
phrase under double quotes seems to be ambiguious. What
is your 'proper' point? Could you paraphrase that into two
or three sentences? You mentioned security and efficiency.
Now there is always a trade-off between these, no matter
how capable the cipher designer is. So, if one needs
extremely high security, one must accept some inferior
processing speed. This is common sense. I don't yet see
what new relationships between these two entities could be
established. You mentioning of 'components' seems also
a bit difficult for the reader. For the components need
not only be good but also to be put together in a good way
in order to have a strong cipher as a whole.
M. K. Shen
------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 01 Nov 2000 09:37:54 +0100
David Schwartz <[EMAIL PROTECTED]> writes:
> Mike Connell wrote:
>
> > > Now the MITM can intercept all the communications between A and B. A
> > > knows it's talking to mb, which it thinks is B.
> >
> > That is the sticking point.
> >
> > I understand what you're sying, and thank you for saying it. However,
> > I still don't see it as an attack. The question is, why does A think
> > that mb is the public key of B?
>
> Because that is the only key he has ever seen B present and he doesn't
> know the MITM exists.
>
> > In the case that A,B have exchanged keys beforehand, the attack fails,
> > as A recognises Pmb!=Pb. The other scenario, is where A knows nothing
> > about B, except the public key which they've previously used to
> > communicate with that 'person'.
>
> Correct. I'm talking about the other scenario.
>
> > In that case, A is talking to "the person with public key mb" - that is
> > all that they know. They get stock tips from mb, and they always get
> > stock tips from mb. the MITM may be relaying those from user B (Pb), but A
> > never even knows that: it only sees stocktips coming from mb.
>
> Correct, so A thinks that mb is B. This allows the MITM to send any
> message he or she wants to A and A will think it came from B, since A
> only knows B as mb. This allows the MITM to impersonate any user A has
> ever spoken to.
>
A only believes mb is B if either:
A has met B and B gave A them mb key. (ie B is in league with M).
A isn't aware of the MITM attack, and will trust a message
claiming "I am B" from an unknown public key. This is the fault of A.
> > All this reduces to the case of A and B trusting C, when C is not
> > somebody they should be trusting.
>
> No, this comes back to A assuming that messages from mb came from "the
> person who gave me all those stock tips", when they don't.
>
Well, A *does* get the messages from mb. M is giving all those stock
tips to A. Any belief from A that mb is B is unfounded.
> > > B knows it's talking to
> > > ma, which it thinks is A. The MITM can continue to do this to every
> > > single communication between A, B, C, and others. All along, it can
> > > decode every communication, can modify any communication, and can
> > > impersonate any user to any other user.
> > >
> > > So you think the person who sent you all those stock tips is 'mb' (when
> > > it's really B). So when you see a new stock tip from 'mb', you think
> > > it's really B. It might be, or it might not be.
> > >
> >
> > Well, it *is* mb. mb might have gotten them from B, but it was still
> > mb that sent them to A.
>
> Yes, mb sent them to A, but so did B.
>
Nja! B sent them to M - and B *knew* it was sending them to M. B has
no more reason to believe that M is A, then A has to beleive M is B
I guess we've discussed this to death now though!
best wishes,
M(ike) ;-)
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 01 Nov 2000 10:12:49 +0100
[EMAIL PROTECTED] (David Wagner) writes:
> Mike Connell wrote:
> >Pa, Pb are RSA public keys. (X)Pi means data X encrypted under key Pi.
> >Xa, Xb are random blocks of data of the same size as the public keys.
> >
> >1. a -> b : Pa
> >2. a <- a : Pb
> >3. a -> b : (Xa)Pb
> >4. a <- b : (Xb)Pa
> >
> >Then a and b compute the XOR of Pa,Pb,Xa,Xb. This gives them a
> >substantional number of shared secret bytes to construct a session key
> >from.
>
> It does have some mildly funny properties (nothing earth-shattering).
>
Quite worrying now that you point them out. Mainly because I didn't
spot them earlier myself ;-)
> Note that B can control what key they finally end up with. Bad?
> I don't know. Maybe it's better to use hash(Xa,Xb,Pa,Pb), not XOR.
>
The XOR block is the same size as the RSA keysize, (say 1024 bit), it
gets hashed (or reduced by some other method) down to the required
size for the session key (say 128+64 bits). The actual raw data of the
XOR block is never used. Is hash(XOR(a,b,c,d)) as good as
hash(a,b,c,d)?
> A reflection attack: Reflect A's messages back to himself.
> 1. a -> m : Pa
> 2. a <- m : Pa
> 3. a -> m : (Xa)Pa
> 4. a <- m : (Xa)Pa
> Here M is the attacker. Note that A ends up sharing the key 0 with
> himself, and if A sets up a "secure" channel using 0 to derive
> encryption and MAC keys, we have two bad results: 1. M can send forged
> messages over the channel, since M can predict the MAC key; 2. If A
> sends anything over the "secure" channel, M can read it, since M can
> predict the encryption key.
>
I should say that this is point-to-point, so M will only be sending
forged packets to itself (or telling A that A said them ;-). The fact
that the attacker can pretend to be A (if only to A) is more
worrying, as that may actually occur.
I must enfore Xa != Xb...
> If you use RSA encryption, so that (Xa)Pb = Xa^Eb mod Nb (Pb = (Nb,Eb)),
> then an active attacker M can break the scheme by replacing the
> transmitted values (Xa)Pb with 0:
> a -> b : Pa
> a <- b : Pb
> a -> m : (Xa)Pb
> m -> b : 0
> m <- b : (Xb)Pa
> a <- m : 0
> Then M can predict the session key used, since 0^Db mod Nb = 0, etc.
>
Eek! Thanks for pointing that one out 8-|
So the encrypted blocks shouldn't equal zero either...
> Also, a Denning-Sacco attack: Suppose M intercepts a session between
> A and B:
> a -> b : Pa
> a <- b : Pb
> a -> b : (Xa)Pb
> a <- b : (Xb)Pa
> M wants to know Xa XOR Xb. Next M can open a session with B,
> replaying the old value of (Xa)Pb in message 3 of the new session:
> m -> b : Pm
> m <- b : Pb
> m -> b : (Xa)Pb
> m <- b : (Xb')Pm
> M can decrypt message 4 to learn Xb'. Now suppose that somehow the
> session key Xa XOR Xb' computed in the second session is revealed;
> maybe you break a session key, maybe it is inadvertently leaked,
> whatever. In any case, compromise of a single session key should not
> result in a complete break of the system (that's the point of having
> session keys). But in your proposal, revealing Xa XOR Xb' at any point
> reveals Xa, which is halfway to compromising the old key Xa XOR Xb.
> I don't think this is an especially good thing.
>
You're right, that's another good point. However, I'm going to brush
it under the carpet by saying that Xa XOR Xb' is never revealed ;-)
As the XOR block is only a temporary value used whilst the bits are
reduced down to enough for a session key, there is some hope that it
might actually be true.
If the actual session key is revealed, there aren't enough bits in it
to reconstruct Xa XOR Xb' (I think).
However, the necessity to quickly destory the XOR block is worrying...
> None of these are devastating, but they are worth a little thought.
Thanks for the help!
best wishes,
Mike
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
From: Mike Connell <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: 01 Nov 2000 10:26:28 +0100
David Hopwood <[EMAIL PROTECTED]> writes:
> Mike Connell wrote:
> > Pa, Pb are RSA public keys. (X)Pi means data X encrypted under key Pi.
> > Xa, Xb are random blocks of data of the same size as the public keys.
> >
> > 1. a -> b : Pa
> > 2. a <- a : Pb
> ^ I assume this should be b
>
Oops! Yes, it should be B. Apaprt from the case where A is telepathic ;-)
> > 3. a -> b : (Xa)Pb
>
> The number of passes could be reduced to 3 by eliminating message 1
> and making this "Pa, {Xa}Pb". (A can still go first by swapping A and B.)
>
Yes, I mainly kept it like this for conceptual simplicity.
> > 4. a <- b : (Xb)Pa
>
> In the other responses to this thread, there seems to be some confusion
> because the original description did not say whether public keys were
> certified or known before the protocol starts. There are three cases:
>
> 1. If the public keys are certified, then messages 1 and 2 should be
> explicitly sending certificates, not unsigned public keys.
>
> 2. If the public keys are not certified, but they are known to be correct
> for some other reason (for example because key fingerprints, i.e.
> hashes, have been exchanged over an authentic channel), then it is
> redundant to send them in the protocol. It would be more efficient
> and clearer to send the fingerprints instead in messages 1 and 2
> (since a mapping from a fingerprint to a public key is assumed to be
> known).
>
> 3. If the public keys are not certified or otherwise known to be correct,
> then there is obviously a MITM attack.
>
The cases are 2 and 3, there are no certificates. I think we've gone
over the MITM attack for 3 in other parts of the thread.
The main reason that the full keys are sent in case 2, is just to keep
everything the same for both cases. Replacing the exchange of keys for
mutually known pairs with some identity tokens sounds good though.
> Also note that the protocol does not provide forward secrecy, or explicit
> key confirmation. IMHO this makes it a bad choice for new applications
> even in cases 1 and 2.
>
Could you explain why there is no forward secrecy. Perhaps I have
misunderstood the term, but I thought that it meant that the discovery
of a session key between a pair (A,B) meant that their future keys could
be discovered?
I'm not too sure about the "explicit key confirmation" either :(
> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
> Nothing in this message is intended to be legally binding. If I revoke a
> public key but refuse to specify why, it is because the private key has been
> seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
>
On the positive side, the private keys of both parties are needed to
determine a session key (I think ;)
best wishes,
Mike.
--
Mike Connell [EMAIL PROTECTED] +46 (0)31 772 8572
[EMAIL PROTECTED] http://www.flat222.org/mac/ icq: 61435756
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: how i decode this?
Date: 1 Nov 2000 09:23:30 +0100
In article <8tn97q$aro$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>> If I was an ametuer
>
> I think we have vastly different definitions of professional, my
> definition includes actually having some knowledge of the subject. You
> obviously have at most minimal knowledge (and probably less), therefore
> you are an amateur.
The words "professional" and "amateur" aren't synonyms to "competent"
and "incompetent". A "professional" does something as a profession,
against payment of some kind. An "amateur" OTOH does not expect
payment for his activities, he does it just for the love of the
subject. The word "amateur" really means "lover" (compare with the
French "amour" and the Spanish/Italian "amore", or the ancient roman
god "Amor" who was the god of love).
Since a "professional" does his thing daily, it's natural that he
usually gains more skill and knowledge than the "amateur" who only
can do it in his spare time. However, there are exceptions: some
amateurs are actually more competent than some professionals. This
is particularly noticeable in subjects with a strong amateur
movement. One such subject is astronomy: the magazine "Sky and
Telescope" once had an article about particularly competent amateurs,
titled "The Professional Amateurs" (the title was of course a little
play with words, hinting that many people consider "professional"
synonymous to "competent"). Another such subject is radio
communication: in the 1920'es radio waves with wavelengths shorter
than 200 meters were considered useless by the professionals and
radio amateurs were given completely free access to them -- and
discovered that they could be very very useful. In this case the
amateurs turned out to be far more competent than the professionals.
Today a professional is usually regarded with higher esteem than an
amateur, and some people even thinks that calling someone an
"amateur" implies an insult. But a few centuries ago it was the
other way around: an amateur was then usually a well educated gentleman
who had unlimited free time and thus could devote himself to the
subjects he loved and become an expert at it, while a professional
was someone from the working class. One example: William Herschel,
who discovered the planet Uranus among other things, was an amateur
astronomer who personally owned the largest telescope of the world
in his time.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Rijndael file encryption question.
Date: Wed, 1 Nov 2000 09:31:36 -0000
"mac" <[EMAIL PROTECTED]> wrote in message news:8tngud$2gp9$[EMAIL PROTECTED]...
> Hello!
>
> I have the same problem and I posted it with subject "Newbie about
> Rijndael" (10/31/00).
> I was directed to Matt Timermanns code which is great. There are some
other,
> not so good but simpler methods. For example, if you have two byte string
to
> encrypt (block size = 16b) you can fill the last two bytes of a block with
> your string and put the number of 'good' bytes (two in this example) in
the
> first byte of a block. You can fill the bytes between(2-14)with '0' for
> example. When this block is decrypted you read the first byte and you know
> the length of the 'good' string from the end of the file.
> There are many different methods as there are many smart people out
> there. But the main point here is the question of standard. If 'Bob' who
is
> encrypted data and the key being sent to, doesn't have the same
> implementation of Rijndael (and the problem we discuss is solved
> differently) he won't be able to decrypt parts of the text that didn't fit
> in the size of a block. So, I think we are looking for the standard
> technique (if there is some).
Your concern is very well founded but is not specific to Rijndael since all
correct implementations of Rijndael will produce identical results.
You will have to tackle *many* further levels of standardisation in working
out how to encrypt messages that you wish to share with others.
One of these is called chaining and seeks to hide message blocks that are
the same by ensuring that they encrypted differently while also stopping
someone switching their order. NIST is currently looking at this for AES
and is likely to publish some existing and some new standards for AES use
shortly.
Another is that of padding where the message has to be padded out to fit the
length of the block in the cipher - 128 bits in the AES case.
And a third area is that of compression - where the messaage is compressed
before it is encrypted. This has two advanatges since it reduces the size of
the data to be encrypted whilst also removing patterns and redundancy in the
text to make it look more like random data (if the compression is good).
Again there are a considerable number of ways of doing this.
Unfortunately you will have to choose from a number of standards in each of
these areas and the chances are that your choices won't be the same as those
of other programs so you wont be able to interoperate with them.
There are many other issues as well (for example, character sets, canonical
message forms and message authentication) so your problems in selecting
standards are truly horrendous in magnitude. Welcome to the nightmare world
of secure interoperable messaging!
If you wish to experiment there is plenty of material on the web offering
standards in these areas from which to choose. But if you have a real world
need for secure messaging you would be better off using something that
already exists, such as PGP, where there are already many users who have it.
Brian Gladman
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Newbie about Rijndael
Date: Wed, 01 Nov 2000 17:20:54 +0800
This is an issue for all implementers of block ciphers actually. You
just have to use a consistent method of padding messages so they become
multiples of the cipher block size end to end. Maybe the upcoming AES
FIPS will give guidelines on how to do this. In the meantime, you might
be able to safely use the methods used in padding messages for iterated
hash functions such as SHA-1 (FIPS 180-1) and MD5 (RFC 1321). They add
nothing to the strength of the block cipher in any case; just make the
cipher easier to implement.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: [EMAIL PROTECTED] (Daniel)
Subject: Re: 3-dimensional Playfair?
Date: Wed, 01 Nov 2000 09:58:33 GMT
On Wed, 01 Nov 2000 00:24:43 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
>Has Playfair ever been (in modern times) practically applied
>to an alphabet of 256, i.e. 8-bit values? I am just curious.
>
>M. K. Shen
There are a few problems with a 256 bytes Playfair square :
1) Choose an appropriate key.
Say I would choose a key which is only 20 bytes long. This means that
(256 - 20) bytes will almost be numerically ordered. Therefore a key
must be lengthy/random enough to mix the Playfair-square to a maximum.
2) The PlainText must have an equal number of bytes.
If I would like to encrypt a Word-document which contains 19999 bytes,
I should add an extra byte. If not, I will not be able to define the
last bigram of the CT! Adding a single byte to an executable or some
other form of binary document, will cripple this document. Thus how
will this info be added into the CT?
3) It would be very difficult to implement a "double playfair" of this
kind :-)
The idea of a Playfair was that there was this single key to be
learned by heart. Everything else could be done by hand. This way an
agent didn't have to carry "extra material" which would make him even
more vulnerable...
regards,
Daniel
------------------------------
** 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
******************************
