Cryptography-Digest Digest #337, Volume #11 Wed, 15 Mar 00 07:13:00 EST
Contents:
Re: Q: Twofish' S-Boxes ([EMAIL PROTECTED])
Re: NIST, AES at RSA conference (John Savard)
Re: Assistance needed With finding an algy that does not (Guy Macon)
Re: sci.crypt Cipher Contest Web Site (Sander Vesik)
Re: NIST, AES at RSA conference (John Savard)
Re: NIST, AES at RSA conference (John Savard)
Re: Q: Coding of music notes (martin2305)
Re: Improvement on Von Neumann compensator? (Guy Macon)
Off-topic null pointers (was Best language for encryption??) (David Hopwood)
Re: streaming cyphoidians (David Hopwood)
Blind recipient hiding with RSA (was Re: encrypting to unknown public (David
Hopwood)
Re: Blind recipient hiding (was Re: encrypting to unknown public key?) (David
Hopwood)
Re: Blind recipient hiding with RSA - correction (David Hopwood)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Q: Twofish' S-Boxes
Date: 15 Mar 2000 10:14:38 GMT
Thank you for the information. (It appears as if it was just a bad case of
uncommented implementation code. Also, I could not tell from your paper if
you used arithmetic addition and multiplication or bitwise XOR and AND as
field operators.)
In a previous article, <[EMAIL PROTECTED]> writes:
>In article <8alti3$434$[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
>> The box I am referring to is a combination of the four s-boxes and the
columns
>> of the MDS matrix. My question should read if it is true that the
g-function
>> is not bijective and why not?
>
>If I understand your question correctly, yes, it is bijective.
>
>Why? It may be written as the sequential composition of two
>functions: (1) the four parallel 8-to-8 S-boxes; and (2) the
>MDS matrix (32-to-32). Each of those two transformations are
>bijective. (Each S-box is bijective; the MDS matrix is bijective.)
>The composition of bijective functions is bijective, so the
>whole thing is bijective.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Wed, 15 Mar 2000 09:49:38 GMT
On Wed, 15 Mar 2000 02:11:11 GMT, Bryan Olson <[EMAIL PROTECTED]>
wrote, in part:
>The point is that the composition of three ciphers is a
>cipher. The distinction is artificial; it's only in your
>mind and not in the encryption function.
but since
>It makes no sense
>to say any cipher a single point of failure while the stack
>is not. The set of ciphers contains the set of stacks.
instead of one set of three ciphers, each cipher can be changed. The
distinction that is real is that each cipher is replaced as a whole
with another cipher (instead of after, say, a partial number of
rounds).
As I've noted, the problem of communication here is that, while "no
cipher is provably secure" is a theoretical problem, and one that
seems insoluble for the moment, what Terry Ritter is proposing is
merely a _practical_ remedy.
A means of significantly increasing the strength of the cipher systems
in use, as a response to the theoretical problem. Of course, the
theoretical problem stays with us. But a single block cipher, with a
consistent round structure, and so on, does at least seem to be more
likely to have a possible unknown weakness than a system which
presents the attacker with a combined group of such ciphers taken from
a large ensemble whose identity within that ensemble is itself secret.
Simply because Terry Ritter doesn't himself have a crack for MARS,
let's say, up his sleeve to show you doesn't mean either that the
theoretical problem he is pointing out is no cause for concern. And
simply because it can only be claimed for his proposed response to the
problem that it can improve security from a practical standpoint,
without, in a mathematical sense, abolishing the theoretical problem,
that doesn't make it useless.
Plenty of people build houses strong enough to survive a hurricane or
an earthquake...without thinking that it is useless, because they
aren't strong enough to survive an asteroid impact.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Assistance needed With finding an algy that does not
Date: 15 Mar 2000 05:25:01 EST
[EMAIL PROTECTED] (NFN NMI L.) wrote:
>My GOD, that post was nearly incomprehensible.
You don't have to call me your God. "Guy" is acceptable. :)
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest Web Site
Date: 15 Mar 2000 10:29:21 GMT
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <WPAx4.1$[EMAIL PROTECTED]>,
> "Adam Durana" <[EMAIL PROTECTED]> wrote:
>> I put together a web site with the a draft of the requirements for
> entries.
>> I need feedback on the requirements and suggestions from everyone
> planing on
>> participating
> Might I suggest to anyone who is planning on participating:
> If you actually have time to spend on examining the security of
> symmetric ciphers, that you instead select one of the AES candidates
> and spend time analyzing it instead?
> AES is important. If you have spare time, why not spend it on something
> important, instead of wasting it on a 'cipher' that will never see
> the light of day?
> If you want to be taken *seriously* by the crypto community, I can think
> of no better way of doing so than by exposing a weakness in one of the
> AES ciphers.
Just IMHO: participants in the 'beginner' and 'intermediate' categories
may well have not enough skill to do anything against AES chiphers.
It takes a good stomack to digest the MARS paper, for example 8-)
> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him think"
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
Sander
There is no love, no good, no happiness and no future -
these are all just illusions.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Wed, 15 Mar 2000 10:07:04 GMT
On Wed, 15 Mar 2000 03:59:55 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>Cipher systems which change ciphers must coordinate cipher changes on
>both ends. It would be insane to do this as unciphered plaintext.
>The opponents have no ability to force particular ciphers by changing
>the ciphertext because changed ciphertext will be detected.
But you see where this is heading. If all ciphers are insecure, except
when multi-ciphering is used, then the negotiation cipher is insecure
unless you negotiate the negotiation, and then...
Of course, you've already addressed this point, by noting that one
enciphers the negotiation using a longer key, and more encipherment
steps, than are necessary when the algorithms are from a large pool,
unknown to the attacker.
Since the AES candidates, with the partial exception of MARS, have a
single consistent round structure, the theoretical problem that "no
cipher can be proven secure" does translate into a somewhat greater
reason for concern in a practical sense for such a cipher than for a
multi-ciphering system.
Of course, the extent of the required concern can't really be
quantified until *after* those ciphers are broken. Which is a bit
late.
Of course, the multi-ciphering system is still a cipher, and can't be
mathematically proven absolutely secure either. What is creating this
argument is that you are proposing a practical solution to what is
seen, by the other side of the debate, as _only_ a theoretical
problem.
Of course, the other side of the debate only makes sense if, in a
practical sense, the AES finalists are already so secure that your
multi-ciphering process is merely gilding the lily. This is, in fact,
something the argument that multi-ciphering is futile absolutely
depends on. And, of course, it can't be proven.
On the other hand, one does have to stop enciphering somewhere. Some
sort of limit has to be placed on the number of layers of encryption,
the CPU time spent on encipherment, and so on. Since even
multi-ciphering can't be *proven* secure, the problem of whether or
not to augment its security by going on to more layers and so on still
remains. Thus, the theoretical problem, by itself, doesn't tell us
where to draw the line.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Wed, 15 Mar 2000 10:12:21 GMT
On Wed, 15 Mar 2000 02:20:58 GMT, Bryan Olson <[EMAIL PROTECTED]>
wrote, in part:
>A cipher is secrecy mechanism, and does not imply
>authentication.
Does not necessarily imply authentication. Presumably, a cipher
technique including authentication is what is proposed.
This is criticising Terry Ritter for not dotting every i and crossing
every t. Such criticism is legitimate, were it applied to a finished
encryption product being offered for sale, since security does depend
on covering all bases. Applying it to a conceptual sketch - even
something on a website, instead of a brief description in posts -
doesn't seem to make as much sense.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
Subject: Re: Q: Coding of music notes
From: martin2305 <[EMAIL PROTECTED]>
Date: Wed, 15 Mar 2000 03:01:34 -0800
Douglas Gwyn wrote:
Mok-Kong Shen wrote:
>>Could someone give links on coding of music notes for computer
>>processing? Are there any coding standards? Thanks.
>MIDI is the nearly universal standard for this. A Web search
>should turn up *plenty* of references.
MIDI is fine for representing notes in terms of pitch, duration,
dynamic etc. Unfortunately it's not much good in a composition
program, where the need is to represent notes in terms of their
position on the musical stave, with accidentals, articulation,
phrasing etc. AFAIK there is no effective standard for this
latter requirement; MIDI seems to be the only (and not very
satisfactory) medium of exchange among different composition
packages.
Martin Taylor
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Improvement on Von Neumann compensator?
Date: 15 Mar 2000 06:01:11 EST
[EMAIL PROTECTED] (Terry Ritter) wrote:
>
>[EMAIL PROTECTED] (Guy Macon) wrote:
>>
>>You also have to either use a source with a lower rate than a
>>typical mantle has or give the Geiger counter a rest.
>
>I don't see a problem: When operating properly, the counter easily
>handles the high event rate. I expect the tube itself should handle
>orders of magnitude higher rates.
I probably overestimated the decay rate of a lantern mantle. There
is a rate at which you have to periodically turn the Geiger tube off
and let it recover, but the mantle probably doesn't come close, given
the long half-life.
>>If you do a thought experiment of measuring your lousy source
>>the way Fourmilab does, you will realize that you would have
>>still received an unbiased and random bit stream...
>
>If the probability of events changes, that influences the expectation
>of which pair of events is likely to have the most delay. The result
>is specifically not "unbiased." Why would you think it was?
Ah. I understand. I was thinking that you could make a large change
in the probability of detecting decay events then do a measurement and
see no change in the probability of the difference of the delay between
events, but now that you mention it, if the probability changes between
your two duration measurements, (as it would in your case of an oscillating
power supply) there would indeed be a bias.
I believe that the method used by HotBits (explained in
[ http://www.fourmilab.ch/hotbits/how.html ] ) would tend to cancel
any bias towards ones or zeros over the long run, and might be able
to compensate the correlation between adjacent time comparisons
that would occur if the sample rate is large compared to the
disturbance rate. Seeing as most folks would want more than a bit
per minute, a change in the detector sensitivity at a 60 Hz. rate
would fit this description.
Here is the HotBits description from their webpage:
| Since the time of any given decay is random, then the interval
| between two consecutive decays is also random. What we do, then,
| is measure a pair of these intervals, and emit a zero or one bit
| based on the relative length of the two intervals. If we measure
| the same interval for the two decays, we discard the measurement
| and try again, to avoid the risk of inducing bias due to the
| resolution of our clock.
|
| To create each random bit, we wait until the first count occurs,
| then measure the time, T1, until the next. We then wait for a
| third pulse and measure T2, yielding a pair of durations. If
| they're the same, we throw away the measurement and try again.
| Otherwise if T1 is less than T2 we emit a zero bit; if T1 is
| greater than T2, a one bit. In practice, to avoid any residual
| bias resulting from non-random systematic errors in the
| apparatus or measuring process consistently favoring one
| state, the sense of the comparison between T1 and T2 is
| reversed for consecutive bits.
|
| [ http://www.fourmilab.ch/hotbits/how.html ]
------------------------------
Date: Tue, 14 Mar 2000 19:28:28 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Off-topic null pointers (was Best language for encryption??)
=====BEGIN PGP SIGNED MESSAGE=====
Runu Knips wrote:
> Jerry Coffin wrote:
> > On Windows NT, any pointer into the first 4 megabytes of the address
> > space is a null pointer. I don't think it's entirely conforming, but
> > there's at least one compiler around that assigns different values to
> > null pointers of different types, so attepting to dereference one
> > will tell you the type without having to trace back to the code that
> > did it.
>
> Hey, thats a cool feature :)))
Does
char * foo() { ... }
void * ptr = (void *) foo();
if (ptr == NULL) printf("ptr is null");
work, though?
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOM6SvjkCAxeYt5gVAQGLMQf+MG0qiEoNkP7qc5Kr5k0DCV4RXzxTSePa
D0w4M2YjDX0YusLLcdJzbZ1exMPIdqBtjkpEI2HTJDZGhdzs145ccqu9otbJ/sJ0
RJF53bgaUJB329gV77Ol50gzUqlwd7A+VfSnKoYzfLIxOu+N8alOhXVxhCt0roGr
4r1KUVsg6CLo+m6buXc6K0p7xSE2hu+FmY+c7RHCO/xD8y6uXkznq62Jd/0R3i+z
u7Y9OVzqZalSist5exIghMn2JMVdaG24Tgaep1G5DQSq31b60YVpvfmTlvM52bRR
/fLRONpQNTWFfsJASZlEuouVUrx8CWGrttF36Kr4FuBfO9f+MlPRzg==
=Z5IO
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 14 Mar 2000 23:36:25 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: streaming cyphoidians
=====BEGIN PGP SIGNED MESSAGE=====
No Brainer wrote:
> I was wondering what is the best method to encrypt/decrypt/create a
> message digest/sign data etc...if all you have is a small window to
> encrypt/decrypt/digest and sign the data with?
>
> For example, if someone wanted to stream video to another person and the
> receiver had to check the validity of the sender but could only receive
> (and HAD to process in stream format) approx. 2k at a time, how would it
> be best done? Remember that the receiver cannot receive the whole
> message to check the sig?
The standard way is to use sequence numbers: split the stream into packets,
prepend or append a sequence number to each packet, and authenticate using
a Message Authentication Code, e.g. HMAC, using a key independent of, but
agreed in the same way as the encryption key. The size of a packet will
depend on what latency is acceptable.
The receiver should not act on the contents of a packet until it has been
authenticated. If the transport preserves the order of transmissions then
the sequence number need not actually be transmitted, but should still be
included in the MAC'd data.
> It there anything like this available?
>
> Is this a dumb question?
No, it's not a dumb question - many people get this wrong because they
believe that authenticating data on a per-packet basis is incompatible
with applications that require streamed data. As a result, there are a
lot of applications out there with inadequate authentication.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOM7MuTkCAxeYt5gVAQH3bggAlvYT6OD6i/EpUgG6MmCFqUZsezQ2iokp
DkF3A6OPu868CN3t7RTQM4E8HuvpPgA3JB73/M31zzTJS+1XsELAGXPpQP2f9Ciw
x9PAhwaXBUMoRuURin+LY3MLqLJgCIp+i0HGVRNBVRO5WRP0P6xYM1krZCC58qfo
MOBZmstI6McSS1So8vE4mDmtqLxU8GJfmUDZ+XbiBic6EqNDaF8pvyq47e1JHCNE
9aDNIOjdLhSEQ/ZGGjfbrEX8nVTnN1J3fEQAL5xmh6n3hMjVv6T3jtOCPjvhqQbs
whp9LZPN6TY2T+bf0RsCy/eXaR8E2wKujgI9OnQP2cn7p+d4pTdb4g==
=4fTM
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 15 Mar 2000 02:08:42 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Blind recipient hiding with RSA (was Re: encrypting to unknown public
=====BEGIN PGP SIGNED MESSAGE=====
Mike Rosing wrote:
> David A Molnar wrote:
> > Yes. If F [i.e. the random input to blinding] affects the
> > decryption algorithm, then it seems that the secret key holder
> > would need to know something about F. I would like it to be the
> > case that blinded keys can be created without any coordination
> > with the secret key holder at all.
>
> That's pretty tough. Basicly, F doesn't do anything.
It's not a problem provided that the blinded public keys fall into
equivalence classes, with one equivalence class per private key.
Then F determines which blinded key from a particular equivalence
class is chosen.
[...]
> I suppose there's some high level math that would allow a "unitary"
> transform so F acts like multiplication by the identity, but gives
> a random looking result.
In a loose sense, this is how BRH-DHAES works: (g, y) -> (g^b, y^b)
preserves the relation y = g^x, where x is the private key. The maths
can be relatively simple, though.
To make this work for other trapdoor functions than discrete log, we
have to find a similar transformation that obscures the public key,
but maintains the relation between public and private keys that
allows decryption to work.
For example, for integer factorisation based schemes, we could
blind a public key by multiplying the modulus by a third factor.
In the case of RSA, the result of blinding a public key (n = p.q, e)
would be (n' = p.q.r, e, bitlength(n)), where the exponent e is
fixed for all users. The private key would include p, q, and
d = e^-1 mod phi(n).
Note that decryption reconstructs the plaintext modulo n (not n'),
so the encrypted blocks must be less than n (hence the need to
include the bitlength of n in the blinded public key). There should
be a minimum value for the bitlength parameter.
If the factors p, q, and r were chosen to be of roughly equal length,
and the blinded modulus n' the same length as would be chosen for
RSA, then this would probably be comparably secure to RSA, and as
fast for encryption (but see the notes below). It would be slightly
faster (using Garner's CRT algorithm) than standard RSA for decryption.
The moduli n' should be chosen so that the most significant 128 bits
or so, and the length, are common to all users. This ensures that the
scheme is recipient hiding, i.e. it is not possible to use the
distribution of ciphertexts to distinguish between public keys (as
discussed in the earlier sci.crypt thread in February).
This scheme seems to have similar security properties to BRH-DHAES:
- it's not possible to link equivalent blinded keys, with significant
probability;
- no-one (including the private key holder), can tell from a
ciphertext, with significant probability, which public key it was
encrypted with;
- when used with OAEP or a similar encoding method, it can be proven
semantically secure and non-malleable, under fairly reasonable
assumptions (that RSAP is hard with the same parameters, in the
random oracle model);
but with some disadvantages relative to BRH-DHAES:
- it is possible to blind a key more than once, but this slows down
encryption, because the modulus length increases each time a key is
blinded;
- it's not possible to rule out special purpose factorisation methods
for moduli of this form, although I don't think that is likely
provided n' is at least 1024 bits;
- low exponent attacks may apply. Normally this would not be a problem
when using OAEP padding, but for this scheme the most significant
third of the bits of the input block (compared to the size of n')
must be zero. I'm not sure how the low exponent attacks on RSA
generalise to moduli with three factors, but it would be prudent to
use e >= 65537;
- the unblinded public key is more vulnerable to factorisation than
the blinded keys (this can be compensated for by increasing the
modulus size, but at the expense of encryption speed relative to RSA).
- RSA is patented until October this year;
- it's not obvious how to do key validation;
- it's mathematically less elegant, IMHO.
I'll call this scheme BRH-RSA-* (e.g. BRH-RSA-OAEP, when used with OAEP
padding).
======
I think it's also interesting that blind PK encryption can be thought of
as a dual to the proposal made by me and (independently) Adam Back, of
encryption schemes that provide non-interactive forward secrecy.
In that proposal, a single public key corresponds to many private keys,
whereas in a blind encryption scheme, a single private key corresponds
to many public keys. Non-interactive forward secrecy seems to be harder
to make secure and practical, though, because it also requires that the
private keys not be equivalent.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOM7ugTkCAxeYt5gVAQHCqAgAyAffoArdz6lLbxcIdgwi5hKhoLNpmxRd
Mn558PkJCxmrd5IP/bIcGnNwPZPlrLk15pN5GA9GlU3cVGpNCZ/kbClh0jpMMqCq
LEU6+EPmxMUKEsLLKI9FcJoub7vY62uW0kz7AVYpoJdJHAyiqqWw8U6P02ejHZsh
2Q2UOWBrl1m0Xo15WLdQY11H+LDtm3kXMMvCAw/8OCzteXeiX3BYPWvZktBRTPf7
rYdDtLrBGJN0iPqQ5BakPnp5ShnxipMyhuu6qXUiXftim3jJhP9tC5yFAdoOH7It
7UYdHG0rZYAh+98daF+hpdgy8yAUkyssktF5UpF8WKNE+j1DLZjHYQ==
=/CCe
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 15 Mar 2000 01:58:23 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Blind recipient hiding (was Re: encrypting to unknown public key?)
=====BEGIN PGP SIGNED MESSAGE=====
David Hopwood wrote:
> For the scheme I described in my other post based on John Savard's
> suggestion (call it BRH-DHAES), [...]
I meant David Wagner's suggestion, sorry.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOM7t9jkCAxeYt5gVAQHQSAgAj6n2G/635xgEu6e7imhARW2sVnq9U7F2
KFmGTWj6NBm94xPXbJg6IOwpx0m1zxsdgqokmmQhZR5Z8qA+HhxB9dqLNdca2Xn0
lTflKV+cho2gOFgP9nU6+Z1Tplhui6kWPSOE0UK2ubbzGqxQwBl4jqPMmYcZdftS
bu4Jv6QEs5h5b5R+AROHnUA9u+etg84Vo1o0m7/yXkjGxJnhBLrrOW5ttKcHw/Jo
5ponYZzUfpyMgmrwfIe2jDLMjPunJEAu0CwhsAIuVqFvKjwR12SRaXPHfzXa5Go1
352OcjqW+KKWEinJJUaW5r/bsOCpJOe4wxz2+2J171ipLZPGTNOKAg==
=NRIM
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 15 Mar 2000 05:58:37 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Blind recipient hiding with RSA - correction
=====BEGIN PGP SIGNED MESSAGE=====
I wrote:
[...]
> This scheme [BRH-RSA-OAEP] seems to have similar security properties
> to BRH-DHAES:
Sorry, no, it's possible to link blinded keys. If n1 and n2 are the
moduli of two equivalent blinded keys, then gcd(n1, n2) = n (the
modulus of the unblinded key). Scratch this scheme, it's insecure.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOM8mUDkCAxeYt5gVAQGR7Qf/Q1F1kbp8RfZHdRXDfQjrbJIMIrx/RWOs
Xm9LhqK8BpF8cD2H0wI9+hNfiMfM3jdZtyZ+APxXKvOe80GcNjL4Sw4La9Kmi9ZR
MWnuQE9eRkaoi8nKawVw6480bN0V8WCwM3ieFtM3m0G5Ju9eB1Do3rDjFV0OQgjQ
BITUYZVMazhvo7ZN+BElyCW5LX9b51iQhyF9VtyMYQDc4HcP5yvIjVfG7SHksun6
V6oAeGd+QH4q9s2PP1iPxfkS4MjAvvXo7PLKwuiB1aRD3XePrKUbs7yEdNob81WX
03atoqS6voTAEH/WbccxV0/kfxQusOJxD5gF00WN+Ju/RtBcaFYoSg==
=6Dn7
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
