Cryptography-Digest Digest #275, Volume #11 Wed, 8 Mar 00 00:13:01 EST
Contents:
Re: EOF in cipher??? ("David Thompson")
Re: Protocol question -- detecting patching of software ("Mrs. Brisby")
Re: Passphrase Quality ? ("Michael A. Greenly")
Re: Passphrase Quality ? ("Michael A. Greenly")
Re: differential cryptanalysis (netpal2u)
Re: Passphrase Quality ? (Marlin Yeko)
Re: ascii to binary ("Douglas A. Gwyn")
Re: ascii to binary ("Douglas A. Gwyn")
Re: Passphrase Quality ? (jungle)
Re: Universal Language: was The Voynich manuscript ("Douglas A. Gwyn")
Re: very tiny algorithm - any better than XOR? (Paul Rubin)
Re: Passphrase Quality ? (jungle)
Re: Best language for encryption?? ("Douglas A. Gwyn")
Re: differential cryptanalysis ("Douglas A. Gwyn")
Re: are self-shredding files possible? (jungle)
Re: An RC5-like cipher (Paul Rubin)
Re: are self-shredding files possible? (jungle)
Re: very tiny algorithm - any better than XOR? (Samuel Paik)
----------------------------------------------------------------------------
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Wed, 08 Mar 2000 02:17:31 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> responded to my:
> > I think you're mistaken. C90 7.9.2, unchanged in C99 7.19.2p3,
> > allows the implementation to pad stored binary streams
> > (normally disk files) with null characters = zero-value bytes;
> > AFAIK this is to allow file granularity > 1 byte.
>
> Yes, binary streams can have padding at the end on some systems,
> but Shen asked if the C standard *required* binary-stream files
> to have size that is a multiple of the system's wordsize instead
> of an arbitrary number of bytes, and the answer is no. ...
Aha! We read the question differently. You saw "is it required
that granularity be > 1, and files padded, or is = 1 allowed".
I saw "can the implementation select granularity > 1, and thus
require padding, or must = 1 be provided".
We agree: the C standard permits either, and a maximally
portable program deals with it, but granularity 1 is very common.
--
- David.Thompson 1 now at worldnet.att.net
------------------------------
From: "Mrs. Brisby" <[EMAIL PROTECTED]>
Reply-To: "Mrs. Brisby" <[EMAIL PROTECTED]>
Subject: Re: Protocol question -- detecting patching of software
Date: Tue, 07 Mar 2000 21:32:50 -0500 (EST)
On 08 Mar 2000 01:57:24 GMT, Edward A. Falk wrote:
>Hi all; here's a puzzler that's been nagging me for a few days:
>
>You have a multi-player game, where the players run a copy of
>the game on their own computer, and play over the net, connected
>to a server.
>
>It's possible to cheat by patching your copy of the game.
>
>Is it possible to design a protocol by which the server could
>challenge the user's software to ensure that it hasn't been
>modified?
>
[snip]
Your best bet is to develop the protocol so that you can't cheat -- e.g. do
not trust your clients. Of course, this sounds more complicated than it
actually turns out to be, so here we go:
A way that I often look at things is:
I cannot trust what this (anonymous) device is giving me.
If he cannot trust what I am sending him, he is more than welcome to
"hang up".
If the client tries to cheat me, I will not tell him that, I will
simply hang up.
If you're designing a game (as per your example), you'll probably want the
server to tell the client what he (the client) sees and hears (the map that's
visable, the sounds that should be triggered, how much health the player has,
etc) while the client does nothing more than tell the server what he does
(shoot, turn left, etc).
The client should not tell the server what his life meter reads, or what his
XY(Z) is. The server should be providing this information.
Of course, what usually ends up being easier (in terms of latency) is for the
client to "guess" and the server to send corrections. This behavior is often
seen when we get 'jaggies' or 'lag' in many multiplayer games.
The alternative is of course slowdown, or rather seen as annoying pauses
during syncs.
------------------------------
From: "Michael A. Greenly" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Tue, 7 Mar 2000 21:02:21 -0800
It seems to me there is no solution? If you can be tortured into giving up
the password you can also be tortured into giving up the password generation
mechanism....
"Stephen P." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> tell them to use some poem as the passphrase !? no, sorry, i'm left
> muddled. but i do have a question about all this. how can i go about
> generating a password that i can't remember but can easily produce if at
my
> machine? and .. please .. don't tell me to go ask alice.
>
> my passphrase is a single stream of a mix of numeric and alphabetic
> characters. it might be tough to guess but i'm a wimp and easily say
> "Uncle" [not that anybody's interested, but..].
>
> steve
>
>
> jungle wrote:
> >
> > IMO you did get all this wrong ...
> >
> > my way is to never remember pass text ...
> >
> > you will not spit a dummy only when you don't know the dummy,
> > is it clear now for you ?
> >
> > Guy Macon wrote:
> > >
> > > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(jungle)
> > > wrote:
> > > >there is one huge difference, this one I can tell you ...
> > > >> > >you know your pass text all the time [ you did your pass text
> > > >memorized very well ], therefore several methods that are child play
> > > >simple to use & execute exist to get this pass text from you
> > > >
> > > >to get your "simple two sentence mnemonic", irrespectively of your
> > > >resistance any time the AGENCY WOULD LIKE TO DO IT ... when agency
> > > >will like to get your "simple two sentence mnemonic", you will spit
it
> > > >out on every request, like a baby spit a dummy
> > > >
> > >
> > > Let me get this straight. You are advocating using a passphrase that
> > > is hard to remember so as to avoid someone torturing it out of you?
> > > Let me guess... you keep it on a post-it note on your monitor, right?
> > >
> > > I have this mental picture of them increasing the torture and you
> > > REALLY, REALLY, *REALLY* wishing that you could remember your
> > > passphrase...
>
> -----BEGIN PGP SIGNATURE-----
> Version: 6.5.1ckt http://irfaiad.virtualave.net/
>
> iQA/AwUBOMOv8FMZCmMtHP6pEQLxxwCggOIbcid+2xZdo9okLL1GnE3WhGwAn2ut
> HMupoYsG4w3P2Z95q6NxOdLQ
> =mrdo
> -----END PGP SIGNATURE-----
------------------------------
From: "Michael A. Greenly" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Tue, 7 Mar 2000 21:19:59 -0800
Combine this table with a remembered password and you indeed have very
strong protection. Since the table can be destroyed you can not be forced
into revealing the key, and since the password is remembered the table is
useless without it.
--
[EMAIL PROTECTED]
http://www.pinenet.com/~mgreenly
------------------------------
From: netpal2u <[EMAIL PROTECTED]>
Subject: Re: differential cryptanalysis
Date: Wed, 08 Mar 2000 03:09:41 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > The most appropriate symbol for xor would be a "V" with a cross
> > stroke. That's how the boolean operator is denoted in formal logic.
>
> Except when some other symbol is used.
> (Most of us use "+" and establish that the context is GF(2).)
>
Hello Douglas,
I know nothing about this "crypto" stuff, just wanted to say hello.
Why are you using your real name?
Ah yes could you tell me why "they" where putting so much craps about
aliens and ufo stuff on "that" "your?" web site? I real wonder?
Another hoax area51 style?
"NSA's activities are conducted in accordance with the highest
constitutional, legal and ethical standards and in compliance with
statutes and regulations designed to protect the privacy rights of U.S.
persons"
a reminder because I am not using for this post an anonymous news
posting.
My regards to Dr. Sadler.
take care...
--
Charlie Chan
"Chips off the Old Chopstick..."
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Marlin Yeko)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Wed, 08 Mar 2000 03:21:19 GMT
"Michael A. Greenly" <[EMAIL PROTECTED]> wrote:
>It seems to me there is no solution? If you can be tortured into giving up
>the password you can also be tortured into giving up the password generation
>mechanism....
Not if it doesn't exist any more -> http://www.5x5poker.com/grid/
--
"Marlin Yeko" is actually 0487 516392 <[EMAIL PROTECTED]>.
012345 6789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: ascii to binary
Date: Wed, 08 Mar 2000 03:54:15 GMT
Vernon Schryver wrote:
> >My old 1620 Books describes the tape device and has pictures.
I don't recall paper tape as a 1620 option, although *mag*tape was.
> Far more than one model from one vendor used paper tape. Paper tape
> was a very common low speed medium from at least the 1960's when I
> started in the business until the late 1970's. The closest to a
> universal paper format were the 5 and 8 level standards that Teletype
> (i.e. Ma Bell) defined for TTY's. Minicomputer vendors of the 1970's
> tended to define their own formats. When dealing with binary, the
> people defining paper tape formats were not happy to make the tape
> 14% longer by spending 1 bit in every frame on parity.
For text, essentially all minicomputers used ASCII code on 8-track
paper tape, with bit order as defined by Teletype. Delimiters
between text lines did vary somewhat, a very nice one being
CR XOFF RUBOUT(=DEL+parity) LF, which CCC (Honeywell) used on the
x16 series, allowing assembly code to be input from the half-duplex
(cheaper than full) ASR-33 (or -35) TTY tape reader, the XOFF
stopping the tape (reliably with one extra character read, if it was
RUBOUT), echo-printing the assembly source on the right side of the
paper, returning the print head so that the assembler could print
the corresponding generated binary on the left side; and if there
was object code to generate, the punch on the ASR could be started
up and the object format consisted entirely of non-printing, non-
printhead/carriage moving codes so that the listing wasn't messed
up. For the next line of input, the assembler sent an XON to
start the tape reader again (and the LF advanced the paper to the
next line without returning the carriage). Very clever kludgery.
By the way, there is a good introduction to these things and more:
"Code" by Petzold, a recent Microsoft Press hardback. It's not so
much about cryptology as it is about coding in computing in general.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: ascii to binary
Date: Wed, 08 Mar 2000 04:03:14 GMT
Paul Koning wrote:
> ISO 10589 and Unicode, which are closely related, use wider characters
> to allow coding of essentially any character you might need without
> having to switch back and forth among sets (which was never standardized
> and would have been a processing nightmare even if standardized, which
> is one reason it wasn't).
I think you meant 10646. Unicode has been normalized to be exactly
the page of 31-bit 10646 with the 15 high bits all zero.
Unfortunately, 16 bits (Unicode) are not really enough..
There are associated standards for multi-octet encodings of 10646
codes, e.g. UTF-8 which has the attractive feature that 7-bit ASCII
strings are encoded as themselves, making it compatible with existing
storage (filename) formats, etc. -- a great way to migrate to full
10646 support. The C standard distinguishes between external
multi-byte encodings such as UTF-8 (or uglier ones with shift states)
and internal character encoding as type wchar_t (which might use
31-bit 10646 coding). This wasn't done in the way I would have
preferred, but it has been adopted very widely.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Wed, 08 Mar 2000 04:07:28 GMT
Marlin Yeko wrote:
>
> "Michael A. Greenly" <[EMAIL PROTECTED]> wrote:
> >It seems to me there is no solution?
wrong assumption
they are many [ several at least ] solutions to this problem !!!
> If you can be tortured into giving up
> >the password you can also be tortured into giving up the password generation
> >mechanism....
wrong again ...
> Not if it doesn't exist any more -> http://www.5x5poker.com/grid/
yes, very good answer,
at least some people can think in this forum !!!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Universal Language: was The Voynich manuscript
Date: Wed, 08 Mar 2000 04:08:17 GMT
Mok-Kong Shen wrote:
> I agree with you. However, I think that it is possible to design,
> first of all, a grammar that is simple, i.e. rational and without
> exception rules, redundancies etc. etc. ... The vocabulary should
> also be well designed, ...
Yes, artificial languages have tried to do all that. It isn't as
simple as you might think. For one thing, if the language is meant
to remain a "living" language, it needs to accommodate expansion as
new entities and concepts develop. If you try to plan in advance
for the categories for such things, you are bound to fail.
Besides Esperanto, another artificial language that has been of
some mild interest in the crypto community is Lincos.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 8 Mar 2000 04:11:55 GMT
Carl Byington <[EMAIL PROTECTED]> wrote:
>Quite correct. However, the content we are protecting is very cheap,
>on the order of 1 or 2 dollars. The hardware is not particularly tamper
>resistent, so anyone with access to a lab could clearly open the device
>and attach probes. We are attempting to prevent the attacker from
>decoding the content and then producing some software that will allow
>loading that content into multiple other devices without also opening
>those other devices.
OK, I understand now.
>Each device contains a serial number (key) that it uses to decrypt
>stuff, and also a 3des encrypted version of that device key. It
>provides the encrypted version of its key on request to some client
>software running on Win9x which simply passes that encrypted key to a
>web server. There is a global key which is used to encrypt all the
>device keys, and clearly if that is broken all is lost... The global
>key is known to the web server, so security there is critical. The
>global key is also known to the internal machines that produce the
>key lists.
You might consider putting the global key into one or more sealed
hardware modules that can do encryption/decryption operations but
won't reveal the key, and interfacing the module(s) to your web server
and internal machines. That makes it a lot harder to spill keys
either accidentally or otherwise. Managing secret keys in disk files
in a production system with multiple servers, frequent software
updates, automatic backup procedures which which copy the key files
onto backup tapes accessible to random people working at your hosting
facility, etc. is very challenging. I've become a convert to the
sealed hardware approach.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Wed, 08 Mar 2000 04:15:10 GMT
"Michael A. Greenly" wrote:
>
> It seems to me there is no solution?
are many solutions ...
> If you can be tortured into giving up
> the password you can also be tortured into giving up the password generation
> mechanism....
many solution exist to this problem ...
> "Stephen P." <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > tell them to use some poem as the passphrase !? no, sorry, i'm left
> > muddled. but i do have a question about all this. how can i go about
> > generating a password that i can't remember but can easily produce if at
> > my machine?
I will not tell you any of these methods ... I can't ...
............................
> > jungle wrote:
> > > IMO you did get all this wrong ...
> > > my way is to never remember pass text ...
> > > you will not spit a dummy only when you don't know the dummy,
> > > is it clear now for you ?
...............................
> > > > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > > > (jungle) wrote:
> > > > >there is one huge difference, this one I can tell you ...
> > > > >> > >you know your pass text all the time [ you did your pass text
> > > > >memorized very well ], therefore several methods that are child play
> > > > >simple to use & execute exist to get this pass text from you
> > > > >
> > > > >to get your "simple two sentence mnemonic", irrespectively of your
> > > > >resistance any time the AGENCY WOULD LIKE TO DO IT ... when agency
> > > > >will like to get your "simple two sentence mnemonic", you will spit
> > > > >it out on every request, like a baby spit a dummy
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Wed, 08 Mar 2000 04:15:53 GMT
Paul Koning wrote:
> C is indeed very weakly typed.
People keep saying that, but I don't think they're right.
Except for mixed-mode arithmetic (a deliberate feature),
C is quite strongly typed. There are explicit loopholes
(casts), and, alas, a "generic" pointer type void* that
freely interconverts with all object-pointer types, but
these occur only if the programmer chooses to use them.
The default style of programming in C is quite tightly
constrained by the types of the entities.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: differential cryptanalysis
Date: Wed, 08 Mar 2000 04:28:40 GMT
netpal2u wrote:
> Why are you using your real name?
I'm not ashamed of it..
> Ah yes could you tell me why "they" where putting so much craps
> about aliens and ufo stuff on "that" "your?" web site?
I'm not sure which Web site you mean. The NSA one is not "my"
Web site; their links were documents released under FOIA. The
CUFON site is also not "mine", and the only reason I had seen
it is due to a hit during a Web search on "Callimahos". (You
can also find a flute recording by him via such a Web search.)
My personal Web site is not operational yet.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Wed, 08 Mar 2000 04:38:38 GMT
it's look to me that you can not grasp this simple concept :
everyone can protect file / msg from self - shredded [ === deleted ] at user
private computer
when you can not grasp this concept, all the future discussions are fruitless
...
protect [ file == e-mail msg ] from been readied, is another concept beyond
thread question ...
Michael Sierchio wrote:
>
> Joseph Ashwood wrote:
> >
> > To consider such is an excercise in faith, to practice such
> > is foolishness. You have no way of stopping an individual
> > from taking your code, and debugging it. From there it is a
> > simple matter to grab the key, or create an altered client
> > that will permanently store the keys.
>
> there are definitely ways of
> protecting against tampering the code itself
again, wrong assumption ...
with current privacy issues / concerns it is not possible to protect "against
tampering the code itself" ...
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: An RC5-like cipher
Date: 8 Mar 2000 04:47:18 GMT
Carl Byington <[EMAIL PROTECTED]> wrote:
>>[To Carl]: I'm not familiar with the AVR product line, but maybe
>>there's a part with more program ROM that doesn't cost too much more
>>and you might want to look into switching. You'll probably need
>>something like that sooner or later anyway.
>
>We are already using the largest variant they make.
Hmmm, I see they make some called "mega" with much more code space,
that might be more expensive. The one you're using has 8k of code
which is quite a lot for many types of embedded uses. If you're
running out (especially since you're interpreting code from eeprom)
maybe it's time to look at processors that can run code from external
memory (i.e. your eeprom).
As for the cipher issue, given the hardware you're using, here are
the three solutions so far that seem any good to me:
1) Page most of the RAM data to eeprom, then use RC4, and page the
eeprom data back in. I don't think of that as an overlay since
"overlay" usually refers to shuffling program code (rather than data)
in and out of memory.
2) Implement a block cipher in interpreted code stored in the eeprom,
if that will run fast enough for your needs. Skipjack is probably
a good choice of cipher for this type of implementation. It only
needs about 3 bytes of scratch ram, plus the key (10 bytes) and data
(8 bytes).
3) Actually, given what you said earlier about the content not being
worth much and all you care about is not loading it into unauthorized
devices, why do you need to encrypt it at all? You could just send it
unencrypted, along with some an authentication code keyed to the unit
allowed to run it. The unit would refuse to activate new content that
wasn't authenticated. For example, the per-unit key could be a secret
CRC polynomial stored in the eeprom for that unit. Then the
authentication code would just be a CRC checksum using that
polynomial. I seem to remember hearing that this is very difficult to
invert if the polynomial is not known to the attacker, but I'm not
sure of what happens if you do it with more than one message (adding
some random padding to each message might help but I'm still not sure).
Maybe someone else here knows more about this.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Wed, 08 Mar 2000 04:52:00 GMT
the answer to the question "are self shredding files possible?" is NO
very stupid idea, when I need to read my e-mail that is on my computer to
connect to internet ...
when this is the solution from you, then depositing e-mail's in / CIA / NSA /
FBI / depository will solve this stupid idea ...
therefore, any one who need to read they owned [ e-mail / file ] need to go to
the government depository and request it ... LOL LOL ...
are you asking for this ?
to paraphrase all what you did provide, you are asking for this, don't you ?
Michael Sierchio wrote:
>
> Joseph Ashwood wrote:
>
> > But how do you delete my copy of the key?
I think, he proposed to use TROJAN [ virus ] UTILITY ...
... LOL
>
> You don't have a copy of the key. The plug-in guards the key context and
> retrieves the key each time you click on the message -- it is discarded
> and scrubbed from memory as soon as the message is rendered. The
> key retrieval is secured against snooping and replay.
>
> It doesn't stop you from taking a picture of the screen, but it
> DOES solve the problem of having all of the copies of the message,
> whether they be on your disk or a backup tape, disappear (become
> unreadable, random bits, etc.).
the answer to the question "are self shredding files possible?" is NO
------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: very tiny algorithm - any better than XOR?
Date: Wed, 08 Mar 2000 04:52:31 GMT
"David A. Wagner" wrote:
> In article <[EMAIL PROTECTED]>,
> Samuel Paik <[EMAIL PROTECTED]> wrote:
> > Anyone have any idea how secure RC5 is with a 16 bit block size?
>
> How much data are you encrypting? With more than ~ 500 bytes of
> text, a tiny bit information starts to leak. With megabytes of
> ciphertext, the cryptanalysis problem is probably amenable to
> classical (simple substitution cipher) techniques,
What if, in addition to CBC, you xor a counter into the plaintext? This
would seem to increase the number of blocks before the birthday paradox
starts revealing information.
I may as well post the current version of the RC5-8 (16 bit block size).
It is based on the following C code transformations for RC5 decryption:
If I understand correctly, RC5 decryption looks like this, which you
can transform into a half round version:
for (i = r; i > 0; i--) for (i = 2*r+1; i > 2; i--)
{ {
B = B - S[i*2+1]; B = B - S[i];
B = ROTR(B, A); B = ROTR(B, A);
B = B ^ A; => B = B ^ A;
A = A - S[i*2]; SWAP(A, B);
A = ROTR(A, B); }
A = A ^ B;
}
B = B - S[1]; B = B - S[1];
A = A - S[0]; A = A - S[0];
Now, SWAP(A, B) can be implemented as
/* A = a, B = b; want A = b, B = a */
B = B ^ A; /* A = a, B = b^a */
A = A ^ B; /* A = b, B = b^a */
B = B ^ A; /* A = b, B = a */
And B = B ^ A done twice has no effect. So the half round version now
looks like:
for (i = 2*r+1; i >= 2; i--)
{
B = B - S[i];
B = ROTR(B, A);
A = A ^ B;
B = B ^ A;
}
B = B - S[1];
A = A - S[0];
We've already got a subtraction from B, it turns out to be cheaper to
fold them together even at the 8-bit word size.
for (i = 2*r+1; i >= 1; i--)
{
B = B - S[i];
if (i == 1)
{
A = A - S[0];
return;
}
B = ROTR(B, A);
A = A ^ B;
B = B ^ A;
}
I don't have an assembler for this architecture, I hope this format is
understandable. A little further rearrangement was done to save an
instruction
; 16-bit blocksize RC5 decryption
; entry at :rc5decode (which isn't at the beginning of this code!)
; 15 instructions
; register initialization on entry:
; a - first byte of plaintext
; b - second byte of plaintext
; roundcnt - initialize to 2*r+1
; s - index register pointing to one beyond end of expanded key array
; on exit
; a - first byte of ciphertext
; b - second byte of ciphertext
; roundcnt - 0
; s - index register pointing to beginning of expanded key array
; trashes one register, rotatecnt and tmp can be the same register
; code entry is further down, this saved a branch
; b = rotr(b, a)
; this code rotates by 0 by rotating through entire byte, this
; saved an instruction.
; if the immediate comparison can not be done due to restrictions
; on size of comparison, then make a copy of b in the prerotate
; section and rotate that to extract high order bit. This trashes
; another register and adds another instruction--but may may not
; add any code size, i suspect the cmpi instruction if it can
; be used here is a 32-bit instruction.
:rotate
mov rotatecnt, a ; load up counter
:rotloop
cmpi #0x7f, b ; set the carry with high order bit
ror b
dec rotatecnt
andi rotatecnt, #0x7 ; straightforward to do before
bne :rotloop ; entering loop, but then we'd need
; another branch before the loop
; a = a ^ b
; b = b ^ a
eor a, b
eor b, a
; ENTRY
:rc5decode
; b = b - s[i]
ld tmp, (--s)
sub b, tmp
dec rndcount
bne :rotate
; a = a - s[0]
ld tmp, (--s)
sub a, tmp
ret
I think I've spent way too much time on this already, I may post code to
the RC5 variant I mentioned in another post--it should be obvious that
handling the whitening adds a few instructions. Carl, do you need a
software engineer?
--
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation
You dont know enough about X86 or kernel architectures to argue with me.
- <38b2dc12$0$[EMAIL PROTECTED]> "Leon Trotsky" to Terje Mathisen
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
