Cryptography-Digest Digest #530, Volume #14 Tue, 5 Jun 01 20:13:01 EDT
Contents:
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: One last bijection question (Berton Allen Earnshaw)
Are RS codes a type of PRF? ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
CTR mode, BICOM, and hiding plaintext length (David Hopwood)
Re: BBS implementation (David Hopwood)
Re: Def'n of bijection (David Hopwood)
Lim-Lee vs safe primes for DH (David Hopwood)
curious about MD3 ("Tom St Denis")
Re: Def'n of bijection ([EMAIL PROTECTED])
Re: Best, Strongest Algorithm (gone from any reasonable topic)
([EMAIL PROTECTED])
Re: One last bijection question ("Douglas A. Gwyn")
Re: CTR mode, BICOM, and hiding plaintext length (SCOTT19U.ZIP_GUY)
Re: One last bijection question ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 5 Jun 2001 22:32:39 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
:> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> :> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
:> :> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> :> :> : Yes there will be equivalent keys but not enough to tell from
:> :> :> : random.
:> :> :>
:> :> :> Tell /what/ "from random".
:> :>
:> :> : Tell the plaintext. [...]
:> :>
:> :> I can very likely tell a randomly chosen plaintext from the decrypt of
:> :> an 1 byte cyphertext using CTR mode.
:> :>
:> :> Does the random plaintext have only 8 bits? If not, I can immediately
:> :> distinguish them.
:>
:> : Yes, but you are just brute forcing the key space. [...]
:>
:> Nope - just checking lengths.
: WHY DOES THE LENGTH AUTOMATICALLY GIVE YOU THE MESSAGE?
It doesn't. I never claimed it did.
:> :> Ah - you're sliding in that "for a single byte only"...
:> :>
:> :> As though we're discussing the trivial case of only 256 possible
:> :> messages...
:>
:> : Um yes that's what we were f$$$ talking about. For geez sakes stay on
:> : the same model!
:>
:> We are *not* discussing the case of 256 possible messages. Both BICOM and
:> CTR mode can encrypt *any* possible message.
:>
:> Given this wide distribution of possible messages, we are asking what
:> security is offered when encrypting a particular 8-bit message in BICOM
:> and CTR mode.
:>
:> BICOM with a 128 bit key maps it to one of 2^128 possible messages.
:> CTR mode maps it to one of 256 messages.
:>
:> The latter produces an 8-bit cyphertext with only 256 possible
:> interpretations.
:>
:> If you happened to know the message consisted entirely of space
:> characters, you could uniquely identify the message!
: C = 88 5e f7 fe c1 78 f0 6d 61 c8 bc ac 3a a1 09 ae 12 6b 4e 46 58
: What is P?
Apparently unable to produce any other coherent reply, Tom presents me
with another of his idiotic challenges again :-(
:> :> Of course it's not provably secure - unless you think only having 256
:> :> possible plaintexts out of the possible billions is something
:> :> worthwhile.
:> :>
:> :> We're trying to stop the attacker getting information about the
:> :> message.
:> :> Giving him the length of the message on a plate is a terrible start.
:>
:> : Why? Tell me how you can find K from C knowing the length?
:>
:> : Just tell me why it's a problem.
:>
:> You go round and round in circles. I've responded in some detail to both
:> these questions already.
: Well those are real questions. [...]
Which - as I have stated - I have already replied to, at least once.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Berton Allen Earnshaw <[EMAIL PROTECTED]>
Subject: Re: One last bijection question
Date: 05 Jun 2001 16:31:15 -0600
Just to clarify: the words 'bijection' and 'isomorphism' are not the
same thing. An isomorphism must also preserve the operations of the
two sets, while a bijection has no such requirement.
For example, if (A,x) and (B,X) are both groups with x being the
group-operation of A and X the group-operation of B, and if
f : A->B is an isomorphism, then f is a bijection *and* for all y,z in
A, f(y x z) = f(y) X f(z), i.e, f preserves the respective
group-operations.
--
Berton Earnshaw - [EMAIL PROTECTED]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Are RS codes a type of PRF?
Date: Tue, 05 Jun 2001 22:45:55 GMT
As far as I can tell RS codes (Reed-Solomon) are form of error correction
codes (???) that were (as an example) used in Twofish to map 8 bytes downto
4 bytes such that the distance is 5 bytes.
So could we make a 8-byte Feistel by appending a 4 byte key to one half to
make the 8 bytes then compute the RS code on it?
Do the remaining unfixed four bytes form a permutation of four bytes?
The way I would see the cipher working is
L,R = block
L = L xor RS(R||K1)
R = R xor RS(L||K2)
L = L xor RS(R||K3)
Of course some series of 8x8 sboxes could be used on the R/L inputs into the
RS to lower the DP and LP biases....
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 5 Jun 2001 22:42:23 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: Wagner does not want to say nice things about BICOM becasue it not a
: product from the crypto insiders club.
BICOM is cool. /Maybe/ it should allow for optional IVs, though -
whitening part of the file doesn't cope with *everything*.
: I am sure the big boys will eventually steal the idea as there own and
: never give me or Matt any credit for it.
I sometimes wonder how your ideas will be represented in
the straight-laced crypto textbooks of the future ;-)
[David Scott in chat rooms]
: I would make a good cop trying to catch pedafiles since I can't type
: better than a child I would not need to fake it.
<fx:giggles>
--
__________ http://rockz.co.uk/ http://alife.co.uk/ http://hex.org.uk/
|im |yler http://atoms.org.uk/ http://mandala.co.uk/ [EMAIL PROTECTED]
------------------------------
Date: Tue, 05 Jun 2001 18:51:09 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: CTR mode, BICOM, and hiding plaintext length
=====BEGIN PGP SIGNED MESSAGE=====
Tim Tyler wrote:
> David Hopwood <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> :> : CTR mode is just a bloody xor of some random bits against a
> :> : message. How can that possibly be less secure than BICOM?
> :>
> :> To repeat David Scott's example, consider a 1 byte cyphertext message.
> :>
> :> In CTR mode it maps to one of 256 possible plaintexts.
> :>
> :> With BICOM it maps to one of *billions* of possible messages.
> :>
> :> You tell me which is more likely to be secure.
>
> : The only way BICOM (with a 128-bit block cipher) can produce a 1 byte
> : ciphertext with probability greater than 2^-120, is if you decrypt a
> : 1 byte ciphertext and call the resulting junk the plaintext.
> : IOW, David Scott's example is of no practical relevance.
>
> It certainly indicates that use of counter mode leaks information
> about the plaintext in large quantities when the message is small.
>
> Is that "of no practical relevance"?
You're missing the point. To the extent that there is any security
problem, it arises from using a length-preserving mode in an application
where hiding the plaintext length is significant; that has nothing
whatsoever to do with bijectivity, and it is easily fixed.
Saying that BICOM is more secure when the ciphertext is 8 bits is
disingenuous, because BICOM will never in practice produce an 8-bit
ciphertext, unless the plaintext is deliberately contrived to do so.
> : If you want to disguise the plaintext length (in CTR mode or in any
> : other secure mode), that is quite easy, and does not require "bijective"
> : encryption in the sense meant by Scott; it simply requires padding
> : the original plaintext.
>
> That's a possibility - but it's not what us normally done when using a
> cypher in counter mode.
Well, it's what I recommend when using a cipher in any application that
requires hiding the plaintext length, regardless of mode.
Note that BICOM also leaks some information about plaintext length, and
the simplest fix for that is the same as for CTR mode: use sufficient
padding.
- --
David Hopwood <[EMAIL PROTECTED]>
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
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOx0bMTkCAxeYt5gVAQGZDAf8CbUeQ/hq/yaZkyhqUPuxTHQgB9iAV/vy
oD2TZv6sNlbD6WEOB5nBFN9Qk6wVgLjS1Jr5PvhmpGfWZ3DgDeeRAv9c0ge5okxA
vtow2mKX2WBkYxkpDWMJUqMbNnPTRwKaqnddrmJsC3s47oI3Y+aU/alzwAZrhypD
F3X2VnaehVcnzyT+QfjpEbqBNVGIB8G1RSFFmRHUFU/GhurilZo4gAK6vlxx9bcZ
p6UJj/iUDTytzEMuqkmTiKhzooiTzrgIF1zKFBHlr/pRqwn7MkErz7ZruyUKd+gt
SP9ve0TAYRux3DeJerga+tv0gUGYHGf9hgVt+nMXrg8zOuivX9WyQA==
=nwfh
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 05 Jun 2001 19:10:51 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: BBS implementation
=====BEGIN PGP SIGNED MESSAGE=====
Tom St Denis wrote:
> "Mark Wooding" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > > How do I know it is not on a short or degenerate cycle?
> >
> > Because if it is, you've managed to factor the modulus.
>
> As I understand it, if you know the length of the cycle you only know
> factors of (p-1)(q-1) right?
Technically, the cycle length is only proven to divide k = lcm(p-1, q-1),
not to be exactly equal to k. However, the probability that this length is
not equal to k is negligable, and therefore there is still a tight reduction
from factoring N to finding a short cycle (i.e. finding a short cycle cannot
be significantly easier than factoring).
- --
David Hopwood <[EMAIL PROTECTED]>
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
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOx0gjDkCAxeYt5gVAQExsQf/e1++N+zsEm2x1dfKQH7H5fc5LGzHYZbs
SQQz9T5DssPIz7L9iE4gbUJT0uZvMZx3b5u7L+LtoNqGgxyAZtZglJyXgEtVA3ra
gwSssyGrZfLCgNpGqfCriKdNCbJDMobKUkVlOdb/nygBi+VE7BRg+DebMHpWMe8B
fyQsj079DrURMZSXNpl7dfmLKGN4zL/j8ORG9yFR6EH0zRe99aV/ulN07bITb4NB
Aq48VWZm6UK2m7FpdHOMAOUK0a4cfuGjvdZFp4/dqsPvPnXLujBzUdsI9v1wdwR1
O+ziJLs3ktPkniN25/OZNn04mwn0xEMnYkzZixmBb7yCdVbqRPYpoQ==
=juYJ
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 05 Jun 2001 20:25:14 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
=====BEGIN PGP SIGNED MESSAGE=====
Tim Tyler wrote:
> [EMAIL PROTECTED] wrote:
> : "Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>
> :> If you take a 2048-bit ciphertext from a system that uses a 128-bit
> :> key, there are only 2^128 possible plaintexts, nowhere near the 2^2048
> :> that an ideal system would have. D.Scott's goal, in general terms,
> :> seems to be to develop a system that avoids having that property.
>
> : Precisely--that's the desirable OTP property that Scott is after.
> : But he's failing to recognize (or at least describe) his goal clearly. If
> : he put it as clearly as you have, it would become clear that the number
> : of decrypts can be no larger than the size of the keyspace, period.
>
> AFAICS, neither of you is discussing anything like what David Scott is doing.
>
> : In particular, if the key has fewer bits of entropy than the message, then
> : potential decrypts will not include all potential messages, period. This
> : follows from an elementary combinatorial argument.
>
> ...and is another mistake :-(
>
> The message can have *huge* entropy - even if there are only two possible
> messages: "0" and "1".
>
> All that is necessary for the "0" message to have a very large entropy is
> for it to be *extremely* rare. This follows from Shannon's definition of
> entropy.
You're wrong. If a source outputs 0 with probability p, and 1 with probability
1-p, then its entropy is maximised when p = 1/2. Saying that the 0 message
has a very large [Shannon] entropy is nonsense, because Shannon entropy
is not defined for particular messages.
The point that [EMAIL PROTECTED] made:
> : In particular, if the key has fewer bits of entropy than the message, then
> : potential decrypts will not include all potential messages, period.
is indeed precisely why compression doesn't hinder an attacker in recognising
plaintext. Compression cannot change the total entropy of the messages sent
under a particular key: that is determined by the usage characteristics of
the application. Once sufficient messages have been sent under a given key,
there will be enough information to brute-force it [*]. If we assume that the
key size is fixed (i.e. not an OTP), then compression makes no significant
difference to when this happens. Even though the distribution of decrypts will
be a little closer to the distribution of meaningful messages than it would
otherwise have been, in practice it will there will still only be one decrypt
that is actually meaningful, and it will be easy to recognise that decrypt
automatically, for message distributions that occur in real applications.
Note that this is true even if codebooks are used, since the messages in a
typical codebook don't have anywhere near equal probability of occurrance.
[*] I know that David Scott handwaves about other attacks than brute-force.
However, he hasn't put forward any coherent argument as to how bijective
compression would help against such attacks. Note that cryptanalytic
attacks against commonly used block ciphers generally require large
amounts of *exact* known plaintext (at least). In plausible situations
where exact known plaintext would be available - when data streams from
multiple sources are encrypted under the same key, for example - then it
would be available whether compressed or not.
- --
David Hopwood <[EMAIL PROTECTED]>
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
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOx0xoTkCAxeYt5gVAQEhwQgAhhDyDTAwU9HuzM6Gsv+Y8ZOqgyPdctA2
PPeP3/YBHotBbM4mIL9WxSIHFiLLSMDbEBO21SgaKyQV4rOzM+3XXCviuASQXcF+
1nK00Ypb5i1rNb4Fkt76t5Va60oxKdQy3zED9jDejceiK9Cdju6FhYtGAmEwSj8y
fgBrTXgOV4z53a6vpju7GuSfPiSHDYC1Rbi83MmU5aZWsLcACREmnKhqdYNOyFG0
cbJtP7PmooxtzWAlyXaJSpGMgYH3smSfBu97VXr8gSj46IMaV37guRQWq6qsC0ZA
0XtFlYOHa20OkUS0W4JjHVa0lO1XJFcH44C2UGVh5jviJBJHWavYgQ==
=vJgb
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 05 Jun 2001 20:47:03 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Lim-Lee vs safe primes for DH
=====BEGIN PGP SIGNED MESSAGE=====
Tom St Denis wrote:
> A question was raised whether Lim-Lee primes were better in terms of
> ease of generation and securtity versus a Sophie Germaine Prime.
>
> So we get our terminology all straight a Lim-Lee (LL) prime is one
> where it has several huge prime factors,
No. A Lim-Lee prime is a prime p such that *all* factors of (p-1)/2 are
sufficiently large (say >= 200 bits).
> a Sophie-Germaine (SG) prime is a prime of
> the form 2p + 1 where p itself is prime.
No. Here p is a Germain prime, and 2p + 1 is called a safe prime. It is
the safe prime that should be used as the DH modulus.
It's "Sophie Germain", not "Sophie-Germaine", BTW. Sophie is her first name.
> The chances of finding a bad LL public key (i.e where it generates a small
> by comparison) sub-group is low why not use a SG prime?
I don't see what argument you're trying to make here. The usual argument
for using Lim-Lee primes is that both parameter generation and the DH
exchange can be made more efficient (the latter because you're using
smaller exponents, and it is possible to do the necessary small subgroup
checks more efficiently).
- --
David Hopwood <[EMAIL PROTECTED]>
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
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOx022TkCAxeYt5gVAQFViwf/Qf0ms0o5DrCTJXxcvTy99ayJ8OgR8Eav
hk4ukCJSucZqlBwnyFRT17kbsf+0xaTlgnb/aZjctH+68VK12yetcdGMIem8CvMB
UppcSE5W75WFSbNWEYlnTy85pcAOzZNMpLwJkurNUVNPIUZCnve81KabNmqW9Sxk
bU1QmMm6r8dMxE0sqCZqUFUBZvEEP+QYcGRUz+QC2GgHqiP6Eq6KqPSZeOpLTljK
eiqPD4pGCxjKLehIaFxTSVxI02ck8zWvTGHTiqkdqar1/se2Vxu4eM7TCE/KLD1n
bXVR53y3B74hE5JHt+R15KU5edok3O3eulfGqFA54Jjml63bHFBs3Q==
=OEI9
=====END PGP SIGNATURE=====
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: curious about MD3
Date: Tue, 05 Jun 2001 23:14:07 GMT
In Applied Crypto P446 Schneier mentions MD3. I can't find the reference
online.
Does anyone have a description?
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
Subject: Re: Def'n of bijection
From: [EMAIL PROTECTED]
Date: 05 Jun 2001 19:15:41 -0400
Tim Tyler <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>: In other words, you are hoping that false positives are more likely.
[...]
>: ...some result in that direction is needed for BICOM to provide
>: any benefit at all. You don't seem to realize that any such result
>: is needed.
>
> This "result" seems unnecessary to me because I see it as being
> rather obvious.
Ah! It's true, because it's obvious! Why didn't I see that before!
This issue is *central* to any claims of increased security for BICOM.
Therefore, it needs proof, not handwaving.
And the idea doesn't even ``seem'' obvious, because of one fact you
keep ignoring: even if BICOM gives a bijection of binary files to
itself, almost all preimages under BICOM are not in fact plausible
messages. There is no a priori reason to believe that potential
decrypts will be rich in plausible messages; indeed it seems rather
unlikely.
> You seem to accept already that an "optimal compressor" is likely to
> make rejecting keys practically impossible.
No I don't, because it's completely false. It might sometimes prove
true, but only by coincidence: if the quantity of encrypted
information turns out to be close to the quantity of key material,
then security may be very high.
But that would be just a coincidence: the coincidence that message
volume was extremely low. You seem to think the compressor actually
did something magical to help the situation. It didn't. If the volume
of ciphertext is much larger than the volume of key material, then
compression really doesn't affect decryption effort (except perhaps
by a constant multiple).
And in practice, such low traffic cannot be expected. If volume is
really that low, then our hypothetical spies could simply memorize
OTP's every Easter.
Len.
--
In general, the Internet was not designed to accommodate deliberate
failures to communicate.
-- Dan Bernstein
------------------------------
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 05 Jun 2001 19:20:35 -0400
Tim Tyler <[EMAIL PROTECTED]> writes:
>
> I'm talking about a system involving a one-time random key stream, XORing
> it with the plaintext, and producing a cyphertext the same length as
> the plaintext.
If you really mean ``random'', and not ``pseudo-random'', then you have
indeed just described a OTP.
> Of course it is not the same system as the proof of perfect secrecy in the
> textbooks applies to.
Yes it is.
> I don't much mind what name is given to the system I described.
Okay, how about ``One-Time Pad''?
Len.
--
You're repeating the same old ``forks are bad and execs are
disastrous'' litany without _profiling_ where your time is actually
going.
-- Dan Bernstein
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: One last bijection question
Date: Tue, 5 Jun 2001 22:40:56 GMT
Tom St Denis wrote:
> Ok I thought bijections were when the codomain and domain are the same set.
No, the codomain is in the range (output) set, not the domain
(input) set. These can be totally separate spaces with
different properties (measured in different units, etc.).
A bijection is a surjection that is also an injection.
A surjection "covers the entire range"; for each element
in the range, there is at least one element in the domain
that maps to it.
An injection "preserves identity"; distinct elements in the
domain are mapped to distinct elements in the range.
Therefore a bijection is a one-to-one correspondence; it
translates from activity in the domain to corresponding
activity in the range and its inverse translates in the
opposite direction. "You can always tell where a point
came from (in the other space)." Or, "No information is
lost (by the mapping)", which is why it is a natural
requirement for lossless compression.
I really think the main thing that is confusing is that
the domain and range sets *in this application* have the
same properties, which allows them to be "identified"
with each other, so the function can be thought of as
an automorphism. Adding to the confusion is the fact
that nearly all bijective compressions of the D.Scott
variety are "open-ended" in the sense that iterated
mappings don't necessarily always reach cycles: if you
compress A you might get B (distinct from A); compressing
B gives C (distinct from A and B); etc. and there is no
guarantee you will ever find a duplicated output in this
sequence. This is quite unlike the case for permutations
on a finite set, where cycles are inevitable.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CTR mode, BICOM, and hiding plaintext length
Date: 5 Jun 2001 23:19:45 GMT
[EMAIL PROTECTED] (David Hopwood) wrote in
<[EMAIL PROTECTED]>:
>Saying that BICOM is more secure when the ciphertext is 8 bits is
>disingenuous, because BICOM will never in practice produce an 8-bit
>ciphertext, unless the plaintext is deliberately contrived to do so.
>
Mr Hopwood this whole debate started do to the fact Tom says
CTR mod RIJNDAEL is obviously more secure than RIJNDAEL BICOM.
To prove I asked what happens if you have a "one byte output
cipher text file". Tom says his CTR would map to 256 messages
and is totally secure. I stated BICOM would map to thousands
and thousands of possible input messages. The facts are
that in neither case would it be very likely that a one
byte output file be used. It was just an end point where we
could compare the two methods. I think if we took a thousand
byte file no easy comparisions could be made. Tom does not
understand the concept of Unicity distance we went round
and round on that. But yes in either case a one byte cipher
text output file is unlikely. However Tom doesn't even see that
it could map to thousands and thousands of possible input files.
The concept is beyond his ability to reason. But yes you and
I know in practice the odds of getting a one byte file ouput
are rare. But that doesn't mean it can't be used as an example.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: One last bijection question
Date: Tue, 5 Jun 2001 23:10:53 GMT
Stanley Chow wrote:
> The dictionary site give a definition for "isomorphism" that is more
> useful than their definition for "bijection".
? The dictionary defines isomorphism *in terms of* bijection.
An isomorphism preserves structure as well as identity.
A bijection preserves only the latter.
Here is an example:
D = domain = { real numbers }
R = range = { nonnegative real numbers }
f = mapping from D to R = exponential_function ("e to the ___")
+ = operation in D = addition
* = operation in R = multiplication
Note that (D,+) forms an Abelian group.
Note that (R,*) forms an Abelian group.
0 = identity in D
1 = identity in R
inverse of d in D = -d
inverse of r in R = 1/r
We have that for all a,b in D, f(a+b) = f(a)*f(b).
We say that this means that these groups are
*isomorphic*; whatever is going on with d's and +
has an exact counterpart in what is going on with
r's and *, and conversely.
In contrast, consider another example:
D = domain = { certain specific married women }
R = range = { their husbands }
f = mapping from D to R = "has as a husband"
This f is a bijection, but there is no structure
within D (nor within R). You could introduce
operation in D, e.g. "trade recipes", and R, e.g.
"watch TV together", but having done so there is
no reason to think that there are parallel
structures. I.e. Dot and Dolly might trade
recipes without their husbands Rick and Rob
watching TV together.
So an isomorphism is much more constraining
than a mere bijection.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
