Cryptography-Digest Digest #190, Volume #12 Mon, 10 Jul 00 06:13:00 EDT
Contents:
Re: OT Question (was Re: Security in UMTS???) (Michael Schmidt)
$10,000.00 Reward for Paytv / cash card smart card decryption! (Justice403911)
Re: Concepts of STRONG encryption using variable base http://www.edepot.com/phl.html
(Bryan Olson)
Re: Proposal of some processor instructions for cryptographical (Mok-Kong Shen)
Re: Proposal of some processor instructions for cryptographical (Konrad Schwarz)
Re: Using CRC's to pre-process keys (David A. Wagner)
Re: Proposal of some processor instructions for cryptographical (Mok-Kong Shen)
Re: Efficient algorithm to determine relative primality? (Bryan Olson)
Re: A new cipher........ (Runu Knips)
Re: DES Analytic Crack (Volker Hetzer)
[Q] Serpent: Gladman Code incomplete ? (Runu Knips)
acquire a secret authentication cipher bloc ("NP")
Re: Proposal of some processor instructions for cryptographical applications ("Al
Grant")
Re: Proposal of some processor instructions for cryptographical (Runu Knips)
Re: Proposal of some processor instructions for cryptographical applications (Mark
Wooding)
Re: one time passwords and RADIUS (Vin McLellan)
Re: Another AONT (less expensive, this time) (Mark Wooding)
----------------------------------------------------------------------------
Date: Mon, 10 Jul 2000 09:18:09 +0200
From: Michael Schmidt <[EMAIL PROTECTED]>
Subject: Re: OT Question (was Re: Security in UMTS???)
Benjamin Goldberg wrote:
>
> Hrm, are the names 'KASUMI' and 'MISTY' a reference to the japanese
> word/name 'Kasumi'?
>
Yes!
Michael
> David A. Wagner wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Michael Schmidt <[EMAIL PROTECTED]> wrote:
> > > There will be a new data encryption algorithm, called KASUMI, which
> > > has been developed under (more or less) public scrutiny, and is most
> > > likely to be published (check the ETSI web site).
> >
> > It turns out it was already published briefly, then yanked from the
> > website. I have a copy, for instance.
> >
> > Anyway, for those interested, KASUMI is a MISTY variant. I found it
> > mildly surprising that a trusted cipher like 3DES was not chosen
> > (perhaps there were political or economic considerations that
> > outweighed the assurance issues of building a new cipher), but IMHO
> > KASUMI is likely to be far better than the old GSM ciphers, so it
> > seems like a substantial step forward.
> >
> > Next step: end-to-end security!
--
===================================================
Michael Schmidt
===================================================
Institute for Data Communications Systems
University of Siegen, Germany
www.nue.et-inf.uni-siegen.de
===================================================
The 'Thin Client Security Homepage':
www.nue.et-inf.uni-siegen.de/~schmidt/tcsecurity/
===================================================
http: www.nue.et-inf.uni-siegen.de/~schmidt
e-mail: [EMAIL PROTECTED]
phone: +49 271 740-2332 fax: +49 271 740-2536
mobile: +49 173 3789349
===================================================
### Siegen - The Arctic Rain Forest ###
===================================================
------------------------------
From: [EMAIL PROTECTED] (Justice403911)
Subject: $10,000.00 Reward for Paytv / cash card smart card decryption!
Date: 10 Jul 2000 07:23:40 GMT
Dear Sir/ Madam,
Our company is posting a contest. Anyone that can create an automated script
or program to decode any smart card for United States Based Paytv and Cash card
systems.
If you think you can, email us for more information. All correspondence is
strictly confidential. The first one that succeeds will receive $10,000.00 USD
NO JOKE!
This contest is for educational purposes only.
If you decode it today, you are paid tomorrow. Interested persons should send
inquiries to [EMAIL PROTECTED] SERIOUS ENQUIRIES ONLY.
Thanking you in advance for your anticipated cooperation.
JUSTICE403911
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Concepts of STRONG encryption using variable base
http://www.edepot.com/phl.html
Date: Mon, 10 Jul 2000 07:35:36 GMT
[EMAIL PROTECTED] wrote:
[...]
> Any static keylength can be searched through.
[...]
> Why not simply provide a scholarly comment on it.
[...]
> I have yet to get a solid response from this
> community that can find errors or problems with it.
Others have pointed out why we do not worry about
brute-force. I think I can explain where the argument for
the security of this scheme against arbitrarily powerful
brute force goes wrong.
I gather that the number of transformations the cipher can
induce is infinite. The argument is therefore that no
attacker could ever search through the keyspace, even given
an unbounded (though finite) amount of computation. Here
the "key" can be any description of the transformation as
long as the implementation runs in finite time.
Alas the argument is wrong. The keyspace the attacker must
deal with is the one from which we actually chose the key,
not the set the algorithm can accept. For any finite-length
key, a brute-force search can eventually find it. To defeat
unbounded brute-force, we cannot choose any finite length
key with non-zero probability. Thus the argument fails
unless we actually use infinite length keys, which doesn't
work because we'd never finish encrypting anything.
Shannon's "theoretical security" took a different approach.
A brute-force search (even of infinite power) fails because
the attacker get's no clue when he's found the right key.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Mon, 10 Jul 2000 10:14:03 +0200
Stephen Fuld wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > Thomas Womack wrote:
> > > "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote
> > > > Transposition is one of the basic operations in cryptography.
> > > Is it, any more? Having a look at the AES candidates, most of them
> > > carefully refrain from calling for bit transpositions simply because
> > > they're rather hard to implement.
> >
> > Whether the operation is basic is a different question from whether
> > awkward support for it causes it to be underutilized.
> >
> > Transposition and substitution, sometimes under the names diffusion
> > and confusion, are often considered basic cryptographic principles.
>
> Sure, but I think the question is whether that transposition needs to be on
> non-byte boundaries and thus hard for current processors (That is, those
> without bit permute instructions.). I think AES shows that one can get very
> strong and fast encryption without needing these extra instructions.
I don't think that's the right kind of argument. Lacking these instructions
prevents certain algorithms from emerging which may be better than
those optimized under the current constraints. (I just learned from the
follow-up of Bruce Hoult, however, that permutation is implemented on
the processor of PowerPC.)
M. K. Shen
------------------------------
From: Konrad Schwarz <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Mon, 10 Jul 2000 10:03:10 +0200
"Douglas A. Gwyn" schrieb:
>
> What would serve a wide variety of applications, including
> cryptology, better would be good support for bit addressing.
> I've discussed this with computer architects in the past, and
> they have agreed that it would be useful, but were not able to
> sell the idea to management, largely because common programming
> languages are unable to make direct use of the facility. There
[...]
Several Siemens embedded uP have support for bit addressing
(though limited to a subset of the addressing space).
Personally, I disapprove of this, because bit addressing requires
atomic read/modify/write, which I expect will slow the memory
subsystem down (esp. for multi-processors).
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Using CRC's to pre-process keys
Date: 10 Jul 2000 01:01:05 -0700
In article <[EMAIL PROTECTED]>,
Scott Nelson <[EMAIL PROTECTED]> wrote:
> If we assume that the hash is completely unbiased
> within the 128 bit space, hashing all possible 128 bit
> keys would result in approximately 1/e values being
> missed, and 1/e single hits, with the rest being
> hit multiple times. Effectively reducing the key
> space by less than 3 bits, which I agree is pretty
> irrelevant in most cases. It's not 0 though,
> so this is an advantage that CRC has over SHA1.
Yup, looks irrelevant to me. Brute-forcing a 125-bit keyspace is utterly
infeasible, so this `advantage' of CRC over SHA1 appears negligible to me.
So, it still seems to me that collisions are not a relevant factor in the
decision whether to use CRC or SHA1.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Mon, 10 Jul 2000 10:17:25 +0200
Helger Lipmaa wrote:
> Finite field GF(2^8) and GF(2^16) multiplication (modulo some fixed irreducible
> polynomial) would be nice. May be also some other operations (x->x^-1, e.g.).
Maybe some support for multi-precision integer arithmetics would also be
advantageous, not only for crypto but also for other scientific applications.
M. K. Shen
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Efficient algorithm to determine relative primality?
Date: Mon, 10 Jul 2000 08:10:34 GMT
David Blackman wrote:
> Isn't there an algorithm using only shift, mask
> and subtract that runs in N ** 2 time?
Yes. I'll include a Python implementation below.
> Asymptotically that would be quite a bit faster than
> Euclid's which is around N ** 3 using long division
No, Euclid's is still only order N**2 using a reasonable
modulo algorithm.
> and maybe (N ** 2) * (lg(N) ** 2) or similar
> nonsense if you can get away with FFTs for
> modulus (and i'm not sure you can).
Not needed to reach N**2. Within Euclid's algorithm,
we expect trial divisors to be small. Computing the
remainder of an N bit number divided by an N-3 bit
number is linear-time even for the simple algorithm.
> I think
> shift/mask/subtract would be faster in practice
> for crypto sized numbers as well.
I don't remember the details, but I found shift-subtract
to be a loser, though not by much.
In implementing RSA, there's little point in optimizing
the GCD algorithm. Its already much faster than the
exponentiation, and exponentiation is much faster than
prime generation.
The binary GCD algorithm in Python:
def binaryGCD(x, y):
if x < y:
x, y = y, x
g = 1L
while x&1 == 0 and y&1 == 0:
x = x>>1
y = y>>1
g = g<<1
while x:
while x&1 == 0:
x = x >> 1
while y&1 == 0:
y = y >> 1
if x >= y:
x = (x-y) >> 1
else:
y = (y-x) >> 1
return g*y
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 10 Jul 2000 10:15:41 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: A new cipher........
Simon Johnson wrote:
> In your post this is just being Pedantic; its my first paper, it
> likely to be incorrect. secondly, its _going_ to be weak,
> there's no way that my first cipher is going to be strong,
> third... the end user cannot use an existing algorithm, and only
> has to be better than XOR's level security, (i'm sure my cipher
> isn't that bad :p)
If your cipher is incorrect, why don't you just fix it ? I don't
understand why you think there 'is no way that my first cipher is
going to be strong'.
> This however is more intresting....... I presume that the moral
> of this story is to consider the key shedule more carefully and
> insure all the bits of the key are used? I've been told that
> using the same shift for all the rounds would allow related key
> cryptanalysis to be successful, is this person sprinkling fairy
> dust or is this true?
If cryptography would be simple, why does the NSA have more
mathematicans (~40,000) than any other organization arround the
world ?
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: DES Analytic Crack
Date: Mon, 10 Jul 2000 10:47:35 +0200
Mok-Kong Shen wrote:
> What do you mean by your second approach? Is that an trial and
> error method? (If yes, what guides you in the search?) Would you
> please give literature references on the progress you mentioned?
This kind of progress came from formal verification techniques.
Unfortunately right now I don't have web access, but you could check
amazon.de (or a search engine) for keywords like "binary decision
diagram". "Graphical representation of boolean functions" and the like.
The technique itself is already rather old. The point is that you can
find a binary decision tree that is unique to each boolean equation.
Kind of a canonical normal form.
Once you got that (which is the part that still can be NP complete
in a few bad cases) solving the equation and several other things
become trivial.
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
Date: Mon, 10 Jul 2000 10:46:04 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: [Q] Serpent: Gladman Code incomplete ?
Last weekend I have studied the Serpent paper, and was surprised how
easy
to understand and elegant this cipher is, even if I missed some of the
very basic features of a cipher description in it, meaning test vectors
and at least an idea how to implement the cipher in software.
I also read the Serpent implementation of Brian Gladman
(http://www.btinternet.com/~brian.gladman/cryptography_technology/aes/serpent.c),
but what I don't understand is the fact that Serpent defines an initial
and final bit transformation (called IP and FP in the paper), which are
not implemented in the cipher of Mr. Gladman. So is it true that Mr.
Gladman's implementation is in fact incomplete ?
------------------------------
From: "NP" <[EMAIL PROTECTED]>
Subject: acquire a secret authentication cipher bloc
Date: Mon, 10 Jul 2000 11:06:23 +0200
Hello
How can I acquire a secret authentication cipher bloc
for electronic component ?
Cipher bloc must be hardware compliant (< 500 gates)
Key length: 64 bits
Signature result: 8-16 bits
Data processed: 64-128 bits
Input random: 32 bits.
Thanks for information or contact.
NP
------------------------------
From: "Al Grant" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Mon, 10 Jul 2000 10:19:26 +0100
"Konrad Schwarz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Personally, I disapprove of this, because bit addressing requires
> atomic read/modify/write, which I expect will slow the memory
> subsystem down (esp. for multi-processors).
Is that a worse issue than byte addressing? With today's
processors, isn't the concept of 'byte' just as artificial as that
of 'bit', and wouldn't it be easy to extend the hardware already
in place to support byte addressing to support bits as well?
------------------------------
Date: Mon, 10 Jul 2000 11:18:04 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Mok-Kong Shen wrote:
> Transposition is one of the basic operations in cryptography.
> However, it is in my view poorly supported currently by processor
> instructions at the bit level at which all modern block ciphers
> operate.
> (1) Swapping. This instruction needs an operand that specifies
> the level at which the swapping is to be done. At the first
> level, the word (register or memory) is divided into two halves
> that are exchanged in positions. At the second level, the
> swapping is done separately on each half of the word.
> Analogously for the higher levels.
>
> (2) Mirroring. This also has levels similar to swapping. At the
> first level, the bits of the word referenced are exchanged by
> mirroring about the central axis. At the second level, the
> mirroring is done separately on each half of the word.
> Analogously for the higher levels.
>
> Another processor instruction that I think is desirable is
> to obtain the parity of groups of bits (e.g. 4, 8, etc.) from
> consecutive words in memory and accumulate these into a word.
> This could be useful to so to say distill the entropy out of
> a given bit sequence.
>
> I should appreciate comments and suggestions of further
> processor instructions that are useful for encryption purposes
> and that are, hopefully, not inefficient for hardware
> realizations.
A general purpose processor has to do many other things than
only cryptography, so adding instructions just for crypto seems
to be a bad idea to me.
The serpent paper describes a bitslice operation. I don't
think that one is an good idea, because it is not a RISC
instruction, so using it efficiently would require a genial
compiler designer or handcoding.
When I have worked on Paranoia, my little cipher in the
contest, I had to spend much time thinking about exactly
that theme. I have described a network in the cipher paper
which requires 109 bits to specify all (32!) possible
bit permutations of a 32 bit word. One could implement
that with using the following 4 instructions:
BRT1 src, dest, mask
- For each pair of bits at the position 2*n and 2*n+1,
n in 0..15, of bits in src, if the bit n is set in mask,
the values of the bit pair is swapped before getting
assigned to dest. Therefore the mask has 16 bits.
BRTL2 src, dest, mask
- For each 4 bits in the positions 4*n to 4*n+3, n in 0..7,
the bits are rotated according to the 2 bits in mask
at position 2*n and 2*n+1, n in 0..7. Therefore mask
has 16 bits.
The rotations look like that:
mask0 mask1 src dest
0 0 abcd abcd
0 1 abcd bcda
1 0 abcd cdab
1 1 abcd dabc
BRTR2 works just the other way round.
BRTL3 src, dest, mask
- For each 8 bits in the position 8*n to 8*n+7, n in
0..3, the bits are rotated according to the 3 bits
in mask at position 3*n to 3*n+2, n in 0..3.
Therefore the mask has 12 bits.
BRTR3 rotates just the other way round.
BRTL4 src, dest, mask
- For each 16 bits in the position 16*n to 16*n+15,
n in 0..1, the bits are rotated according to the
4 bits in mask at position 4*n to 4*n+3, n in
0..4. Therefore the mask has 8 bits.
BRTR4 rotates just the other way round.
Then one can realize any bit transformation using the
instructions:
BRT1 reg1, reg1, mask0
BRTL2 reg1, reg1, mask1
BRTL3 reg1, reg1, mask2
BRTL4 reg1, reg1, mask3
ROTL reg1, reg1, mask4 # mask4 has 5 bits
BRTL4 reg1, reg1, mask5
BRTL3 reg1, reg1, mask6
BRTL2 reg1, reg1, mask7
BRT1 reg1, reg1, mask8
However, I doubt these instructions have any general
purpose use, and these BRT* instructions themselves
can be implemented relatively efficiently with using
ordinary shift and bitwise operations.
> Note. The concepts of the instructions described above are
> herewith in the public domain. Their implementation and use,
> in particular in cryptographical applications, are therefore
> NOT patentable by any persons/firms.
Of course, to mine as well.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: 10 Jul 2000 09:36:05 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Transposition is one of the basic operations in cryptography.
> However, it is in my view poorly supported currently by processor
> instructions at the bit level at which all modern block ciphers
> operate.
There are several reasons for this.
One is that hardly anything other than crypto needs dedicated bit
permutation instructions, so it's not worth the gate count.
A second is that doing the bit permutation the `hard' way isn't the way
ciphers are implemented in software: we have lookup tables and
everything works quite nicely. Look at a heavily optimized
implementation of DES some time (not mine: a *heavily* optimized one).
A third is that bit permutations aren't very good. Do you remember when
Tom introduced TC1, which was based on a simple substitution/permutation
function? Bit permutations can move bits around, but they won't
increase the number of active bits in an attack. Bit permutations are
(quite rightly) dying out now, in favour of new diffusion techniques
such as MDS codes.
> (1) Swapping. This instruction needs an operand that specifies the
> level at which the swapping is to be done. At the first level, the
> word (register or memory) is divided into two halves that are
> exchanged in positions.
This is easily done using a rotate, e.g, mov r0, r0, ror #16.
> At the second level, the swapping is done separately on each half of
> the word. Analogously for the higher levels.
Doing this isn't very difficult either. Consider:
mov r14, #&ff
orr r14, r14, r14, lsl #16
eor r1, r0, r0, lsr #8
and r1, r1, r14
eor r0, r0, r1
eor r0, r0, r1, lsl #8
will independently swap bytes 0 and 1, and 2 and 3. Similar sequences
will do similar jobs for nibbles and bit pairs.
Finally, I think the point that's being missed is that, as cipher
designers, it's our job to come up with designs which are secure and
efficient in a *given* environment. We need not, and should not, impose
further requirements on the implementation platform: instead, we work
with its strengths and avoid its weaknesses. And I believe that the AES
competition is showing, extremely clearly, that this is indeed possible
even under quite extreme constraints.
-- [mdw]
------------------------------
From: Vin McLellan <[EMAIL PROTECTED]>
Subject: Re: one time passwords and RADIUS
Date: Mon, 10 Jul 2000 05:50:50 -0400
greuh wrote:
> More about the subject :
> http://www.homeport.org/~adam/dimacs.html
> It's 4 years old, I hope things have changed since then !
You should dig a little deeper, maybe.
For perspective, at least check out the note John Brainard of RSA Labs
sent to Adam Shostack prior to the publication of that paper. Mr.
Shostack has it on his Homeport website at
<http://www.homeport.org/~adam/brainard.html>. Unfortunately, there is
no link from Adam's "Apparent Weaknesses" paper to the RSA reply.
In the mid-1990s, there were two prominent critiques of the ACE
protocol published. The popularity of ACE/SecurID made it an attractive
target and led to a half-dozen organized efforts to crack the SecurID
hash or deconstruct the ACE client/server protocol by prominent Gray
Hats, competitors, and sundry infosec consultants looking to count
coup. It was a fun time.
Adam Shostack, now at Zero Knowledge Systems -- then, a prominent
consultant, and founder of the ACE-focused "SDAdmin" mailing list --
presented his paper, "Apparent Weaknesses in the Security Dynamics'
Client/Server Protocol," at a DIMACS workshop in October of 1996.
Mr. Shostack reverse-engineered version 1.2 of the ACE protocol to
identify a subtle flaw in the protocol which Security Dynamics (which
had just purchased RSA) had discovered in a routine internal security
review, and fixed, some 18 months earlier.
The problem had been patched in a free "mandatory" upgrade to ACE v.1.3
-- flagged as necessary to address unspecified security issues and a
couple of bugs. ACE/SecurID customers knew the 1.3 upgrade had patched a
security problem, and serious one; but until Mr. Shostack published his
paper no one outside the company knew specifically what the problem had
been.
By the fall of '96, when Shostack published his paper, RSA was shipping
ACE/Server v.2 and about to announce ACE version 3.0.
In September, 1996, "PieterZ" of Secure Networks Inc.,(now part of
NAI,) had also published a paper: "Weakness in SecurID." PieterZ's paper
was a more tactical analysis which suggested a variety of potential
attacks on the ACE protocol. See:
<http://www.tux.org/pub/security/secnet/papers/secureid.pdf>.
As the author of a then-popular FAQ on ACE/SecurID, and as a long-time
consultant to RSA, I challenged a lot of Mr. Z's assumptions and
arguments in a vigorous and widely-circulated exchange. See:
<http://www.dataguard.no/bugtraq/1996_3/0458.html> and
<http://www.dataguard.no/bugtraq/1996_3/0474.html>.
Both critiques of ACE/SecurID attracted a lot of attention, then and
since, from potential customers doing due diligence.
YMMV, but I -- and, apparently, most of the ACE/SecurID user community
-- felt that the SecurID, two-factor authentication, and the ACE
protocol, had weathered the storms quite well.
Two years later, ACE/SecurID won the highest level of approval, in a
poll of SANS corporate network and security managers, of all network
security products. See:
<http://www.sans.org/newlook/publications/powertools.htm>
In my favorite citation about the ACE/SecurID technology, SANS also
reported that 92 percent of the SANS network managers who had hands-on
experience with the technology said that they actively recommmended
ACE/SecurID to their peers as a critical component for network security.
That, I assert, indicates something more than mere market share.
In the first six months of this year, the newest model, ACE/Server 4.X,
has already won three major industry awards. See links to the
evaluations at: <http://www.rsasecurity.com/products/securid>
I'm still a consultant to RSA, so please take my opinions with an
appropriate grain of salt.
Surete,
_Vin
----
"Cryptography is like literacy in the Dark Ages. Infinitely potent, for
good and
ill... yet basically an intellectual construct, an idea, which by its
nature will
resist efforts to restrict it to bureaucrats and others who deem only
themselves worthy of such Privilege." _A Thinking Man's Creed for
Crypto _vbm
* Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Another AONT (less expensive, this time)
Date: 10 Jul 2000 09:51:27 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> The following is both to transform, and to reverse the transform:
> ( a, x ) = ( first-20-bytes-of-message, rest-of-message )
> b = a XOR SHA1( x )
> y = ARC4( b, x )
> c = b XOR SHA1( y )
> transformed-message = c || y
This is OAEP with a pointless extra round. OAEP already has proven all-
or-nothing properties.
(Alternatively, you could look at it as unkeyed BEAR (or is it LION? --
I can never remember which is which), but that's not helpful.)
-- [mdw]
------------------------------
** 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
******************************
