Cryptography-Digest Digest #548, Volume #14 Thu, 7 Jun 01 10:13:00 EDT
Contents:
Re: Is this a weakness in RSA key generation? (Bodo Moeller)
Re: shifts are slow? (Jeffrey Williams)
Re: Brute-forcing RC4 (S Degen)
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: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Humor, "I Must be a Threat to National Security" ("Tom Gutnick")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: Notion of perfect secrecy (SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Is this a weakness in RSA key generation?
Date: 7 Jun 2001 12:19:00 GMT
Bill Unruh <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] (Mark Borgerding):
>> I found that pgp 2.6.2 may sometimes generate a private exponent n
>> that does not entirely match the RSA spec (as I know it)
>> 1) d*e = 1 , mod (p-1)*(q-1)
>> 2) d*e = 1 , mod (p-1)
>> 3) d*e = 1 , mod (q-1)
>> pgp seems to occasionally generate a key that satisfies 2&3, but not 1.
>> I know that stmt #1 implies 2&3, but the reverse is not true.
>>
>> My question is: is this something to worry about? What effect would
> Yes. It will not work. You will not be able to decrypt anything.
Wrong, such keys will work perfectly. There is no requirement that
d*e == 1 (mod (p-1)(q-1)).
It is only necessary that
d*e == 1 (mod lcm(p-1, q-1)),
which is exactly equivalent to 2&3 above.
(To prove that RSA decryption works in this case, consider decryption mod p
and mod q and apply the Chinese Remainder Theorem. Most RSA decryption
implementations use the CRT anyway, and in that case only d mod p-1
and d mod q-1 are actually used -- the exact choice of d does not
matter at all.)
--
Bodo M�ller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: shifts are slow?
Date: Thu, 07 Jun 2001 07:35:02 -0500
IIRC, the original poster was talking about a P4, not a unique selection of
hardwired gates.
Before pipelined processors, shifts were frequently faster than adds and
almost always faster than multiplies (or divides). Pipelining instructions
can (and almost certainly will) change some of our known facts about
programming.
If you really want to optimize your program for a given processor, you really
need to spend some time studying the data book for that processor. It should
contain lots of information about the relative speeds of instructions. Note
that figuring things out to an optimal level is not easy when dealing with a
pipelined processor as there are all kinds of options which will affect the
relative speed of an instruction.
Realistically, given the speed of today's processors, and the insanely low
cost per MIP, MOST OF THE TIME, you'd be better off writing your program in a
high-level language and using an optimizing compiler which can take full
advantage of the target processor. Yes, if you really know the target
processor well, you could probably hand code the program to be faster, but
that "if" is huge. Very few people will know a target processor well enough
to be a good optimizing compiler. More to the point, given the rate at which
new processors are introduced, it becomes much more difficult to find people
who can beat the optimizing compiler.
Jeff
Tom St Denis wrote:
> "Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
> news:euGrY4t7AHA.277@cpmsnbbsa07...
> > The new reality is the same. It's just that for a register to shift it
> needs
> > to make use of itself as a shift register, so in a single clock bit 30
> moves
> > to 31, 29->30, 28->29, 27->26 . . . 1->2, 0->1. In order to shift by X
> > takes X clocks. Also because we have gotten to such high frequencies and
>
> This is so wrong. I can shift a 512-bit register 211 bits in one cycle.
> (Just re-wire the outputs).
>
> <snip>
>
> Boolean operations like AND,OR,XOR,NOT can take one cycle since you just
> apply all the logic in parallel. So if 1 AND takes 1 cycle 32 ANDs should
> take 1 cycle too. You get a bit of delay to synchronize the bits but
> generally that's low.
>
> Tom
------------------------------
From: S Degen <[EMAIL PROTECTED]>
Subject: Re: Brute-forcing RC4
Date: Thu, 07 Jun 2001 14:35:37 +0200
WOW
That long?
I was expecting something in the line of.... a week :P
Thanx anyways
Ichinin wrote:
>
> Hi.
>
> S Degen wrote:
> >
> > Howmuch time would it take to brute-force a 40 bit RC4 key? (Ofcourse
> > depending on the processor-speed, but lets say a PIII 500)
>
> Don't really know about a P3/500, but compare
>
> In my home lab i did a brute force estimate once on RC4
> (including all key setups and guessing).
>
> Using:
>
> 1 x P1/133 acting as a job server
> 1 x P2/266 - slave client
> 1 x AMD K6/350 - slave client
> 1 x P3/700 (Bus can be clocked to 117 Mhz; == ~819 Mhz)
>
> ..i estimated that with a C++ plugin for each slave
> client, i could brute force a 2^40 key in roughly 180
> days.
>
> The computing power could be compared to 2 to 2.5 P3/500,
> so, if my guess is correct, around 180 x 2 (or 2.5) days.
>
> >
> > This is the case:
> > You have a 128 bit (ASCII) text, and the encyphered version of it. This
> > version is encyphered with a 64 bit secret key, but of those 64 bits, 24
> > bits are known. (Leaving 40 unkown bits)
>
> Is this text always 128 bits? Are there fixed fields or headers in it?
> Then there are a more efficient attack.
>
> > I would like to know how long it would approximately take to calculate
> > the 40 bit secret key.
>
> Calculating the K and guessing (by brute force) are 2 separate things.
>
> > (Worst case scenario)
>
> Worst case scenario is bruteforce.
> >
> > Thank you if you can help me.
>
> NP.
>
> .Reg's,
> Ichinin
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 7 Jun 2001 12:39:38 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<Z2IT6.49208$[EMAIL PROTECTED]>:
>
>No perfect secrecy is defined as having no ability to tell one plaintext
>from another. Who cares if you know the entire set of plaintexts (hint
>you will always know the set), you won't know which is the right one.
No perfect secrecy is dedined for a closed system where any possible
encrypted message recieved can map back to all possible input messages.
if you have as part of the input set messages of various lengths,
That you apply a one time pad to and send. If I get a short cipher
text. And its assumed I know all about your method and the set of
possible input messages. Then you have told me its not the longer
message. Its actually quite clear.
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: 7 Jun 2001 12:28:14 GMT
[EMAIL PROTECTED] (JPeschel) wrote in
<[EMAIL PROTECTED]>:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes, in part:
>
>[EMAIL PROTECTED] (JPeschel) wrote in
><[EMAIL PROTECTED]>:
>
>>>Point me to where Shannon says that the length of the plaintext
>>>must be kept secret.
>
>>Joe do you really need your hand held? I read the whole thing
>>I think you're a big boy and can read it yourself.
>
>Save your bullshit, Dave. If you can point me to where Shannon says
>the length of the plaintext must be kept secret, do it.
>
>Quit fucking around. :-)
>
Joe it never says the plaintext length must be secret it says
any interecept message must be able to map back to any possible
message that could have been sent. If there are several messges
of different lengths if you only XOR the shorter one and sent one
of them. The attacker would know it was not one of the longer
messages. Thats not saying you nescessiarly know what the messages
is. But in perfect sercrecy you can't eliminate any message that
might have been sent.
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: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 12:38:03 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: An encrypted message Y, on arrival in the hand of the opponent,
: has a 'concrete' form. It has a bit pattern and also a length,
: which in the case of OTP processing with xor is equal to
: the length of the plaintext X that the sender has input
: into his software. Trivailly, (note) X has ALSO a concrete
: form. We consider our X to be the original, i.e. the
: ASCII text that the sender has actually written down
: manually. Shannon's argument guarantees in this case that
: the opponent's knowledge about X is not enhanced by his
: having 'in addition' a corresponding Y. Now consider
: carefully what this actually claims. Note that the
: term 'his knowldege about X' is dependent on the very
: 'existence' of X. Before X comes into being, 'his
: knowledge about X' is not well-defined (excepting
: perhaps the 'idea' of its non-existence). After X comes
: into being, the opponent's a-priori knowledge of X
: (now that we can talk about X) 'can' include the size of X.
That's possible.
If the attacker knows in advance that all messages that could be
sent have the same size (which is what you are saying here) then
the resulting system has perfect secrecy.
I think this is the system which Shannon's proof relates to.
However, note that this systems is not the OTP as generally
described. The OTP is not normally considered to be constrained
in such a way that all messages are known on a-priori grounds to
be the same size.
: One can however reduce that a-priori
: knowledge through varying the size of X, i.e. through
: somehow transforming X to X_1 (reversibly, in effect
: doing a superencipherment step) such that the size of
: X_1 is now random (within a range that is feasible, of
: course) and send with OTP processing the corresponding
: Y_1. Shannon's argument again applies, now concerning
: the pair X_1 and Y_1. But the 'a-priori knowldege of
: the opponent' (and with it his a-posteriori knowldege,
: of course) gets changed. For now, in lieu of the length
: of the original ASCII text, he has a random value which
: is no information for him.
You seem to be talking about varying the size of
the plaintext in the case where the attacker knows
it is of fixed size.
Scott and I are have previously discussed almost the
exact opposite - taking plaintext of varying lengths
and padding them until they are all indistinguishable
from one another when encrypted.
If your process that translates from X to X_1 is
key dependent then you won't lose anything significant - but
you won't gain in security either, if the attacker couldn't
distingish the plaintexts in the first place because they
all had the same length.
Your procedure may well have value if the length of X
is *not* known in advance, though.
: [...] there could be cases that the size plays a role.
: To illustrate, let's consider a hypothetical case where among the
: messages communicated between a company A and a company B there is a
: particular class of messages that always has a fixed length,
: because it is a routine purchasing order that the manager
: of A makes through filling a form (nowadays commonly in
: a window on his computer) and sends. Let's say that
: the other messages between A and B are all of varying
: lengths, e.g. diverse business letters etc. etc. Now the
: opponent can simply count the number of messages of the
: said fixed length and know how many orders A has placed
: with B [...]
Yes.
: One might say that this belongs to traffic analysis and not
: encryption proper [...]
Pah! Cryptanalysis usually involves analysing traffic. ;-)
: [...] but anyway information is still information. Through randomizing
: the size of the messages we make it difficult for the opponent to
: gain that information.
Key dependent padding would certainly help obscure length information -
though it's not very likely to produce perfect secrecy,
since for any message you'll still have an upper bound on the
size of the plaintext if given the cyphertext.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Tom Gutnick" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Humor, "I Must be a Threat to National Security"
Date: Thu, 07 Jun 2001 12:47:10 GMT
There are loads of computer security jobs advertised in the Washington Post
and on company web sites in the area. Sorry you're having problems, but an
interview is no guarantee of getting a job offer -- and don't assume that
it's because you're a threat. More likely, you don't have the particular
skill set they're looking for, or you at least couldn't convey the fact that
you did have the skills desired. If you talk to people in the placement
business, you'll hear that it's not unusual to send out hundreds of letters
and have dozens of interviews before landing a position.
Incidentally, your posting was riddled with grammatical errors. How is your
spoken language? Speaking as someone who has interviewed and hired many
technical people over the years [but I'm not in such a position currently],
I know that at least unconsciously I think less highly of a job candidate
who can't speak clearly and correctly.
>"David G. Boney" <[EMAIL PROTECTED]> wrote in message
news:E4HT6.3857$[EMAIL PROTECTED]...
>
>My frustrations with trying to find a job in government service are
summarized in an essay I have posted that is >titled, "I Must be a Threat to
National Security". I have also placed my rejection letters from the CIA and
NSA on->line.
>
>http://www.seas.gwu.edu/~dboney/security.html
>
>If anyone knows of any computer or network security engineer positions
open, developer or administrator, in the >Washington, DC area, that are
commercial, non-government, non-government contractor, and don't require a
>clearance, please drop me a line. You can surf my home page to get a
picture of my qualifications. Resume >available upon request.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 7 Jun 2001 12:45:25 GMT
[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>Tim Tyler <[EMAIL PROTECTED]> writes:
>> Tom St Denis <[EMAIL PROTECTED]> wrote:
>>: Or if you just pad the bloody thing to a multiple of say 64 bytes.
>>: [...]
>>
>> Still not enough for perfect secrecy :-(
>
>Right--no matter what ``a multiple'' means. It could mean 64 million
>bytes, or 64 quintillion terabytes, but that's ``still not enough for
>perfect secrecy.'' If the ciphertext has finite length, then some
>possible plaintexts will be longer.
>
>That's why all messages must be infinite in length in order to enjoy
>``perfect secrecy''. (And note: this is true whether or not any sort
>of compression is used.)
That why proofs for OTP state lets assume a max length for messages.
As soon as you fix the length of longest message possible. You then
only have a finte set of messages and then you can make a perfect
secrecy system.
If you allow infinte messages of any type well then your in trouble
like you have observed.
>
>Len.
>
>
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: Notion of perfect secrecy
Date: 7 Jun 2001 13:09:19 GMT
[EMAIL PROTECTED] (Jeffrey Walton) wrote in
<9fne9v$b8k$[EMAIL PROTECTED]>:
>Hello David,
>
>I apologize for my ignorance. I agree with Neil. I think I
>understand your point with padding. But I'm not sure I
>agree with it.
>
>For example, if blocks are 64 Bytes, on average the last
>block of 64 bytes will contain 32 padded bytes (again, on
>average). This would imply that the adversary would know
>what the plain text padded bytes are (some hand waving, but
>a possible assumption). But this additional information
>does not lend itself to plain text or key recovery (except
>for the average of 32 trailing bytes).
>
>I don't feel this is in opposition to Shannon's theories.
>But there are clearly much more astute minds that visit this
>NG. They could probably reveal my flawed thinking. I think
>other cryptosystems could be vulnerable, but not the one
>time pad.
>
>For whatever reason, padding may be beneficial; but I don't
>feel its required for the OTP. I also don't feel it
>compromises the plain text either.
Appearantly Shannons ideas are not somthing the crypto
community want wide spread. There are different levels of
security. If you look at all possible sentences. An use
an OTP the way you wish. It most likely will be very
secure. Hear me again. very secure. But it wont be
"perfect secrity" unless it is endishable from any other
message you might send. Its not rocket sciense. It based
on his observation of closed systems. To prove it you
need a fixed set of messages. Any message can with different
keys map to any possible cipher text. And any cipher text
can map to any input messages. IF your input set consisits
of 100 messages 50 of length 10 bytes and 50 of length 20
bytes. And you system either sends out a 10 or 20 byte
message. Based solely on length of input message. You may
have a secure system. Since you now have message hidden
in a pool of 50. You no longer have perfect secureity
since you have reduced the pool from 1 out of a 100 by
sending either a 10 byte or 20 byte message. It is not
rocket science. But I think there seems to be a large effort
to keep peoples minds closed. Exactly why I can't say.
>
>Respectfully,
>Jeff
>
>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in
>message news:[EMAIL PROTECTED]...
>| [EMAIL PROTECTED] (Tom St Denis) wrote in
>| <kmBT6.47362$[EMAIL PROTECTED]>:
>|
>| >Ok this has gone on too long.
>| >
>| >Typically what you guys are missing is that the length of
>the message is
>| >not the secret. It's the contents of the message.
>|
>| <crap sniped>
>|
>| >At any rate if the length is important just pad the
>message. Make the
>| >message fit to be a multiple of say 64 bytes or
>something.
>|
>| DUH??? GEE WHIZ length may mean something so pad to make
>it
>| match longest message for "perfect security" READ SHANNON
>YOU IDOIT
>| you can't have it both ways little BOY.
>|
>| 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!
>|
>
>
>
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: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 13:06:31 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> : Tim Tyler wrote:
:> :> Consider BICOM for example. It can map a 8 bit cyphertext to
:> :> one of some 2^128 plaintexts - considerably more than your figure of 2^8.
:>
:> : There are in total 2^8 possible ciphertexts.
:>
:> You were talking about a *particular* 8 bit cyphertext, of which there was
:> one, not 2^8
:>
:> There are *many* more than 2^8 possible cyphertexts altogether.
: Sorry, I still don't understand. How could there be more
: than 2^8 possible ciphertexts of length 8 bits?
I never said that there were more than 2^8 possible ciphertexts of
length 8 bits. I said there were more than 2^8 possible cyphertexts
*altogether*.
There are probably going to be at least as many cyphertexts as there are
possible plaintexts.
:> : What is the cardinality of the set of plaintexts that correspond to them?
:>
:> Well you don't /really/ want to know that, but...
:>
:> The size of the set of plaintexts that could correspond to
:> 2^8 cyphertexts them in some cyphersystems can be calculated by:
:>
:> How many possible plaintexts are there in your whole system?
:>
:> How many can be represented by your key? Multiply that by 2^8
:> (for the number of different cyphertexts you asked me to consider).
:>
:> Take the smaller of these two figures, and you have my reply.
: What if my key is 8 bits? I am confused.
If your key is 8 bits each possible 8 bit cyphertext could map to one of
256 plaintexts. The maximum total number of plaintexts would thus be
256x256 = 65536.
To see how a particular 8 bit cyphertext could map to more than 256
different plaintexts, just get an 8 bit cyphertext, decrypt it with
BICOM under a number of keys.
You will see *many* different plaintexts come out - not just 256.
--
__________
|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: Thu, 7 Jun 2001 13:14:14 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Traffic analysis information is indeed often present -
:> but we are talking about once a message exists, does
:> the attacker gain anything by looking at the cyphertext.
:>
:> That's what the definition of "perfect secrecy" talks about.
:>
:> Perfect secrecy applies to encryption devices. Time of
:> message transmission etc is considered to be outside its scope.
:>
:> A conventional OTP, [...] does not
:> have Shannon's perfect secrecy property.
: I am not of the opinion that size is 'inherently' different
: from time etc. in the present context.
Well, you should be. Length is a property that can be used to
distingush between elements of the set of possible plaintexts -
while time cannot be so used.
With an OTP, information about the plaintext length is learned by
an an attacker on observation of the cyphertext - while he remains
ignorant about the transmission time - as ignorant as he was before
if he knew the message had been transmitted before he observed the
cyphertext.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 7 Jun 2001 13:13:37 GMT
[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>Tim Tyler <[EMAIL PROTECTED]> writes:
>>
>> ``The bijective arithmetic encoder produces an intermediate
>> representation
>> called a finitely odd stream -- it is an infinitely long sequence of
>> bits, but with the last 1 bit at a position finitely far from the
>> beginning, i.e., it is a finite sequence of 0s and 1s, followed by
>> an infinite sequence of 0s. [...]
>
>Complete red herring; in the material you posted, that ``infinite
>sequence of 0s'' is not used for anything.
OBviously your never looked or tested the
code. The infinite zeros are a conceptual
thing. I doubt from your poor comments that
you understand bijective arithmetic compression
either.
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: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 13:19:18 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:>: Or if you just pad the bloody thing to a multiple of say 64 bytes. [...]
:>
:> Still not enough for perfect secrecy :-(
: Right--no matter what ``a multiple'' means.
That's correct - so long as no restraints are placed on the set of
possible plaintexts.
: It could mean 64 million bytes, or 64 quintillion terabytes, but that's
: ``still not enough for perfect secrecy.''
Not if there are no restraints on the possible plaintexts, no.
: If the ciphertext has finite length, then some possible plaintexts will
: be longer.
: That's why all messages must be infinite in length in order to enjoy
: ``perfect secrecy''.
I advised you that you were mistaken about this the last time you
mentioned it.
Your premise is wrong. Not all plaintexts are always possible.
If there's a bound of the number of the possible plaintexts,
perfect secrecy may well be perfectly attainable.
--
__________
|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: Thu, 7 Jun 2001 13:30:09 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:> ``The bijective arithmetic encoder produces an intermediate representation
:> called a finitely odd stream -- it is an infinitely long sequence of
:> bits, but with the last 1 bit at a position finitely far from the
:> beginning, i.e., it is a finite sequence of 0s and 1s, followed by an
:> infinite sequence of 0s. [...]
: Complete red herring; in the material you posted, that ``infinite
: sequence of 0s'' is not used for anything.
This is Matt's explanation of how his own program operates.
Who are you to call it a "red herring"? The day before yesterday you
didn't even know what BICOM was. I see you have become quite an expert
in the interim. Have you got as far as downloading it yet?
:> ``...Because the finitely odd stream is infinitely long, and all
:> bits are significant to the output...''
: Actually, everything up to (but not including) the last 1 bit is
: all you need--the rest can be reconstructed from the definition of
: a ``finitely odd stream''.
So, what was it about "all bits are significant to the output" that you
missed?
--
__________
|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
******************************
