Cryptography-Digest Digest #533, Volume #14 Wed, 6 Jun 01 09:13:01 EDT
Contents:
Re: function notation (injection, bijection, etc..) one last time (Mok-Kong Shen)
Re: function notation (injection, bijection, etc..) one last time (Mok-Kong Shen)
Re: Def'n of bijection (Tim Tyler)
Re: Bow before your new master (Paul Burke)
Re: Def'n of bijection (Tim Tyler)
cheksum on keyfile ("Gisli Sigurdsson")
Re: CTR mode, BICOM, and hiding plaintext length (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mark Wooding)
Re: fast CTR like ciphers? ("Tom St Denis")
Re: function notation (injection, bijection, etc..) one last time ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mark Wooding)
Re: cheksum on keyfile (Mats Kindahl)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: Def'n of bijection (Tim Tyler)
Re: Bow before your new master (Robert Strand)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: function notation (injection, bijection, etc..) one last time
Date: Wed, 06 Jun 2001 09:44:14 +0200
Tom St Denis wrote:
>
> It seems each time I ask people feud over terminology.
>
> Let me try again :-)
[snip]
Please don't misunderstand me but I think that for such
questions it is best to consult a textbook on algebra.
You would certainly find plenty of them in your local
library. The one that I happen to have at hand and I
find to be quite good is:
L. E. Sieger, Algebra. Springer-Verlag.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: function notation (injection, bijection, etc..) one last time
Date: Wed, 06 Jun 2001 09:57:46 +0200
Mok-Kong Shen wrote:
>
> L. E. Sieger, Algebra. Springer-Verlag.
Shame, I have often typo. The name is Sigler.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 08:13:06 GMT
[EMAIL PROTECTED] wrote:
: 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!
Well, it's obvious to *me*. I accept that doesn't necessarily mean that
it's obvious to everyone else. Thus my explanations.
: This issue is *central* to any claims of increased security for BICOM.
Note that it applies to any compression program, not just 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.
Well, if they were it would be really, really obvious - rather than just
obvious.
: There is no a priori reason to believe that potential decrypts will be
: rich in plausible messages; [...]
...except for the fact that compression makes target files smaller, while
increasing the lengths of other files, thus making their density at
small output sizes greater.
: indeed it seems rather unlikely.
Well, you *you*, maybe.
:> 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.
You can use a three bit key and compress huge files. If all
decompressions look like plausible messages it will be hard
for an attacker to tell which one was intended.
--
__________
|im |yler http://rockz.co.uk/ http://alife.co.uk/ http://atoms.org.uk/
------------------------------
From: Paul Burke <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To:
alt.drugs.pot,sci.electronics.design,sci.electronics.repair,sci.environment
Subject: Re: Bow before your new master
Date: Wed, 06 Jun 2001 08:23:22 +0000
"Mike S." wrote:
> if you take into account the on-purpose attempts at sounding
> redneck and inflaming readers.
I for one am against discrimination based on neck colour. Smash
cervicism!
Paul Burke
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 08:27:18 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
: 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.
Nope ;-)
: If a source outputs 0 with probability p, and 1 with probability
: 1-p, then its entropy is maximised when p = 1/2.
You are talking about the entropy of the entire source. I was talking
about the change in entropy of an observer when looking at the rare "0"
message.
If you insist on talking about different things when I made it clear that
I was talking about a message rather than a source, it's hardly suprising
that you come to diferent conclusions.
: Saying that the 0 message has a very large [Shannon] entropy is
: nonsense, because Shannon entropy is not defined for particular messages.
You can talk about the change in information of a recipient as the
entropy of a message - the "suprise value" of that message.
It's true that entropy is not defined for a particular message
*in isolation*, but I was clearly not talking about a particular message
in isolation - I have given it a probability of occurring, and that is
enough to give it an entropy.
: 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.
Now you're just being silly. This point is well established.
: Compression cannot change the total entropy of the messages sent
: under a particular key that is determined by the usage characteristics of
: the application.
Who claimed that it could? What it changes in the entropy-per-bit.
: Once sufficient messages have been sent under a given key,
: there will be enough information to brute-force it [*].
Unless those messages have maximal entropy, for example.
: If we assume that the key size is fixed (i.e. not an OTP), then
: compression makes no significant difference to when this happens.
What leads you to that erroroneous idea?
: 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.
Nope. Your assertion depends critically on both the message size, and the
quality of the compressor for the target data.
You can't just make incorrect bold generalisations like that and expect to
get away with it.
: 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.
Analaysis based on frequency of occurrence of messages is indeed
possible, and is likely to have more success in the long term.
However it needs many messages before it can be applied, and is a far cry
from your decrypt, decpmpress, test for plaintext signature methodology.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Gisli Sigurdsson" <[EMAIL PROTECTED]>
Subject: cheksum on keyfile
Date: Wed, 6 Jun 2001 08:34:42 -0000
I have a keyfile on which I know the checksum, but when I calculate it"s
value I am never close to the answer. According to the manual the checksum
is supposed to be calculated using the following steps:
"The checksum is computed as the complemented sum of all the bytes in the
key record, including the key record length."
No, my question is this: Has anybody come across this kind of checksum
calculation, and would you guess the "complemented sum" is a 1's or a 2's
complement ?
/GGS
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: CTR mode, BICOM, and hiding plaintext length
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 09:29:12 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
: 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; [...]
Yes [to the latter part anyway].
: that has nothing whatsoever to do with bijectivity [...]
Not my claim.
: and it is easily fixed.
That maybe - but it's not fixed in (for example) the CTR mode that was
advocated for use with AES.
: 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.
No that's silly. BICOM is more secure when the *plaintext* is 8 bits.
In that case CTR mode will produce a weak 8-bit output.
:> : 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.
Very sensible, no doubt.
: Note that BICOM also leaks some information about plaintext length [...]
Indeed - but not enough to reduce the worst case scenario to 256 messages.
I believe the worst case for BICOM produces about 2^128 possible
plaintexts - still "quite a few" - even if they don't completely
span the space of all possible plaintexts.
BICOM is not perfect on this front - but it is a *lot* better than CTR
mode.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 6 Jun 2001 10:14:55 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Pollard-rho or just trial division? :-)
I just used the `factorint' program that comes with saml. I think it
used trial division and Pollard's rho in this case, but the program can
also use an MPQS if it can get there without segfaulting.
-- [mdw]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: fast CTR like ciphers?
Date: Wed, 06 Jun 2001 11:23:37 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:9fkhn7$l95$[EMAIL PROTECTED]...
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:s0gT6.40533$[EMAIL PROTECTED]...
> >
> > "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> > news:9fk1i4$aaf$[EMAIL PROTECTED]...
> > >
> > > Tom St Denis <[EMAIL PROTECTED]> wrote in message
> > > news:TsbT6.37526$[EMAIL PROTECTED]...
> > > >
> > > > "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> > > > news:U_aT6.37003$[EMAIL PROTECTED]...
> > > > > I was just thinking. It's probably very easy to make a super-fast
> > > cipher
> > > > > thats made for one-way encryption for CTR modes....?
> > > > >
> > > > > We could make a UFN which favors the encryption direction for
> > diffusion
> > > > and
> > > > > designed to be fast?
> > > >
> > > > Just to start the discussion I have a toy cipher (designed in all of
> > five
> > > > mins) that we can use as a model of discussion.
> > > >
> > > > I call it MUD for "Mirky UnderDeveloped". it's not intended for
real
> > > > use....
> > > >
> > > > It's somewhat fast and on 8-bit cpus would be a dream to implement.
> The
> > > > idea is that the cipher is used in CTR mode only so the decryption
is
> > > > neither required nor provided. The cipher is designed such that
going
> > > from
> > > > plaintext to ciphertext is secure but not the vice versa...
> > > >
> > > > http://tomstdenis.home.dhs.org/src/mud.c
> > >
> > > Could you double-check the URL? I'm getting errors.
> >
> > Stupid windows... arrg I think my server was not running try
> >
> > http://24.112.8.23:8080/src/mud.c
> >
> > BTW the design is not suppose to be secure. So I won't be surprised if
> you
> > break it.
> >
> > The point of posting this is to highlight a new design philosophy. The
> idea
> > is we want a block cipher were we can sacracfice alot as long as the
> > encryption routine is secure. I.e Guessing the output is hard without
the
> > key.
> Actually, it looks pretty vanilla -- what's the different philosophy.
Well I designed it so it's fast and simple. I would consider four xors and
a lookup rather trivial.
> > The idea is that the cipher will be used in either a hash or CTR mode of
> > operation.
> >
> > The example I posted was a simple UFN with a 8-bit round function. It's
> > most likely not secure (although I can't see obvious breaks I bet they
> will
> > come of the form of either some impossible differential or differential
> that
> > simply cancels out and has little active sboxes).
> It looks vulnerable to a differential going in the backwards (decrypt)
> direction. And, with sufficient (O(2**28)) known plaintexts, you're
likely
> to be able to find a pair of ciphertexts with the right starting
> differential.
Ah, but the cipher is never used backwards that's the beauty of this idea.
You would have to mount an attack base on the knowledge it's used in counter
mode
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: function notation (injection, bijection, etc..) one last time
Date: Wed, 06 Jun 2001 11:26:09 GMT
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Nicol So <[EMAIL PROTECTED]> writes:
> > [EMAIL PROTECTED] wrote:
> >>
> >> "Tom St Denis" <[EMAIL PROTECTED]> writes:
> >>>
> >>> Bijection. Any function F : A => B, where all elements of A point
> >>> to unique elements of B (required to be an injection), and A and B
> >>> have the same cardinality (required by the surjection requirement).
> >>
> >> Correct.
> >
> > No. See my example in another message.
>
> You're right; thanks. I was trying to accomodate Tom's somewhat loose
> language, and ended up making careless mistakes.
>
> Tom: I don't mind answering questions on usenet, and neither do others,
> but at this point it really wouldn't hurt to pick up a math text. This
> is important notation, and the definitions are quite standard. It's
> not a winning plan to keep avoiding rigorous language.
No offense but the same could be said for half of you. This is the third or
so time I asked and each time I get conflicting answers.
I shall read up a bit if I can (I don't even know if my texts explain those
terms).
Tom
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 6 Jun 2001 12:12:31 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
> No. You are talking about an unknown 1-byte cyphertext under a
> *known* key.
No. That wasn't my error. If k is known, there is only one possible
plaintext!
Where I came unstuck was assuming that the symmetric cipher was
noncompressing. I now see that, given David Scott's bizarre chaining
mode, the noncompressing assumption was invalid. (I'm reading the
version described in his public comment on AES.)
It's a grotty chaining mode, by the way. It's basically ECB with a knob
on the end. It retains the ECB property that equal plaintext blocks
encrypt to equal ciphertext blocks. There is no randomization in the
encryption process. This chaining mode cannot possibly give you a
secure cipher in the real-or-random sense (or any of the related
senses). Doing nonrandomized compression beforehand doesn't help.
It leaks too. The final plaintext block given to the cipher can't be
zero. This isn't very interesting, but it shouldn't happen.
I still don't see the point. Using a well-analysed block cipher in CTR
or CBC mode seems a much better idea.
-- [mdw]
------------------------------
Subject: Re: cheksum on keyfile
From: Mats Kindahl <[EMAIL PROTECTED]>
Date: 06 Jun 2001 14:23:18 +0200
"Gisli Sigurdsson" <[EMAIL PROTECTED]> writes:
> I have a keyfile on which I know the checksum, but when I calculate it"s
> value I am never close to the answer. According to the manual the checksum
> is supposed to be calculated using the following steps:
>
> "The checksum is computed as the complemented sum of all the bytes in the
> key record, including the key record length."
>
> No, my question is this: Has anybody come across this kind of checksum
> calculation, and would you guess the "complemented sum" is a 1's or a 2's
> complement ?
The same scheme is used for the checksums of Motorola
S-records. There, the "complemeted sum" is the 1-complement: that is,
the bitwise complement of the value.
The S-record checksum is truncated to 1 byte, i.e., two hexadecimal
digits, prior to being appended to the S-record.
Some examples of S-records are:
S00700006266696C5B
S21400010002F022F042F062F082F0A2F0C2F003F0B9
S21200011023F043F063F083F0A3F0C3F0FFFF8C
S804000000FB
where the "S0", "S2", and "S8" are the types of each record and does
not participate in the checksum calculation, e.g.,
~(04 + 00 + 00 + 00) = ~(04) = FB
Hope this might be of some help,
--
Mats Kindahl, IAR Systems, Sweden
Any opinions expressed are my own, not my company's.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 6 Jun 2001 12:24:39 GMT
[EMAIL PROTECTED] (Mark Wooding) wrote in <[EMAIL PROTECTED]>:
>
>Where I came unstuck was assuming that the symmetric cipher was
>noncompressing. I now see that, given David Scott's bizarre chaining
>mode, the noncompressing assumption was invalid. (I'm reading the
>version described in his public comment on AES.)
>
>It's a grotty chaining mode, by the way. It's basically ECB with a knob
>on the end. It retains the ECB property that equal plaintext blocks
>encrypt to equal ciphertext blocks. There is no randomization in the
>encryption process. This chaining mode cannot possibly give you a
>secure cipher in the real-or-random sense (or any of the related
>senses). Doing nonrandomized compression beforehand doesn't help.
What are you talking about? I think there is more than one place
you have come unstuck.
>
>It leaks too. The final plaintext block given to the cipher can't be
>zero. This isn't very interesting, but it shouldn't happen.
Again what are you talking about the last plaintext block
can't be zero are you serious?
>
>I still don't see the point. Using a well-analysed block cipher in CTR
>or CBC mode seems a much better idea.
It not wonder you don't see it. You have ni idea what is happening,
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 6 Jun 2001 12:18:47 GMT
[EMAIL PROTECTED] (JPeschel) wrote in
<[EMAIL PROTECTED]>:
>>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
>
>
>>Actually I am begining to think you don't know what a
>>OTP is for perfect security. If one can limit the set
>>of messages to N bits then you use XOR with the pad
>>to create messages of all the same lengths That would be
>>N in this case. If one has many messages of different lengths
>>and you use an OTP for example to XOR with the short messages
>>and send that you have just limited the possible messages to
>>a subset of the possible messages you may wish to send.
>>Joe look it up. Ask Casmir.
>> Perfect security is a far stronger requirment where no possible
>>messages one wants to be encrypted can be eliminated. If you
>>only match the length of varible messages you have eliminated
>>the possibility of the other messages being encrypted.
>>Has Tom confused you.
>
>Nope, you two cats -- you and Tim -- appear to have added more
>constraints to what constitutes a one-time pad. If you haven't
>added more, tell me where I can look up and find your definition
>of a one-time pad -- uh, somewhere other than Tim's and your posts. :-)
>
Joe there is more than one form of the OTP. But in the
example above Tim and I where talking about an OTP with
perfect security in the Shannon sense. Which as even you should
know requires not information about plain text to be given,
and if your messages set is of various lengths it would require
all messages to be encrypted to same length.
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: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 12:19:59 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
: David Hopwood <[EMAIL PROTECTED]> wrote:
: : Tim Tyler wrote:
: :> [EMAIL PROTECTED] wrote:
: :> : 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.
: Nope ;-)
I really don't know /why/ I'm finding it necessary to explain such basic
stuff in sci.scrypt - but the entropy, H of a message m is given by
H(m) = log2(1/p(m)) where p(m) is the probability of the message
occurring.
Consequently - as I stated - all that is necessary for a message to
have a very large entropy is for it to be *extremely* rare, and thus
arise with a very low probability.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Robert Strand <[EMAIL PROTECTED]>
Crossposted-To:
alt.drugs.pot,sci.electronics.design,sci.electronics.repair,sci.environment
Subject: Re: Bow before your new master
Date: Wed, 06 Jun 2001 22:26:33 +1000
"Mike S." wrote:
> It was kinda funny from a psychology perspective how the
> poster was trying to inflame as many people as possible
> with their shocking statement and language. Surprisingly,
> this message was fairly well composed by Usenet standards,
> if you take into account the on-purpose attempts at sounding
> redneck and inflaming readers. Quite the irony...
There's a new OS people are running to use Usenet these days, it's becoming
quite popular, I believe it's called Loonix :).
Regards
Rob
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 12:27:03 GMT
JPeschel <[EMAIL PROTECTED]> wrote:
: Tim Tyler [EMAIL PROTECTED] writes, in part:
:>JPeschel <[EMAIL PROTECTED]> wrote:
:>: Tim Tyler [EMAIL PROTECTED] writes, in part:
:>:>OTPs do *not* have perfect secrecy if messages can be of varying lengths
:>:>and the plaintexts and cyphertexts are of equal lengths.
:>
:>: I don't follow this. It sounds as if you are re-defining an OTP.
:>
:>What don't you follow about it?
:>
:>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.
: That's an OTP and its secrecy is perfect.
Not according to the definition of perfect secrecy.
Perfect secrecy implies there's no information about the plaintext in the
cyphertext. That is clearly not true for the system described above.
:>I am claiming that the result does not have perfect secrecy - assuming a
:>reasonable space of variable length files as possible messages.
: What you've written immediately above suggests an addiotional property
: for an OPT that leads me to believe you are re-defining OTPs.
[...]
: Names are important; otherwise no one will have a clue what you're talking
: about.
: If you insist upon an additional property that an OTP must possess, you
: are re-defining it, and I am not sure why, or to what pupose.
What "additional property" are you talking about.
If you mean my statement that the requirement that some messages have
different lengths from one another, that's not really an "additional
requirement" - I'm just making explict the fact that I'm not only
considering a degenerate case that would have perfect secrecy.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 12:28:08 GMT
JPeschel <[EMAIL PROTECTED]> wrote:
:>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
:>Actually I am begining to think you don't know what a
:>OTP is for perfect security. If one can limit the set
:>of messages to N bits then you use XOR with the pad
:>to create messages of all the same lengths That would be
:>N in this case. If one has many messages of different lengths
:>and you use an OTP for example to XOR with the short messages
:>and send that you have just limited the possible messages to
:>a subset of the possible messages you may wish to send.
:>Joe look it up. Ask Casmir.
:> Perfect security is a far stronger requirment where no possible
:>messages one wants to be encrypted can be eliminated. If you
:>only match the length of varible messages you have eliminated
:>the possibility of the other messages being encrypted.
:>Has Tom confused you.
: Nope, you two cats -- you and Tim -- appear to have added more
: constraints to what constitutes a one-time pad. If you haven't
: added more, tell me where I can look up and find your definition
: of a one-time pad -- uh, somewhere other than Tim's and your posts. :-)
We're using the standard definition AFAIK.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
** 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
******************************
