Cryptography-Digest Digest #542, Volume #14 Wed, 6 Jun 01 20:13:00 EDT
Contents:
Re: shifts are slow? ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: RSA's new Factoring Challenges: $200,000 prize. (my be repeat) (John Myre)
Re: shifts are slow? ("Joseph Ashwood")
Re: Medical data confidentiality on network comms ("Roger Schlafly")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Joseph Ashwood")
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) (JPeschel)
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) (JPeschel)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: shifts are slow? ("Tom St Denis")
----------------------------------------------------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: shifts are slow?
Date: Wed, 06 Jun 2001 23:08:36 GMT
"Bob Jenkins" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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?
Depends on if they are done in the ALU directly or not.
In the Athlon afaik a shift and rotate can be done in 1/2 time (1 cycle
latency, 2 cycle throughput) i.e
ROL EAX,3
ADD EBX,ECX
MOV EDX,EAX
Will not stall since ROL is completed by the end.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Wed, 06 Jun 2001 23:09:11 GMT
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tim Tyler <[EMAIL PROTECTED]> writes:
> >
> > ...but why only consider the possible messages of size 2^n? This is
> > a tiny subset of the messages that could have been transmitted.
>
> Right! That's why ``perfect secrecy'' is only attainable if the ciphertext
> is longer than *any* possible plaintext. All messages must have infinite
> length.
>
> That's why in fact perfect secrecy has been proven impossible, and there
> is no such thing as a OTP.
>
> Len.
You're a loon.
Tom
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: RSA's new Factoring Challenges: $200,000 prize. (my be repeat)
Date: Wed, 06 Jun 2001 17:09:35 -0600
(Re "algorithm")
For the OP:
The really important parts of the definition are that the
steps are unambiguously defined, and can actually be done.
So steps like "pick a fratzle number" (a name I just made
up), or "use the last integer" (obviously not possible)
aren't allowed. It's partly a problem in communication,
since "unambiguous" depends on mutual understanding. But
it's also important to recognize when the instructions are
clear, and when they are more like hand-waving.
To Joe:
I'm not sure what you meant by "a finite number of steps".
The usual formal definition of "algorithm" includes the
requirement that the method always halts - is that what you
meant? The example you gave does not meet this requirement.
(Hint: what does it do if the battery is already dead?)
(BTW, I find it amusing that the "halting problem" shows that
it is not algorithmically possible to decide what programs are
algorithms...)
JM
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: shifts are slow?
Date: Wed, 6 Jun 2001 16:07:26 -0700
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
such deep pipelines addition now takes multiple clocks but commonly you can
get a througput of 1 add/clock. Basic binary operations ^|&~ still take one
clock (although it may take longer due to the pipeline). It gets worse when
you get into advanced pipelines such as those in most RISC processors, where
the pipeline itself can actually be out-of-order. In a basic EE course on
RISC processors you will cover pipelining taking say 7 stages; 1)fetch the
instruction, 2)parse the instruction, 3)fetch memory for the instruction,
4)aquire register(s) for instruction, 5)perform instruction, 6)write to
registers, 7)write to memory/release registers. With advanced processors
they will commonly examine as far ahead as 64 instruction to determine what
locations in memory to load into level 1 cache, maybe even a pipeline cache,
the instructions are arranged in a prepipeline to avoid pipeline stalls, and
may be jumped over for hundreds of clocks, some instructions may even be
omitted entirely if they are purely redundant, and that's just what is in a
simplistic model step 1. The result is that phase 2 is done before phase 1,
so the parsed instruction actually enters the pipeline, phase 3 was also
done before phase 1 so the memory doesn't have to be fetched. Phase 4 the
registers are acquired, this is also a sorted pool (often linked into the
phase 0), as everyone waits for the registers they need to be released, this
can be a delay of anywhere from 0 to a couple hundred clocks. the
instruction is performed, this is itself pipelined with different paths
going to the FPU, the Integer Unit, register games movement etc, here the
delay per instruction is generally fixed. Write to the registers, 1 clock,
no need for a pipeline, although there may need to be resolution in case
more than one instruction finishes at the same time (or even a later
instruction finishs earlier) and all write to the same register. All writes
to memory are in the same clock (since it's generally a different path) and
are done in however many clocks it takes for level 1 cache. The cache in
it's own time writes to level 2, and level 2 either to level 3 or to memory.
The short of it is, that how long an opcode takes to complete depends on
what happens for potentially several hundred clocks before it. In the case
of the IA-32 line (now commonly called the pentium or Athlon line) this is
much simpler. It is in fact so simple that the execution time is only
affected by the surrounding at most dozen instructions. If you want to have
the most optimal timing on your shifts you should restrict them to no more
than 2/3 the depth of the integer pipeline, since you are targetting a P4
you should be able to get this time by checking the CPU full execution speed
time of an add by the following (not assembly, but should be close enough
that someone that speaks x86 can figure it out)
move timer, reg1
move timer, reg2
add reg1, reg2, reg2
move timer, reg3
subtract reg2, reg1, reg1
subtract reg3, reg1, reg1
reg1 contains the depth of the integer pipeline, give or take 2
multiply by 2/3 and that should give you the maximum shift you should be
able to do at full speed. There are caveats, if Intel created a short out
for addition, or shift, all bets are off, same applies if they created a
pipelined loop. Both of these are unlikely since they would take up more
silicon and the speed improvement would be almost negative (silicon
translates rather cleanly to speed). And this doesn't even cover the state
of the art, there are multi-register setups, multi-core, shadow registers,
deeper pipelines, broader pipelines, staggered pipelines, there are simply
an enormous number of possibilities that they can use to increase the
throughput, and some of them can change things enormously. Your basic option
is to just experiment with your code, and don't bother with the OS Idle
loop.
Joe
"Bob Jenkins" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Wed, 06 Jun 2001 22:17:41 GMT
"Barry Margolin" <[EMAIL PROTECTED]> wrote in message
news:l6sT6.22$v47.924@burlma1-snr2...
> In article <[EMAIL PROTECTED]>,
> wtshaw <[EMAIL PROTECTED]> wrote:
> >If my doctor violated his position, he would have to answer for it to me.
> >I try to deal with trustworthy people to start with, and most
> >professionals are.
> Of course. But in emergencies you generally don't have the freedom to
> choose who to deal with, or even the knowledge of who is trustworthy (you
> don't have the time for a background check when you're in the ER), yet
> emergency personnel may need access to your personal information.
> If we could trust all professionals to act ethically, we wouldn't need
> privacy laws in the first place.
Good point, but I think we'd still need privacy laws. People seem to
have radically different ideas about what their privacy rights are.
Eg, some people think it is an invasion of their privacy to go on a
junk mail list, and others don't.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 01:22:10 +0200
JPeschel wrote:
>
> Mok-Kong Shen [EMAIL PROTECTED] writes, in part:
>
> >The OTP, in the literature that I am familiar with, is
> >always considered in the context of being used with
> >xor.
>
> XOR is one operation that can be used with an OTP,
> but it is not the only one.
Right. A trivial variant would be to invert (applying
'not') after xor. But that doesn't add any security.
I don't know any literature mention anything other than
xor in connection with OTP.
M. K. Shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Wed, 6 Jun 2001 16:20:39 -0700
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Right! That's why ``perfect secrecy'' is only attainable if the ciphertext
> is longer than *any* possible plaintext. All messages must have infinite
> length.
You seem to be misunderstanding the meaning os "possible" in this case. It
is know that any response to your post will be of some maximum length, for
the sake of simplicity let's set that length at k. k is finite, it must be,
in the worst case a human being has less than 100 years to complete typing
it, so it must be finite. Since the OTP must be at least as long as that it
becomes a simple matter to create from there that the OTP length needed is
in fact k. We already determined that k is finite, so the required length of
the OTP is finite. Would you care to revise your position?
> That's why in fact perfect secrecy has been proven impossible, and there
> is no such thing as a OTP.
Perfect secrecy has been proven possible (hence the existance of the OTP),
and regardless of any misguided statements on your part it will continue to
remain possible. I suggest you revise your position.
Joe
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 6 Jun 2001 23:12:29 GMT
[EMAIL PROTECTED] (JPeschel) wrote in
<[EMAIL PROTECTED]>:
>[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. Since by defination no information can be
>>leaked about plain text. 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. ( I take it you want to pad short messages
>with random data.)
>
>Note importantly that "Typically, a pad may be issued as a
>collection of keys, one for each day in a month, for example, with one
>key expiring at the end of each day or as soon as it has been used
>once."
>
>I think you are confusing the pad itself with the keys taken from the
>pad.
>
Joe if your serious about encryption. You should read
Shannon's article "Communication Theory of Secrecy Systems"
it was in the Bell systems technical Journal. Actully
even little TOMMY should read it even though he will not
understand it. You also have to realize a lot of stuff he
wrote in the 40's is still secret.
In it he says "perfect secrecy is defined by requiring of
a system after a cyptogram is intercepted by the enemy the
a posteriori probabilites of this cryptogram representing
various messages be identaically the same as the a priori
probabilites of the same message before the interception."
He a few pages later talks about breaking up a cipher
into various residue classes. In it there are several
sets such that a set of keys in that class map every message
to every cipher element in that set and visa versa.
Then talks about changes in probabilites if you know
a message is in that set. Compared to rest of residue
clases.
A few pages later is the diagram describing a "perfect secrecy"
system it has only one residue class.
In summary if you limit your OTP to the msg length you are chopping
the set up into several resisue classes solely based on the
length of the message. Such a system can not be perfectly secure.
If you read it its old exchange the word Transducer to "bijective
compressor" and read how to make a system practical secure.
You need a high work factor. You need to get rid of redunancy
and without high error propagation you can't easily have a system
that even ideal. But read it yourself.
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 23:02:38 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
: I looked up what Bruce Schneier has to say about perfect secrecy in
: A.C.
: He says this:
: ``There is such a thing as a cryptosystem that achives perfect secrecy:
: a cryptosystem in which the cyphertext tields no possible information
: about the plaintext (except possibly its length).''
Unsatisfied by that nonsense, I tried the Handbook of Applied Cryptography:
This makes no bones about the matter:
``(i) Unconditional security
The most stringent measure is an information-theoretic measure – whether
or not a system has unconditional security. An adversary is assumed to
have unlimited computational resources, and the question is whether or
not there is enough information available to defeat the
system. Unconditional security for encryption systems is called
perfect secrecy. For perfect secrecy, the uncertainty in the plaintext,
after observing the ciphertext, must be equal to the a priori
uncertainty about the plaintext – observation of the ciphertext provides
no information whatsoever to an adversary.''
There's no ambiguity there. This *clearly* is the same definition of
perfect secrecy that myself and David Scott are using.
However, we then have:
``A necessary condition for a symmetric-key encryption scheme to be
unconditionally secure is that the key be at least as long as the
message. The one-time pad (x1.5.4) is an example of an unconditionally
secure encryption algorithm.''
I sure /hope/ that isn't the *conventional* OTP - which encrypts
variable-length messages into cyphertexts of the same length.
Alas the reference (to x1.5.4) seems to indicate that a Vernam cypher is
indeed what is indicated - so superficially it appears that this is one
textbook whose entry on the subject contains internal contradictions
and needs some qualifications adding :-|
--
__________
|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 23:08:55 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
[snip example]
: Oh, in some cases whether one sends a messages at all
: could leak information, isn't it?
Yes.
: If a message goes out e.g. from my home, that means some person is
: there. Are we considering such stuffs?
That's not what perfect secrecy is about. It's defined as being about the
difference in an attacker's knowledge of the plaintext before and after
observing the cyphertext. It's not about the possibility that no message
was sent.
: If [the attacker] already knows that a message
: of two bytes means 'NO', then any system of encryption is
: as bad as any other, in fact useless.
No! What about Scott's example? What about BICOM?
This is false - encryption *can* conceal how many letters there
are in the plaintext, the same way it can conceal everything else.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 06 Jun 2001 23:29:37 GMT
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Tim Tyler [EMAIL PROTECTED] writes:
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>: 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''.
>--
It seems unlikely, to me, anyway, that first message would be sent
in the clear. But let's suppose it happens, and the correspondent
follows directions. As the attacker you see three encrypted characters
sent in reply. You immediately assume the answer is yes, however,
the correspondent wrote:
No.
(He included the period, which was also encrypted, -- three characters.)
Suppose this punctuation-conscious correspondent replied:
Yes.
(Also including the period, but four characters.)
Now, you might think that he'd written yes with a period. He might have
written yeah without a period. But maybe he didn't follow the directions
exactly and could have could have written:
Nope
(Without the period.)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 6 Jun 2001 23:19:06 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <3B1EA7DC.7F88727B@t-
online.de>:
>
>
>"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
>
The opponent is always assume to know the encryption
program and method. Only the key used on message intercepted
is secret.
On another Post I posted dierectly from Shannon if you
read or read the source you will see Tim and I and agreeing
with Shannon.
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 23:27:55 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <3B1EB22A.71F7B2@t-
online.de>:
>
>Oh, in some cases whether one sends a messages at all
>could leak information, isn't it? If a message goes
>out e.g. from my home, that means some person is there.
>Are we considering such stuffs? I already mentioned
I just posted Shannon defination. It defines it based
on a recieved message. SO that info is not something new.
And in a footnote he notes for purest a message that
means nothing could also be considered in the set of messages
if one wants.
>in a previous post that, unless there is something
>that links the length to the content of the message,
>the argument holds. Note that Shannon's perfect
>security implies that the efficiency of the transforming
>a 'given' bit sequence of n bits is so good that from the
>ciphertext the opponent cannot get more information than
>he 'already' knows otherwise (e.g. from the length or
>from the time of sending, or from the particular station
>that sends it, etc.). If he already knows that a message
>of two bytes means 'NO', then any system of encryption is
>as bad as any other, in fact useless. But is that any
>argument against OTP as such? If a 'bijective' system
>transforms 'NO' to 4 bits and 'YES' to 5 bits, doesn't
>the same thing happen?
>
Please read up on SHannon. And yes your right if you
only had 2 messages in your set and used your type of
OTP if not went to 4 bits and yes went to 5 bits and
you sent only 4 or 5 bits. Of course it would be insecure.
I never stated bijective compression would force perfect
security your putting words into my mouth.
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] (JPeschel)
Date: 06 Jun 2001 23:53:50 GMT
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
"Joseph Ashwood" [EMAIL PROTECTED] writes, in part:
<[EMAIL PROTECTED]> wrote in
messagenews:[EMAIL PROTECTED]...
>> That's why in fact perfect secrecy has been proven impossible, and there
>> is no such thing as a OTP.
>
>Perfect secrecy has been proven possible (hence the existance of the OTP),
>and regardless of any misguided statements on your part it will continue to
>remain possible. I suggest you revise your position.
Joe, if you look at other posts by Len in this thread, I think you'll
agree he's kidding.
I could try to make the case that since I have some ciphertext, I know
some information about the plaintext: That it actually exists! But I'd be
kidding
around. :-)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 6 Jun 2001 23:51:08 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <3B1EBB22.4F49F65E@t-
online.de>:
>
>
>JPeschel wrote:
>>
>> Mok-Kong Shen [EMAIL PROTECTED] writes, in part:
>>
>> >The OTP, in the literature that I am familiar with, is
>> >always considered in the context of being used with
>> >xor.
>>
>> XOR is one operation that can be used with an OTP,
>> but it is not the only one.
>
>Right. A trivial variant would be to invert (applying
>'not') after xor. But that doesn't add any security.
>I don't know any literature mention anything other than
>xor in connection with OTP.
>
>M. K. Shen
>
I think part of the problem is you know in theroy how to
use a short OTP. But you lack the knowledge of how to
use an OTP if the message ends in N bytes but your longest
message is M bytes. You would like to use the OTP to make
a system that has "perfect secrecy" for the messages invovled.
Easy if your using binary files. Convert to FOF files. tack
on zero bytes till all messages the same length. Then apply
your normal OTP to the resulting message.
To decrypt use the OTP chop off trailing zero bytes. Convert
from the FOF file back to normal file. Your done. Was that so
hard.
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: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: shifts are slow?
Date: Thu, 07 Jun 2001 00:03:20 GMT
"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
------------------------------
** 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
******************************
