Cryptography-Digest Digest #459, Volume #14      Sun, 27 May 01 23:13:01 EDT

Contents:
  Re: Small (not fast) RIPEMD-160 (Mark Wooding)
  Re: Good crypto or just good enough? (wtshaw)
  Re: Good crypto or just good enough? (wtshaw)
  Re: A problem of combinatronic$ :: ATTN: Mr Mok Kong Shen (Mok-Kong Shen)
  Re: To prove PGP can easily be misused... (Mok-Kong Shen)
  2,2-multipermutation? ("Tom St Denis")
  Re: A problem of combinatorics :: ATTN: Mr Mok Kong Shen ("BenZen")
  Re: Medical data confidentiality on network comms ("Harris Georgiou")
  Re: Good crypto or just good enough? ("Harris Georgiou")
  Re: How do boomerang attacks work? ([EMAIL PROTECTED])
  Re: 2,2-multipermutation? (Mok-Kong Shen)
  Re: How do boomerang attacks work? (Tom St Denis)
  Re: A generic feistel cipher with hash and gf(257) mixers (David Wagner)
  Re: 2,2-multipermutation? ("Niels Ferguson")
  Stream Cipher combiners (Tom St Denis)
  Re: Euroean commision will recommend all citizens to use encryption in email next 
week, because of echelon. (Crypto Neophyte)
  Re: How do boomerang attacks work? ([EMAIL PROTECTED])
  Re: Help with 'P' in PKCS1V2.1 RSAES-OAEP (Sam)
  Re: Medical data confidentiality on network comms ("Roger Schlafly")

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Small (not fast) RIPEMD-160
Date: 27 May 2001 20:24:43 GMT

Ian Stirling <[EMAIL PROTECTED]> wrote:

> Impressive, though the stripped .o file is >2K, with all the compilers
> I have. (egcs and gcc).

