Cryptography-Digest Digest #539, Volume #14 Wed, 6 Jun 01 19:13:01 EDT
Contents:
Re: Def'n of bijection (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: RSA's new Factoring Challenges: $200,000 prize. (my be repeat) ("Joseph Ashwood")
Re: AES question ("Joseph Ashwood")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: AES question ("Joseph Ashwood")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
shifts are slow? (Bob Jenkins)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
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)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 21:36:02 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:>[EMAIL PROTECTED] wrote:
:>: Tim Tyler <[EMAIL PROTECTED]> writes:
:>:> ...there are *excellent* reasons for thinking that potential decrypts
:>:> will be richer in plausble messages than they would be if compression
:>:> had not been employed...
:>
:>: That statement is vacuously true.
:>
:> Well, I'm glad to hear that you agree that it's true - but sorry to hear
:> that you think it is vacuous.
: Um, it's a mathematical term, Tim. A statement is vacuously true when it
: cannot possibly be false. In other words, the statement contains no
: information.
I guess you think Fermat's Last Theorem is vacuous, then. It's negation
is known to be an impossiblity, after all.
:>: Any non-negative number is >= 0. But the probability of false positives
:>: is still probably ~0...so your ``maybe'' isn't actually interesting.
:>
:> What are you talking about? Is this ">= 0" some sort of analogy?
:> I didn't say "maybe" above. What are you talking about?
: Sigh. If no compression is performed, then the likelihood of false
: positive decryptions is for most practical purposes zero.
What?!?! How on earth you you figure that out?!?!
: However, you haven't actually exhibited any interested circumstances
: where the likelihood of false positives *is provably* larger than
: zero.
Um, plaintext: 129 bits. Key 128 bits. What on earth can you possibly
be talking about?
:> ...the messages are what we're interested in. If *they* get smaller,
:> that's all that's needed. It doesn't matter what else gets smaller
:> as well.
: To prove that false decrypts are more likely when BICOM is used, you
: must prove that preimages of smallish files are more likely to be real
: (or real-looking) messages. Since lots of non-messages also get smaller,
: there is no reason to suppose that *plausible* preimages are strictly more
: likely with BICOM than without it.
*Everything* that's made smaller is more likely to turn up in possible
decrypts. Messages, junk, everything. That some junk is made smaller
doesn't affect the fact that the messages shrink, and are thus going to
have a greater density at the small file end of the spectrum than they
did before.
Think of files as in bins, with the bins being labelled with file
lengths (only files of that length may go into that bin).
Compression takes plausible messages and moves them (and perhaps lots of
other stuff) into smaller-numbered bins, while moing other files the other
way.
Now the question is, do you wind up with more messages in bins
numbered < n than there were before this operation was performed.
That answer is of *course* you do. It's blinking obvious that you do!
Are you now going to quibble that I haven't proved that a non-zero number
of files have actually crossed a particular n/n+1 bin boundary? ;-)
: The most one can say is that they're certainly no LESS likely [...]
That's not "the most one can say". I've repeatedly said a lot more -
and I'm correct in doing so.
--
__________
|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 21:38:41 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Nobody 'pads' anything on using OTP, as far as I understand
: the literature. The OTP sequence is used just like, say,
: a Scotch tape. If the next message is n bits, you cut
: out n bits from that, no more no less, do an xor and
: send the stuff. If the following message is m bits,
: do the similar thing. Or am I missing something?
Padding improves the secrecy by depriving the attacker of length
information, increasing the range of possible messages a given
cyphertext might represent by increasing the size of the key.
--
__________ http://rockz.co.uk/ http://alife.co.uk/ http://hex.org.uk/
|im |yler http://atoms.org.uk/ http://mandala.co.uk/ [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 6 Jun 2001 20:56:14 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in
<[EMAIL PROTECTED]>:
>
>There I suppose you have given a wrong interpretation.
>What 'the number of possible keys is equal to the number
>of possible messages' means is in my opinion the following:
>Given a plaintext of n bits and a segment of n bits taken
>from a perfect source (a part of a long OTP sequence at
>hand), one does an xor to get the ciphertext of n bits.
>Now since the source is perfect, the segment of n bits
>can be any of the 2^n possible ones, this is 'the number
>of possible keys'. The number of possible messages
>for a size of n bits is also 2^n. Hence these are equal.
>Thus the opponent gains no information. But there is no
>constraint at all to the effect that all 'successive'
>messages are to be of the 'same' length (having the same n).
>If the next message has m (m!=n) bits, the 'same' argument
>of security applies.
>
>M. K. Shen
>
Look at my simple example. Say you always anwser YES or NO
but you wnat to encrypt. And you use your wrong defination
of "prefect security" if your send "SD" I know you sent a NO
if you send "XER" I know you sent YES. So you had ZERO security
using your one time pad. Can't you see this simple example??
If you uses 4 bytes for all messages and sent "XENA"
I would have zero info about your YES or NO reply. In
this case you have "perfect security".
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: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RSA's new Factoring Challenges: $200,000 prize. (my be repeat)
Date: Wed, 6 Jun 2001 14:37:25 -0700
Crossposted-To: sci.math
"Michael Brown" <[EMAIL PROTECTED]> wrote in message
news:BHwT6.583$[EMAIL PROTECTED]...
> It's not really a mathematical method,
Can it be run on a computer? Yes? Then it's math.
> so I can't describe it in mathematical
> terms.
If you can't then you simply don't have enough understanding of math to
express it yet (see above). What you might try is writing explicit
directions on how it is done in general, from there formalize then into
statements of DO x, DO y, if W>Z ...... It won't be in a perfect form but it
should be close enough that it can be understood, the firmer and less open
to interpretation each statement is the better.
> However, if you could elaborate a bit more on "gibberish", I will try to
> be more exact. And also, what is the correct definition of an algorithm?
Would
> method be a better word to use?
An algorithm is a finite number of iterated steps to reach a goal. The
example of
insert key in ignition
turn key clockwise until it stops
while(engine is not running)
if more than 5 seconds have passed
turn key counter-clockwise until the key stops
wait 30 seconds
reset timer
turn key clockwise until the key stops
end if
end while
depending on make/model/year of car either release the key or turn key back
to on/run
is an example of an algorithm to start a car. It has a finite number of
steps and will start the car (if the car can be reasonably started by the
algorithm). It fails some error checking which isn't really necessary to
express the algorithm. A method is something that simply hasn't been
expressed in algorithm form yet, or may be too generic to be presented as an
algorithm (e.g. encrypting something can be called a method, to make it an
algorithm would take defining which encryption algorithm to use). Gibberish
is something that isn't defined well enough to be considered either a method
or an algorithm.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: AES question
Date: Wed, 6 Jun 2001 14:41:17 -0700
Sorry XML ENC is the abbreviated name of the XML Encryption working group
(http://www.w3.org/Encryption/2001/). The reasoning behind the use of an
algorithm other than AES for the mobile communication actually had some
interesting twists and turns, it all boiled down to a lot of petty concerns,
and they (right or wrong) they believed that the selected algorithm was a
better fit in terms of speed, hardware size, software size, and lastly
security.
Joe
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Joseph Ashwood wrote:
> >
> > Currently I am aware of the XML ENC standard (pending) supporting AES,
but
> > it doesn't as specified support much else (I was out voted). PGP uses
> > Rijndael/AES and also Twofish in the latest version. SSL and TLS both
have
> > pending additions to the cipher suite to support AES, and I know of at
least
> > one installation that has Twofish as well. There was a rumor a while
back
> > that the next version of the SecurID token (not the card) might use RC6
> > instead of the current hash. They are still all new technology so they
> > haven't been brought heavily into play yet (we did too good of a job
pushing
> > 3DES).
>
> What is 'ENC' please? BTW, isn't it that in a mobile
> communication standard an algorithm originated in
> Japan would be used instead of AES? Does anyone know
> the reason why?
>
> M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Wed, 06 Jun 2001 23:49:52 +0200
Tim Tyler wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> : Nobody 'pads' anything on using OTP, as far as I understand
> : the literature. The OTP sequence is used just like, say,
> : a Scotch tape. If the next message is n bits, you cut
> : out n bits from that, no more no less, do an xor and
> : send the stuff. If the following message is m bits,
> : do the similar thing. Or am I missing something?
>
> Padding improves the secrecy by depriving the attacker of length
> information, increasing the range of possible messages a given
> cyphertext might represent by increasing the size of the key.
But if you have an OTP (a perfect one), you 'need' not
pad anything, for you already have perfect security
for the secret you want to communicate. Padding means
waste of resources in this case. You are free to do that,
of course.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 21:49:39 GMT
JPeschel <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
:> Joe I see why your having a problem. Most use the short
:>version of an OTP but for perfect security you need the
:>correct version.
[...]
:>Most definations start by assuming a given message length then stat you
:>need a key that length so they don't really cover the case of many
:>messages of varing length. Here is a typical URL that my help you get
:>the correct defination in your mind
:>
:>http://whatis.techtarget.com/definition/0,289893,sid9_gci213673,00.html
: I looked at that URL. I think you misunderstand this part:
: "Typically, a one-time pad is created by generating a string of characters or
: numbers that will be at least as long as the longest message that may be
: sent."
: This is telling you that your pad must be at least as long as the longest
: message you intend to send. That is, if the pad is shorter than your longest
: message, part of the message won't be encrypted because the key taken
: from the pad won't be long enough.
: It does not say that the key must be as long as your longest message even if
: the message is short. [...]
It doesn't really say much either way.
If David Scott wants to present a URL that described use of an OTP in
such a manner that the attacker gets no information about the plaintext
from the cyphertext, that's probably not a good URL, since it's not clear
about the point.
: I think you are confusing the pad itself with the keys taken from the pad.
That page didn't clearly distinguish between these AFAICS.
It didn't clearly specify when the procedure was stopped.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: AES question
Date: Wed, 6 Jun 2001 14:57:07 -0700
I apologize if this is a repeat the last message showed up here as cancelled
so I'm reposting.
===== Original Message =====
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Newsgroups: sci.crypt
Sent: Wednesday, June 06, 2001 2:41 PM
Subject: Re: AES question
> Sorry XML ENC is the abbreviated name of the XML Encryption working group
> (http://www.w3.org/Encryption/2001/). The reasoning behind the use of an
> algorithm other than AES for the mobile communication actually had some
> interesting twists and turns, it all boiled down to a lot of petty
concerns,
> and they (right or wrong) they believed that the selected algorithm was a
> better fit in terms of speed, hardware size, software size, and lastly
> security.
> Joe
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> >
> > Joseph Ashwood wrote:
> > >
> > > Currently I am aware of the XML ENC standard (pending) supporting AES,
> but
> > > it doesn't as specified support much else (I was out voted). PGP uses
> > > Rijndael/AES and also Twofish in the latest version. SSL and TLS both
> have
> > > pending additions to the cipher suite to support AES, and I know of at
> least
> > > one installation that has Twofish as well. There was a rumor a while
> back
> > > that the next version of the SecurID token (not the card) might use
RC6
> > > instead of the current hash. They are still all new technology so they
> > > haven't been brought heavily into play yet (we did too good of a job
> pushing
> > > 3DES).
> >
> > What is 'ENC' please? BTW, isn't it that in a mobile
> > communication standard an algorithm originated in
> > Japan would be used instead of AES? Does anyone know
> > the reason why?
> >
> > M. K. Shen
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Wed, 06 Jun 2001 23:59:56 +0200
"SCOTT19U.ZIP_GUY" wrote:
>
> Look at my simple example. Say you always anwser YES or NO
> but you wnat to encrypt. And you use your wrong defination
> of "prefect security" if your send "SD" I know you sent a NO
> if you send "XER" I know you sent YES. So you had ZERO security
> using your one time pad. Can't you see this simple example??
>
> If you uses 4 bytes for all messages and sent "XENA"
> I would have zero info about your YES or NO reply. In
> this case you have "perfect security".
Are you saying that the opponent can read the meaning
from the length? But this means the 'code' is known to the
opponent. Your are not encrypting, your are using a
special code (much like ASCII but of variable length),
you are sending 'plaintext, isn't it?
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Wed, 6 Jun 2001 21:56:59 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> : Nobody 'pads' anything on using OTP, as far as I understand
:> : the literature. The OTP sequence is used just like, say,
:> : a Scotch tape. If the next message is n bits, you cut
:> : out n bits from that, no more no less, do an xor and
:> : send the stuff. If the following message is m bits,
:> : do the similar thing. Or am I missing something?
:>
:> Padding improves the secrecy by depriving the attacker of length
:> information, increasing the range of possible messages a given
:> cyphertext might represent by increasing the size of the key.
: But if you have an OTP (a perfect one), you 'need' not
: pad anything, for you already have perfect security
: for the secret you want to communicate.
The attacker can tell how long the plaintext is just byy looking at the
cyphertext. He can eliminate vast numbers of possible plaintexts
by a cursory examination. How is this "perfect".
: Padding means waste of resources in this case.
Not at all. It increases the size of the key, which increases the
number of possible plaintexts that can be represented by a given
cyphertext.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: [EMAIL PROTECTED] (Bob Jenkins)
Subject: shifts are slow?
Date: 6 Jun 2001 15:07:54 -0700
I've been talking to people trying to optimize assembly for the P4.
They say there is a "shift penalty". What is more, they claim that
shifts are necessarily slower than addition or xor. Wire length
is starting to matter more than gate count.
I asked, do you mean that the low bits of x and y in x+y are closer
together than the low and high bits of x? They said yes. The
registers are interleaved that way. Perhaps they could do shifts
by 2 or 3, or maybe 4, in the same time as addition, but more than
that is inherently slower.
My old model of the world had +-^|&~ take 1 cycle, tab[] take 2,
if() take 5 if it guesses wrong, * take 10, and / take 20. That's
apparently no longer close to reality. What is the new reality?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 00:06:58 +0200
Tim Tyler wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> : But if you have an OTP (a perfect one), you 'need' not
> : pad anything, for you already have perfect security
> : for the secret you want to communicate.
>
> The attacker can tell how long the plaintext is just byy looking at the
> cyphertext. He can eliminate vast numbers of possible plaintexts
> by a cursory examination. How is this "perfect".
So you are refuting Shannon, aren't you??
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 6 Jun 2001 21:29:45 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <3B1E9A97.54BECE57@t-
online.de>:
>
>
>Tim Tyler wrote:
>>
>> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>> : If it is xored with a perfect random source, then each
>> : of the possible 2^n sequences could result as ciphertext.
>> : Hence the a-posteriori probabability of (the content)
>> : of the message is the same as its a-priori probability.
>>
>> In an OTP if you are given a cyphertext of length n there
>> are only 2^n possible plaintexts.
>>
>> However this is not true of cypher-systems in general -
>> in some cyphersystems a message might represent any
>> possible plaintext.
>>
>> If the plaintext is not restricted to be the same
>> length as the cyphertext then there may be far more
>> than 2^n possible plaintexts - and consequently a
>> key of greater size than 2^n would be necessary to
>> properly obscure them.
>
>Since each ciphertext has to be uniquely decipherable
>to a plaintext, it is not possible to have n bits
>of ciphertext to map to more than 2^n different
>plaintexts. On the contrary, if one uses homophones
>or the like, then the number of possible plaintexts
>would be less than that amount.
>
>> : Now this is general for 'any' n. It certainly has no
>> : implication to the effact that, after sending a message
>> : of a certain length, the next following message should
>> : have the same n.
>>
>> I certainly never meant to imply anything like that.
>
>Scott said in another post that sending some shorter
>messages would leak information.
>
Well it can leak information. I thought I gve the
example that you never anwsered. Suppose someone asks
you a question of the type where you are "known" to
anwser "yes" or "no". ( Its a made up example you
reall can't anwser yes or no to anything just go with
it for a minute). You could encrypt with a TOMMY style
OTP and send "QW" but if you did I would know its a "NO"
or you sould send a "TRU" in wish case I would know its a
"YES". SO you have zero secruity.
Or you could use a longer pad like 4 letters. And
send "WSHS" for no and "JSKS" for yes in which case
I would not know what you sent.
Or you could compress it and send 1 bit.
If you actaully want more securoty since you may on
rare occastions not give a yes or no. IN that case you
real need a very long pad. But the length of all messages
should be the same if you want "perfect security" It can
be less and still secure if you use a different size. But
it won't be "perfectly secure" unless it is as long as your
longest message.
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: Wed, 6 Jun 2001 22:04:49 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> : If it is xored with a perfect random source, then each
:> : of the possible 2^n sequences could result as ciphertext.
:> : Hence the a-posteriori probabability of (the content)
:> : of the message is the same as its a-priori probability.
:>
:> In an OTP if you are given a cyphertext of length n there
:> are only 2^n possible plaintexts.
:>
:> However this is not true of cypher-systems in general -
:> in some cyphersystems a message might represent any
:> possible plaintext.
:>
:> If the plaintext is not restricted to be the same
:> length as the cyphertext then there may be far more
:> than 2^n possible plaintexts - and consequently a
:> key of greater size than 2^n would be necessary to
:> properly obscure them.
: Since each ciphertext has to be uniquely decipherable
: to a plaintext, it is not possible to have n bits
: of ciphertext to map to more than 2^n different
: plaintexts.
Yes it is. 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.
:> : Now this is general for 'any' n. It certainly has no
:> : implication to the effact that, after sending a message
:> : of a certain length, the next following message should
:> : have the same n.
:>
:> I certainly never meant to imply anything like that.
: Scott said in another post that sending some shorter
: messages would leak information.
Yes, I believe I can see what you're both thinking about.
Scott's talong about a secure variant of his own.
I was talking about the "conventional" OTP that preserves
file length as described in the literature dating back to
Shannon - which is less secure than Scott's scheme, since
it preserves length - but lacks the upper length limit of
Scott's scheme.
--
__________
|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 22:09:44 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> To illustrate my point, here's a system that does better at concealing
:> information about the plaintext from an attacker with cyphertext and
:> full knowledge of the algorithm employed than a conventional
:> One Time Pad manages.
:>
:> Convert the plaintext from a 8-bit granular file to a 64-bit granular
:> file using one of David's bijections between these sets.
:>
:> Then encrypt with a conventional OTP.
:>
:> The result is much the same - except that many plaintexts that were
:> previously distinguishable on length grounds are now effectively
:> indistinguishable.
:>
:> Given a cyphertext representing a particular plaintext, the attacker's
:> uncertainty about the possible plaintexts increases, as the file length
:> will (typically) increase, and thus so will the length of the key.
:>
:> Would anyone still refer to a One Time Pad as offering
:> "perfect" protection of one's secrets after reading this?
: The OTP, in the literature that I am familiar with, is
: always considered in the context of being used with
: xor. Scott's 'bijection' is a new 'invention'. That may
: be a genious one. On the other hand, lacking concrete
: knowledge of proof materials, I am not in a positition
: to related the security of a system using his 'bijection'
: to the known argument of security of (the hithertofore
: known) usage of OTP (i.e. the perfectly random source)
Should I describe it? Just systematically number the set of
all 8-bit granular files, (e.g. shortest first) do the same
with the 64-bit granular ones and then form a bijection
between files with equal numbers.
: and doubt anyway that such use is terminologically
: justified to be called an OPT encryption system.
I wasn't calling it an OTP (though it does employ a random pad, which
it only uses once).
I was saying it had *better* secrecy properties than a conventional OTP -
since there would be greater uncertainty in an attacker about the
plaintext, given a encryption of some specified message.
--
__________
|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 22:16:16 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: "SCOTT19U.ZIP_GUY" wrote:
:> Look at my simple example. Say you always anwser YES or NO
:> but you wnat to encrypt. And you use your wrong defination
:> of "prefect security" if your send "SD" I know you sent a NO
:> if you send "XER" I know you sent YES. So you had ZERO security
:> using your one time pad. Can't you see this simple example??
:>
:> If you uses 4 bytes for all messages and sent "XENA"
:> I would have zero info about your YES or NO reply. In
:> this case you have "perfect security".
: Are you saying that the opponent can read the meaning
: from the length?
He can if he knows the possible messages are "Yes" or "No".
Say he just saw a message going the other way in the clear that read:
``Did you destroy the evidence? Keep it brief - answer "yes" or "no".
Also, OTP-encrypt your reply for maximum security''.
--
__________
|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
******************************