I measured the size of the text using the `size' command (part of GNU
binutils).  This avoids counting all of the cruft in the object file
like symbol names and relocation directives.

> What's the proper tool to show me bytes per function, or better, bytes
> per line of code?

`nm' will show you function offsets, I think, so you can work out the
function sizes.  `objdump -S' will show you a disassembly interleaved
with the source code.

> I'm pretty sure I can get it a little smaller than this, as I have a 
> cunning plan...

Good luck.  I'd be interested to see the finished result.

[Oh, anyone else who wants the code can mail me and ask.  It's free
software, under the GPL.]

-- [mdw]

------------------------------

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Good crypto or just good enough?
Date: Sun, 27 May 2001 14:00:11 -0600

In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:

> "SCOTT19U.ZIP_GUY" wrote:
> > The NSA wants people to use [Rijndael] for several years.
> 
> I'm sure the NSA would be happiest if everybody used the *same,
> standard* cryptosystem, only because their cryptanalysts could
> concentrate resources on cracking just the one system instead
> of spreading them thinly across numerous commonly-used systems.

This cuts deep and has so for generations. Most modems these days are
field programible, meaning that the basics for any communication are
vulnerable.  Decades ago, a legal requirement passed that all modems meet
certain specifications.  This alone greatly facilitates monitoring, even
before field progamible status.  However, it is possible to bypass
standard specifications with modulation that can't be forbidden because is
expressly allowed for other purposes.

If you are thinking of how to do good crypto, look at the total process of
communications and how to shut out any attacker, even down to using custom
modems that work directly with acceptable text and encrypted data.  This
is not really hard to do.  Microprocessor based systemss are unreliable,
vulnerable, and dedicated designs are not. I was wrong when I thought that
it was the other way; its back to the drawing board and soldering iron to
get it right.
-- 
Suppose California quit sending food back East.
Would Gerorge be ready to barter with energy?

------------------------------

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Good crypto or just good enough?
Date: Sun, 27 May 2001 14:11:53 -0600

In article <[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
> 
> There are no "good" block ciphers, just "less badder".  If we can break
> cipher X and not Y then Y is not as bad as X.
> 
> Tom

You could say the same of stream sipher....guess you have.  But, the
alternative I push offers wildly better security.  It's not hype, but a
wakeup call from me.  Otherwise, you are welcome to beat you head against
the same old wall if you choose, but I ask why for your sake, not mine.
I'm on the way out, unfortunately from my standpoint, but my dream is for
you to say earlier than later that you should have listened to reason.
-- 
Suppose California quit sending food back East.
Would Gerorge be ready to barter with energy?

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A problem of combinatronic$ :: ATTN: Mr Mok Kong Shen
Date: Sun, 27 May 2001 23:16:04 +0200



BenZen wrote:
> 
[snop]
> Then I wondered about the 200$ reward.
> What are the exact criterias, aside the fact Mr Shen expects the applicants
> to be 'experts' as he states in the first parragraph ?

I am happy that you have interest to tackle the problem.
The reward is yet open. The criteria is that you have
to give a proof of the result just like any accepted
results in mathematics are proved. (As to the word 
'expert', anyone who solves the problem is an expert 
for me (compared to myself whose poor knowledge is
not sufficient to solve it).)

M. K. Shen

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: To prove PGP can easily be misused...
Date: Sun, 27 May 2001 23:44:45 +0200



wtshaw wrote:
> 

> It does not follow that they are in place or even have competence to pick
> qualified people.  The military point of view is to threaten and
> intimidate to get what they want, which extends to the way certain
> organizations try to push their own agendas, those of politicians be
> damned.  Privacy is their last consideration if that cannot also be
> subverted.  Security is not an art but a science to be learned at all
> levels; leave it to someone else and your surrender your privacy.

If your view is that some (or even many) politicians
are unintelligent, then you may have a point. Otherwise,
every person, whether involved in politics or not, is
certainly not happy when his privacy gets compromised.
Politicians are more liable to get into headlines of
newspapers, when certain secrets become known to the
public. From this view, it couldn't be that 'privacy
is their last consideration'. (It could well be that
privacy of the common people -- not their own --
is their last consideration, on the other hand.)

M. K. Shen

------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: 2,2-multipermutation?
Date: Sun, 27 May 2001 22:42:46 GMT

To get away from politics for a bit...

Does the following pseudocode define a 2,1 Multipermutation?  (a,b) forms
the input

1.  a = a xor b
2.  a = S[a]
3.  b = b xor a
4.  b = S[b]

Where S is some bijection.  assume for no entries in S does S[a xor b] xor b
equal zero (i.e not linear enough).

>From what I can tell if 'b' or 'a' differs (not both) a will differ and
2^n - 1 of the time (assume S is a n-bit function) b will not differ ...
hence it's not a 2,2 multipermutation.

Is this true?
--
Tom St Denis
---
http://tomstdenis.home.dhs.org



------------------------------

From: "BenZen" <[EMAIL PROTECTED]>
Subject: Re: A problem of combinatorics :: ATTN: Mr Mok Kong Shen
Date: Sun, 27 May 2001 18:48:44 -0400

Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
>BenZen wrote:
>>
>[snop]
>> Then I wondered about the 200$ reward.
>> What are the exact criterias, aside the fact Mr Shen expects the applicants
>> to be 'experts' as he states in the first parragraph ?
>
>I am happy that you have interest to tackle the problem.
>The reward is yet open. The criteria is that you have
>to give a proof of the result just like any accepted
>results in mathematics are proved. (As to the word
>'expert', anyone who solves the problem is an expert
>for me (compared to myself whose poor knowledge is
>not sufficient to solve it).)
>
>M. K. Shen
>
Thanks for clarifying the issue for the benefit of all.
I will continue to work on the problem at leisure time,
while understanding the Mathematical proof is currently out of my reach.
You are kindly, very humble, and I conclude noone has yet resolved it.
I shall hereby present my excuses for doubting your purpose,
and continue to appreciate and share your Mathematical enthousiam.

I should have known better from reading your favorite citation:
'Should not we, then, exert ourselves to do good? '
  -From Tai Shang Kan Ying Pien. Probable author: Ko Hung, 4th century A.D

Here is one of my favorite:
"Turn your face to the sun and the shadows fall behind you." -Maori proverb
This is also on my top ten list:
"Vision without action is a daydream. Action without vision is a nightmare."
   -Japanese proverb

But there is one thought that emerged while talking a walk this winter,
and I noted it; It is not in my habbit, and that alone makes it my favorite. ;)

There is no peace of mind without purpose.
There is no rest, each day at a time.
There is no glory, without proper ending.

Regards,
Benoit Jobin AKA: Ben Zen.
========================
akh tI akh gAyi ka:h    -Kashmiri
One plus one make eleven.
(In unity there is strength. Two heads are better than one. )



------------------------------

From: "Harris Georgiou" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Mon, 28 May 2001 02:07:55 +0300

Thank you all for your responses.
I have traced a link to the actual HCFA confidentiality requirements and I
believe that covers my quest.
The fact that 128-bit ciphers where selected as minimum standard was what I
expected, but to my surprise too only 1024-bit keys where proposed for
asymmetric crypto and digital signatures/authentication. I guess I has to do
with hardware requirements (mostly on hardware devices), although no
signifficant difference in speed would emerge for any standard personal
computer.
I would would also like to hear about similar standards stated by European
Union agencies, if anyone has references to them.



--

Harris

- 'Malo e lelei ki he pongipongi!'



Ο Tom McCune <[EMAIL PROTECTED]> έγραψε στο μήνυμα συζήτησης:
mtbQ6.70603$[EMAIL PROTECTED]
> In article <9eju29$156j$[EMAIL PROTECTED]>, "Harris Georgiou"
<[EMAIL PROTECTED]> wrote:
>
> >The term "closed loop" I used refers to a group of processes (services)
> >working together independently or in sequence (request relay), so my
design
> >mainly addresses the issue of authenticated processes interconnection
rather
> >than physical login by users.
> >Anyway, is it a fact that biometric security devices have been used in
> >medical facilities? I thought only military or goverment organizations
could
> >affort the cost of them  :-o
> >Cheers!
>
> I work for the a State Office of Mental Health.
>
> Our facility policy does not allow the transfer of any patient information
> over the internet, but state OMH policy requires that patient information
> transferred over the internet be encrypted (that was not clarified in the
> policy when I looked - probably a year or so ago).
>
> We have a state wide area network that we can transfer patient
> information over - I beieve that is encrypted - transparently to the user,
> so I have no idea what that consists of.
>
> If my recall is correct, HCFA requires 128 bit symmetric encryption (but I
> almost get the idea that it might have said something about either 112 or
> 168 bit, which would be in reference to Triple DES, I assume - that was
> again some time ago when I looked that up).  What I was then surprised
about
> was that the asymmetric encryption was only required to be 1024 bit - I
> would have thought longer term privacy would warrant 2048 bits.
>
> I am now required to do my psychological evaluations, progress notes,
> etc., while connected to a server in the state capitol (about 80 miles
> away), and that requires fingerprint scan verification.
>
> Tom McCune
> http://www.McCune.cc
> Please use PGP for Privacy & Authenticity



------------------------------

From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Mon, 28 May 2001 02:19:18 +0300

> If you are thinking of how to do good crypto, look at the total process of
> communications and how to shut out any attacker, even down to using custom
> modems that work directly with acceptable text and encrypted data.  This
> is not really hard to do.  Microprocessor based systemss are unreliable,
> vulnerable, and dedicated designs are not. I was wrong when I thought that
> it was the other way; its back to the drawing board and soldering iron to
> get it right.

I don't think that modulation has anything to do with comms security.
Modulation standards change (at least for radio channels) so that the
available bandwidth can be used more effectively in cost and speed terms. I
mean, what specific modulation algorithm can a micriprocessor-based modem do
that cannot be simulated by software in a standard PC? Sure speed is a
factor, but no one can rely on the secrecy of the modulation scheme (which
is not key-specific in most cases) or the channel speed to ensure that no
eavesdropper monitors the traffic. Of course special-purpose modulation can
make the cracking work harder but it's no way comparable to encryption or
authentication.






------------------------------

From: [EMAIL PROTECTED]
Subject: Re: How do boomerang attacks work?
Date: Sun, 27 May 2001 14:43:10 -0800

John Savard wrote:
 
[snip]
> 
> My web page at
> 
> http://home.ecn.ab.ca/~jsavard/crypto/co041001.htm
> 
> explains the boomerang attack, I hope simply and understandably, if I
> may toot my own horn.
[snip]
 
> John Savard
> http://home.ecn.ab.ca/~jsavard/

That made it easy to understand.

Is this summary correct? 

1.) Encrypt two plaintexts that differ by "d1" based on the known
characteristic
for the first half of the cipher. The results of the first half of the
encryption
differ by "c1".
2.) XOR the results of both full encryptions with the characteristic
"d2" for the second
half of the cipher.
3.) Fully decrypt both results of step 2.
4.) If the results of step 3 have the same difference as the two
plaintexts
in step 1, then the assumptions about the key are true.

This works because step 2 essentially causes each result of the first
half of
the encryption to be XOR'ed by "c2" provided that the assumption about
the key is true.
XOR'ing both results by "c2" means that they still differ by "c1" so the
full decryptions differ by "d1".

Perhaps you could provide a similar description of the slide attack
(also by Mr. Wagner)?

Thanks.

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: 2,2-multipermutation?
Date: Mon, 28 May 2001 02:50:08 +0200



Tom St Denis wrote:
> 
> Does the following pseudocode define a 2,1 Multipermutation?  
[snip]

Would you please give a reference where the term
'multipermutation' occurs or is defined? 

M. K. Shen

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: How do boomerang attacks work?
Date: Mon, 28 May 2001 00:58:59 GMT

[EMAIL PROTECTED] wrote:
> 
> John Savard wrote:
> 
> [snip]
> >
> > My web page at
> >
> > http://home.ecn.ab.ca/~jsavard/crypto/co041001.htm
> >
> > explains the boomerang attack, I hope simply and understandably, if I
> > may toot my own horn.
> [snip]
> 
> > John Savard
> > http://home.ecn.ab.ca/~jsavard/
> 
> That made it easy to understand.
> 
> Is this summary correct?
> 
> 1.) Encrypt two plaintexts that differ by "d1" based on the known
> characteristic
> for the first half of the cipher. The results of the first half of the
> encryption
> differ by "c1".
> 2.) XOR the results of both full encryptions with the characteristic
> "d2" for the second
> half of the cipher.
> 3.) Fully decrypt both results of step 2.
> 4.) If the results of step 3 have the same difference as the two
> plaintexts
> in step 1, then the assumptions about the key are true.
> 
> This works because step 2 essentially causes each result of the first
> half of
> the encryption to be XOR'ed by "c2" provided that the assumption about
> the key is true.
> XOR'ing both results by "c2" means that they still differ by "c1" so the
> full decryptions differ by "d1".
> 
> Perhaps you could provide a similar description of the slide attack
> (also by Mr. Wagner)?

If I am not mistaken the Slide Attack is a birthday paradox based attack
where you try to find two pairs of texts that are slightly out of
phase... i.e 

P   Q
R1  --
R2  R1
R3  R2
R4  R3
--  R4
P'  Q'

That way you know the input to R4 to form Q' was.  Many feistels will
fall if you know the input and output (if the round function is a
bijection that is).

The chances of getting this is about 2^(n/2) randomly.  So against say
DES with 1 round key this requires 2^32 texts and trivial time.

Tom

------------------------------

From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Mon, 28 May 2001 02:21:38 +0000 (UTC)

Jim Steuert  wrote:
>   a) Use at least one more key part, and blend it in. The attack is thus
>       on    =>(xor k1)=>H=>(xor k2)=>J=>(xor k3)=>K=>(xor k4)=>

Assuming that H,J,K have no exploitable structure, and k1,k2,k3,k4
each are 32 bits of independent key material, I can't immediately
see any attacks with less than 2^64 complexity.  (Guess k1,k2 and
work forwards; guess k4,k3 and work backwards; and meet in the middle:
this requires 2^64 work, since k1,k2 contain 64 bits of key.)

>    b) Re-use the parts of the key at the various stages, [...]

Ahh, yes.  This is known as a key schedule.

>While the original specification of my cipher was flawed, is there
>anything fundamentally wrong with the methodology or recipe, given those
>(important) fixes, to generate a reasonable cipher?

I don't know how to answer this question.  I'm not sure whether
it even has a meaningful answer as posed.

I suspect you'll have to be much more precise about your methodology,
your definition of how you choose a key schedule, how you choose an
"invertible hash", and so on, before one can something useful about
the methodology in the aggregate.  Otherwise, the only meaningful
answer is likely to be the trivial one: "there exist instances of
ciphers that appear to follow the methodology but are insecure".

Nor am I convinced yet that there is a "recipe" for building secure
block ciphers, at your level of generality.

In general, we do not have even a single useful block cipher that
is provably secure at all (let alone "recipes" for entire families of
secure ciphers), and there are strong reasons to believe that designing
a provably secure block cipher is not an easy task.

------------------------------

From: "Niels Ferguson" <[EMAIL PROTECTED]>
Subject: Re: 2,2-multipermutation?
Date: Mon, 28 May 2001 04:28:13 +0200


"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:GpfQ6.58257$[EMAIL PROTECTED]...
> To get away from politics for a bit...
>
> Does the following pseudocode define a 2,1 Multipermutation?  (a,b) forms
> the input
>
> 1.  a = a xor b
> 2.  a = S[a]
> 3.  b = b xor a
> 4.  b = S[b]
>
> Where S is some bijection.  assume for no entries in S does S[a xor b] xor
b
> equal zero (i.e not linear enough).

This restriction on S does not make much sense. Wlog, suppose S[p] = q.
Then we can choose b:=q and a:= p xor q, and we have S[ a xor b ] xor b = 0.
In other words, S[a xor b] = b will always happen for some pairs (a,b).

Your function is not a multipermutation. Look at the 'b' output, which is
defined by
Fb( a, b ) = S[ b xor S[ a xor b ] ]
The final S does not change the permuation property, so we can look at
Fb'( a, b ) = b xor S[ a xor b ]

In general this will not be a permutation. It would be if you construct S
such
that the differentials of the form x -> x all have probability zero.

Cheers!

Niels






------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Stream Cipher combiners
Date: Mon, 28 May 2001 02:27:26 GMT

A while back someone suggested looking into diff combiners (other than
xor) for stream ciphers.

Why not consider my original decorrelated system?

Ie generate two bytes A and B (A is a element  of Z*/257 and B is an
element of Z257) and simply do

C = A(P+B) mod 257

P = C/A - B mod 257

The only attack I can see is forcing P to zero to get AB.  In this case
we will know whenever B is zero since A cannot be zero.  If we change it
such that both A and B are elements of Z*/257 we will never get zero and
the result is perfectly decorrelated.

You could do the inversion via lookup such that encoding or decoding
will take about the same amount of time.

This has the benefit that from a pure algebra sense no information is
leaked about the internal state of the cipher.  

Wait... another attack... in C=... we know what P is if P+B=0 mod 257. 
Oh foo...

The only fix I can see is to use

C = X1(P+X2) + X3 mod 257

That way if P=-X2 mod 257 we still get X3 in the mix so we are not sure.

Arrg... perhaps this is not a good idea... (yes I am cryptanalyzing this
as I type btw).

Any other comments?  It doesn't seem like this is a super good idea so
far..

Tom

------------------------------

From: Crypto Neophyte <[EMAIL PROTECTED]>
Subject: Re: Euroean commision will recommend all citizens to use encryption in email 
next week, because of echelon.
Date: Mon, 28 May 2001 02:33:47 GMT

On Sun, 27 May 2001 16:31:16 +0000, John Savard wrote
(in message <[EMAIL PROTECTED]>):

> On Sun, 27 May 2001 13:22:56 GMT, [EMAIL PROTECTED] (Jan
> Panteltje) wrote, in part:
> 
>> It seems Echelon is used by the US and GB for industrial espionage,
>> I suppose they (the commision) thinks that by everyone encrypting their
>> email Echelon will become rather useles.
> 
> And yet there was a recent news item that said Holland was planning to
> follow the same path as Britain with its R.I.P. bill.
> 
> John Savard
> http://home.ecn.ab.ca/~jsavard/frhome.htm

These are not mutually exclusive. My understanding of the RIP bill is that 
users are required to give up the passwords on demand, they can still use 
encryption.
HKRIS


------------------------------

From: [EMAIL PROTECTED]
Subject: Re: How do boomerang attacks work?
Date: Sun, 27 May 2001 17:49:33 -0800

Tom St Denis wrote:


> If I am not mistaken the Slide Attack is a birthday paradox based attack
> where you try to find two pairs of texts that are slightly out of
> phase... i.e
> 
> P   Q
> R1  --
> R2  R1
> R3  R2
> R4  R3
> --  R4
> P'  Q'
> 
> That way you know the input to R4 to form Q' was.  Many feistels will
> fall if you know the input and output (if the round function is a
> bijection that is).
> 
> The chances of getting this is about 2^(n/2) randomly.  So against say
> DES with 1 round key this requires 2^32 texts and trivial time.
> 
> Tom

I'm working through the "Slide Attacks" paper by Biryukov & Wagner.
If I'm interpreting the discussion on page 3 correctly, the "fixed
secret key" means the same sub-key is used on all rounds. Is this
correct? Then in the 2K-DES example on page 6, only two sub-keys
are used. I'm still trying to get a handle on how the method is
applied to sub-keys that are related but different. Does a good key
schedule
defeat this attack? 

Oops. We're getting off the original topic of boomerang attacks. Oh
well...

------------------------------

Date: Mon, 28 May 2001 12:47:25 +1000
From: Sam <[EMAIL PROTECTED]>
Subject: Re: Help with 'P' in PKCS1V2.1 RSAES-OAEP

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Thanks for your reply David,
<p>I understand as per Victor shoup research paper you mentioned
<br>4.1 Random encoding&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
E=f(m,r)^e mod n
<p>where m is messege and r is random bits not a part of&nbsp; plaintext.
Is this r what you meant by ID of algorithm, or ID of the algorithm (e.g.
SHA-1) has to be a part of encoding parameter r.
<p>Where can I get some specific example of this ID of algorithm(SHA-1,
256 or 512) and encoding parameters.
<p>If somebody has got it
<p>I will appreciate any kind of help with any example to visualize.
<p>Thanks in advance
<p>Sam
<p>David Hopwood wrote:
<blockquote TYPE=CITE>-----BEGIN PGP SIGNED MESSAGE-----
<p>Sam wrote:
<br>> Could somebody please tell me how to determine P required for
<br>>
<br>> PKCS1v2.1 RSAES-OAEP 9.1.1.1 Encoding operation
<br>>
<br>> DB=pHash||PS||01||M
<p>P is the encoding parameters. The purpose of encoding parameters is
to
<br>associate some information with this encryption, in such a way that
the
<br>combination of the encoding parameters and plaintext is non-malleable
<br>(see [1] if you're not familiar with the concept of non-malleability).
<p>For example, suppose that you're using OAEP to encrypt cipher and MAC
keys
<br>in a hybrid system. The interpretation of the RSA-OAEP plaintext then
depends
<br>on which cipher and MAC algorithms are used, but the choice of those
algorithms
<br>is not secret (and it may be undesirable to encrypt them, depending
on
<br>the protocol). So, you could put an ID for those algorithms in the
encoding
<br>parameters. That would prevent some types of attack based on trying
to
<br>convince the receiver to use a different cipher or MAC than intended.
<br>More generally, anything that is variable and affects the interpretation
<br>of the plaintext, but is not part of the plaintext itself, is a candidate
<br>for inclusion in the encoding parameters.
<p>If you don't need encoding parameters, P can be the zero-length octet
string.
<p>[1] Victor Shoup,
<br>&nbsp;&nbsp;&nbsp; "Why Chosen Ciphertext Security Matters,"
<br>&nbsp;&nbsp;&nbsp; Research Report RZ 3076 (#93122), IBM Research,
November 1998.
<br>&nbsp;&nbsp;&nbsp; <a 
href="http://citeseer.nj.nec.com/shoup98why.html";>http://citeseer.nj.nec.com/shoup98why.html</a>
<p>- --
<br>David Hopwood &lt;[EMAIL PROTECTED]>
<p>Home page &amp; PGP public key: <a 
href="http://www.users.zetnet.co.uk/hopwood/";>http://www.users.zetnet.co.uk/hopwood/</a>
<br>RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5&nbsp; 0F 69 8C D4
FA 66 15 01
<br>Nothing in this message is intended to be legally binding. If I revoke
a
<br>public key but refuse to specify why, it is because the private key
has been
<br>seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
<p>-----BEGIN PGP SIGNATURE-----
<br>Version: 2.6.3i
<br>Charset: noconv
<p>iQEVAwUBOxEGOzkCAxeYt5gVAQEdpAgAhspdMj2nAueL8pCu5hpK69Gidk99j4mI
<br>DkfPYrNVVoScF4tjkjFOxpLws5PE+Lyow1CcCD25HV6hu+DfzYIGL7yicPUEl3Sz
<br>BLEeb+2Na0tBzXavgztgeaBqOGzpaDEBgs9aew29wLRomg7tFoz3ZKoX4ybK3Nyn
<br>8CDq6PqZ8ulaZaG3ZX6Lzi4cIIM4m7PvQLTh/SSa20tDMWnXfEcqpufzx7L9IdnX
<br>PI4QXUtYIl5Nzkc1mOxGrsgLZejEVawuIOGZrQjetY2s5vngD8+2/3mQ94AFuebm
<br>Hcmi8av8YJYrqNUuxkv9z/6WIfvfcATI0VNdj8w1KptQfKHbDLZrQw==
<br>=9KFf
<br>-----END PGP SIGNATURE-----</blockquote>
</html>


------------------------------

From: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Mon, 28 May 2001 01:52:02 GMT

"Harris Georgiou" <[EMAIL PROTECTED]> wrote in message
news:9es1cg$117j$[EMAIL PROTECTED]...
> The fact that 128-bit ciphers where selected as minimum standard was what
I
> expected, but to my surprise too only 1024-bit keys where proposed for
> asymmetric crypto and digital signatures/authentication. I guess I has to
do
> with hardware requirements (mostly on hardware devices), although no
> signifficant difference in speed would emerge for any standard personal
> computer.

Personally, I'd be quite happy with 56-bit ciphers and 512-bit PK keys
if the various other privacy leaks were plugged. The real medical privacy
threats have almost nothing to do with crypto.




------------------------------


** 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
******************************

Reply via email to