Cryptography-Digest Digest #558

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #558, Volume #14   Thu, 7 Jun 01 21:13:01 EDT

Contents:
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
  Re: Simple C crypto ("Dirk Bruere")
  Re: Notion of perfect secrecy ("Jeffrey Walton")
  Re: Notion of perfect secrecy ("Boyd Roberts")
  Re: Simple C crypto ("Tom St Denis")
  Re: Notion of perfect secrecy (John Savard)
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes 
(David Wagner)
  Re: PRP => PRF (TRUNCATE) (David Wagner)
  Re: Any Informed Opinions? ("Jeffrey Walton")
  Re: Medical data confidentiality on network comms (David Wagner)
  Re: PRP => PRF (TRUNCATE) ("Tom St Denis")
  Re: Some questions on GSM and 3G (David Wagner)
  Re: Simple C crypto ("Dirk Bruere")
  Re: DES not a group proof (David Wagner)
  Re: MD5 for random number generation? (David Wagner)
  Re: CBC variant (David Wagner)
  Re: DES not a group proof ("Patrick Aland")
  Re: Simple C crypto ("Joseph Ashwood")
  Re: Alice and Bob Speak MooJoo ("Robert J. Kolker")



From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 22:27:12 GMT


"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (JPeschel) wrote in
> <[EMAIL PROTECTED]>:
>
> >Tim Tyler [EMAIL PROTECTED] writes, in part:
> >
> >>If you nitpick the examples without actually attacking the basic point,
> >>we will only find other ones.
> >>
> >
> >Tim, "we" appears to only you and maybe Dave.  :-)
> >
> >You posted an example where you thought it was obvious that a
> >two-character encrypted response meant "no," and three letters meant
> >"yes." I pointed out that it isn't neccesarily so. You might as well
> >flip a coin.
> >
>
>   Off hand I would say you have not seen many proofs or tests of
> theorms. You don't understand that it perfectly valid to define
> a system that contains 2 messages 'YES" and "NO". To reject it
> saying you want to do somthing else is irrelivent. I gave a model
> and showed "zero security". I don't care if you have other models
> since it only takes one failure to prove something is wrong.

By your logic RSA is an insecure system completely since it is possible to
make and use 32-bit primes.

Just because you mis-used an OTP doesn't make the OTP non-secure.

Typically if your situation calls for a boolean you dont send the ascii
"YES" or ascii "NO".

If you had a three letter call code you would use 3 ascii bytes.

Tom



--

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 22:29:33 GMT


"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> :> : Perhaps if you defined your threat model this would make sense.  Why
in
> :> : your world is knowing the length of the message a threat?
> :>
> :> See David's "Yes"/"No" example.
>
> : What 1/0? [...]
>
> No.  Where the attacker has a priori knowledge that the message is going
> to be either "yes" or "no" - but doesn't know which.

That's just a contrived example of how to not use an OTP.  Obviously in this
case the two messages are vastly different.

If your system calls for sending booleans send bits not ASCII words.

I mean seriously, outside of a contrived example an OTP is perfectly secure.

By this logic RSA is insecure because a naive user can make 32-bit primes,
or RC6 is insecure because you can supply 16-bit keys, or CTR mode is
insecure because you could have "THEANSWERISYES" and "NO" as texts, or BICOM
is insecure because the user could just forget to supply a key at all...
or...

Making contrived ways to break something is not only pointless but futile.
It proves nothing.

Tom



--

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Fri, 08 Jun 2001 00:26:38 +0200



"SCOTT19U.ZIP_GUY" wrote:
> 
> [EMAIL PROTECTED] (Mok-Kong Shen) wrote in <3B1FBAF6.1DD02E47@t-
> online.de>:
> 
> >
> >
> >"SCOTT19U.ZIP_GUY" wrote:
> >>
> >> [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
> >>
> >> >Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >> snap...
> >>
> >> >To see how a particular 8 bit cyphertext could map to more than 256
> >> >different plaintexts, just get an 8 bit cyphertext, decrypt it with
> >> >BICOM under a number of keys.
> >> >
> >> >You will see *many* different plaintexts come out - not just 256.
> >>
> >>   Mok likes to 

Cryptography-Digest Digest #559

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #559, Volume #14   Thu, 7 Jun 01 23:13:01 EDT

Contents:
  Re: Simple C crypto ("Tom St Denis")
  Re: Alice and Bob Speak MooJoo ("Robert J. Kolker")
  Re: Alice and Bob Speak MooJoo ("Tom St Denis")
  Re: Brute-forcing RC4 ("Scott Fluhrer")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: Brute-forcing RC4 ("Tom St Denis")
  Re: Simple C crypto ("Boyd Roberts")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: CBC variant ("Scott Fluhrer")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Brute-forcing RC4 ("Scott Fluhrer")
  Re: Brute-forcing RC4 ("Tom St Denis")
  Re: Alice and Bob Speak MooJoo ("Robert J. Kolker")
  Re: Simple C crypto ("Dirk Bruere")
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes 
(sisi jojo)
  Re: Simple C crypto ("Dirk Bruere")
  Re: Brute-forcing RC4 ("Scott Fluhrer")
  Re: Simple C crypto ("Tom St Denis")
  Re: Any Informed Opinions? ("Dirk Bruere")
  Re: Simple C crypto ("Dirk Bruere")
  Re: Simple C crypto ("Tom St Denis")



From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Fri, 08 Jun 2001 00:56:36 GMT


"Dirk Bruere" <[EMAIL PROTECTED]> wrote in message
news:6OUT6.19530$[EMAIL PROTECTED]...
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:xITT6.52725$[EMAIL PROTECTED]...
> >
> > > The requirement is for text comments (for example) to be written to a
> file
> > > along with data. We simply don't want people to get into the file to
> read
> > > and/or alter the text. We're not talking about professional hackers or
> the
> > > NSA, just (say) lab technicians who use the equipment. Detecting
> > alteration
> > > of the text is something else.
>
> > > So, no freeware solution to such a simple problem?
>
> > There are tons of public domain crypto tools (tools = algorithms).
> Whether
> > your a competent enough cryptographer to use them is another question.
>
> I don't have to be a competent crypographer if someone else has done the
> work.
> I use other peoples programs to do jobs so I don't have to write them
> myself, or even know how they work. Am I supposed to be able to code .jpg
> before I can embed a picture viewer?

There is more to crypto then just using a cipher.  just like there is more
to a codec then a library to output jpg.  However, unlike outputting a jpg,
errors in crypto can be more than just annoying.  They can be fatal errors.

For example, if you default to 0.99 quality in your JPG library that's
annoying.  If you default to 16-bit symmetric keys that's useless!

> > Also if your application that you distribute can read these "magically
> > encoded files" then so can anyone else.  This is a re-hash of the
> > CSS/SDMI/etc designs.  Here's a tip, they don't work.
>
> The files are output from a data logger, we just don't want people
casually
> changing the data.
>
> I rather doubt the ability and motivation of normal users to reverse
> engineer the application to determine the crypo method in order to change
> the comments in a file. If they are that keen then they will have faked
the
> whole thing from start to finish. The algorithm is not in a file viewer
they
> will have access to, unless, of course, they do that reverse engineering.
> They can encode a comment (if it is theirs), but not decode anything.
>
> All I am looking for is something that will require a few hours of work by
a
> competent engineer with the right tools to break. That is the level of
> deterrence required.

The problem with this (as many and espesicially Schneier have pointed out)
is that it only takes ONE person to break your program ONCE.  Then it's all
down hill.  Who cares if it takes them 3 days.  Once they complete the task
ONCE they will FOREVER.

> > If you application is based on secrets like passwords or what have not
> just
> > use a cipher like Blowfish in CTR mode to encode the files.  Alterations
> > will show up in the plaintext but if you need more assurance append a
hash
> > of the pre-image to the plaintext.  That should stop all attacks on "the
> > math".  At that point it's upto physical and password security.
>
> Done a search on Blowfish, but could not find any code. If its more than
> about 100 lines of C then I'm not interested. I just need a key of length
N,
> and two functions
>
> #include "encryption.h"
> CString Encrypt( Cstring )
> CString Decrypt( Cstring )
>
> something as simple as that to drop into existing code.

Then don't ask here.  If you are not willing to do the job right why are you
asking others for help?

Tom



--

From: "Robert J. Kolker" <[EMAIL PROTECTED]>
Subject: Re: Alice and Bob Speak MooJoo
Date: Thu, 07 Jun 2001 20:58:33 -0400



Joseph Ashwood wrote:

> required a few years. To prove this consider the f

Cryptography-Digest Digest #555

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #555, Volume #14   Thu, 7 Jun 01 17:13:00 EDT

Contents:
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (John Myre)
  Re: Notion of perfect secrecy (Tim Tyler)
  Re: better yet, perfect secrecy => who cares? (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: better yet, perfect secrecy => who cares? ("Tom St Denis")
  Simple C crypto ("Dirk Bruere")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Alice and Bob Speak MooJoo ("Robert J. Kolker")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")



From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 7 Jun 2001 19:49:37 GMT

[EMAIL PROTECTED] (John A. Malley) wrote in 
<[EMAIL PROTECTED]>:

>
>Tim Tyler wrote:
>> 
>
>> 
>> : You probably question whether such usage leads to
>> : Shannon's perfect security which, as you said, is claimed
>> : to be a property of OTP. However, I don't see where in the
>> : literature about OTP (in connection with perfect security)
>> : the length enters into the argumentation, i.e. plays a role
>> : in the proof.
>
>Shannon's paper "Communications Theory of Secrecy Systems" addresses
>this. Perfect secrecy is a property of the OTP (i.e. the Vernam cipher
>specifically cited in that paper) AND message length DOES enter into the
>argument. However, using an OTP is NOT required for perfect secrecy when
>the set of messages is finite.  :-)
>
>> 
>> I also think that it's not mentioned.  I beleive it is common to
>> consider the domain where all plaintexts are the same length -
>> perhaps in order to get the "perfect secrecy" result.
>> 
>> : My memory of Shannon's paper is no good, but I don't think that he
>> : considered the length of the messages.
>> 
>> I don't think it was mentioned either - all the messages were the same
>> length in the system in question.
>> --
>
>Shannon's important paper on cipher systems carefully considers the
>length of the messages. Shannon shows the OTP is NOT required for a
>finite set of messages to give perfect secrecy. (I've posted on this
>before, given examples of such ciphers, just search google or drop me a
>note by email for more specific examples. :-) )
>
>The OTP is required for message sources with an infinite number of
>messages.  From page 682 of  "Communications Theory of Secrecy Systems",
>C. E. Shannon, Bell System Technical Journal, pp. 656-715, 1949:
>
>"The situation [perfect secrecy] is somewhat more complicated if the
>number of messages is infinite. Suppose, for example, that they are
>generated as infinite sequences of letters by a suitable Markov process.

  UNforutunutely your missed most of the paper. We are taking about
the simple system where you have a fintie number of messaages. Of
versus lengths. And since for perfect security you can't have more
than one residue class. If one used an OTP that only encrypts to the
end of the message actaully sent. You have imediatly form a series
of different residue classes based on input message length. THerefore
usuing it that way would not be "perfect security".

  Try taking another look.

David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
 made in the above text. For all I know I might be drugged or
 something..
 No I'm not paranoid. You all think I'm paranoid, don't you!


--

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 14:01:18 -0600

Tim Tyler wrote:

> I see.  You think you know better how to explain how Matt Timmermans
> compressor operates than Matt Timmermans himself.


Wh

Cryptography-Digest Digest #556

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #556, Volume #14   Thu, 7 Jun 01 18:13:01 EDT

Contents:
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: MD5 for random number generation? (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (JPeschel)
  Re: Brute-forcing RC4 ("Joseph Ashwood")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (JPeschel)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Brute-forcing RC4 (Ichinin)
  Any Informed Opinions? ("Robert J. Kolker")
  Re: Alice and Bob Speak MooJoo (Ichinin)
  Re: MD5 for random number generation? ("Tom St Denis")
  Re: Alice and Bob Speak MooJoo ("Robert J. Kolker")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")



Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 07 Jun 2001 16:48:45 -0400

Tim Tyler <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] wrote:
>: Tim Tyler <[EMAIL PROTECTED]> writes:
>:
>:> My claim is that the chances of collisions are generally greater if
>:> compression has been employed than if not.
>:
>: You are wrong to say ``generally greater''; you have not proven that
>: they actually are greater. You can only say they are ``no less''.
> 
> ...the net effect is that they will be more frequent.

You don't have any idea what the net effect will be. In fact, I gave a
fairly thorough explanation why the net effect is almost certainly no
such thing. You need to *prove* that the ``net effect'' will be what
you say.

> If you have a fishtank and all the fish swim towards one end, the
> chances of finding fish at that end will be generally greater.
> Sometimes if you look by the castle you will find greater, fewer or
> an equal number of fish in its neighbourhood - but *on average* the
> density of fish at that end of the tank will be greater.
> The fish are plausible plaintexts.  The tank represents files
> sorted by size.  Files at the end of the tank are shorter than ones
> further away.  The directional swimming of the fish represents
> compression.

GLORY, GLORY HALELUJAH! NOW I GET IT! Please, please, write this up and
submit it to the Acta Mathematica, will you? You must be Isaac Newton
reborn!

Question: If there are 50 billion billion eels, and 2000 guppies, and
they all start in one end of the tank--which is 45,000 light-years long,
when can I expect to catch a guppy at the far end of the tank?

Translation: You keep using words like ``some'' or ``a lot'' or
``greater than'' or ``better'' without any attempt whatsoever to
verify that the hypothetical ``improvement'' will *ever* affect an
attacker.

> Did you miss my 129 bit message?

If that's not the only message you send, then we're NOT dealing with
only 129 bits; we're dealing with all the bits you encrypted with that
key. On the other hand, if you DID send only 129 bits with a 128-bit
key, and then throw the key away--but DIDN'T use a one-time pad, then
you're an idiot.

>: Bottom line: ``All BICOM gives you, assuming its correctness, is an
>: increase in the work required to brute-force the key.''
> 
> If that's your bottom line then I have to say your panties are showing.

Didn't you used to date Ludwig Plutonium?

Len.


-- 
Performance speculation is bad. Performance hypocrisy is much worse.
-- Dan Bernstein

--

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 20:44:35 GMT

John Myre <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:

:> I see.  You think you know better how to explain how Matt Timmermans
:> compressor operates than Matt Timmermans himself.

: Where does that come from?

http://www3.sympatico.ca/mtimmerm/bicom/bicom.html

: On the whole, Len's posts are more convincing to me than
: yours are. [...]

Well, this isn't a popularity contest - this is a scientific forum.

Is there anything specific you don't agree with?

: He may be wrong, but he's not an idiot. [...]

I don't believe I've called him an idiot to date.

He has some technical knowledge - but he has now made rather a lot of
mistakes.  Entropy, perfect secrecy, compression - he seems to have an
innacurate view about everything :-|

The posts of his that /really/ rub me up the wrong way are the ones where

Cryptography-Digest Digest #557

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #557, Volume #14   Thu, 7 Jun 01 19:13:01 EDT

Contents:
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Notion of perfect secrecy (SCOTT19U.ZIP_GUY)
  Re: Notion of perfect secrecy ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (JPeschel)
  Re: Def'n of bijection ("Henrick Hellström")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: about DH parameters & germain primes (Anton Stiglic)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (JPeschel)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: shifts are slow? ("Joseph Ashwood")
  Re: Alice and Bob Speak MooJoo ("Joseph Ashwood")
  Re: Simple C crypto ("Joseph Ashwood")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")



From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 21:27:56 GMT

[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:> [EMAIL PROTECTED] wrote:
:>: Tim Tyler <[EMAIL PROTECTED]> writes:

:>:> My claim is that the chances of collisions are generally greater if
:>:> compression has been employed than if not.
:>:
:>: You are wrong to say ``generally greater''; you have not proven that
:>: they actually are greater. You can only say they are ``no less''.
:> 
:> ...the net effect is that they will be more frequent.

: You don't have any idea what the net effect will be.

So you falsely claim.

:> If you have a fishtank and all the fish swim towards one end, the
:> chances of finding fish at that end will be generally greater.
:>
:> Sometimes if you look by the castle you will find greater, fewer or
:> an equal number of fish in its neighbourhood - but *on average* the
:> density of fish at that end of the tank will be greater.
:>
:> The fish are plausible plaintexts.  The tank represents files
:> sorted by size.  Files at the end of the tank are shorter than ones
:> further away.  The directional swimming of the fish represents
:> compression.

: GLORY, GLORY HALELUJAH! NOW I GET IT! Please, please, write this up and
: submit it to the Acta Mathematica, will you? You must be Isaac Newton
: reborn!

I assume you didn't understand :-(

I figure that makes you a lost cause.  If you didn't understand that
simplified explanation, there's really not much hope of you ever
grasping it.

:> Did you miss my 129 bit message?

: If that's not the only message you send, then we're NOT dealing with
: only 129 bits; we're dealing with all the bits you encrypted with that
: key.

No - not if there are multiple messages and key per message.

: On the other hand, if you DID send only 129 bits with a 128-bit
: key, and then throw the key away--but DIDN'T use a one-time pad, then
: you're an idiot.

How so?

Say I have a cyphermachine that already uses BICOM.

You're telling me I should scrap that, build a new machine, send copies of
it to everyone who I want to communicate with - all just for sending short
messages with?

Wouldn't that represent a lot of rather pointless work?

How many cyphersystems are you familiar with that use a conventional
cypher for long messages and an OTP for short ones?

...

A 256 bit message might have very few collisions with a 128 bit key.
It /might/ even encrypt to a unique plaintext.

On the other hand a 129-bit message will yield a cyphertext
will decrypt to (almost) every *possible* message - a set that
may well include a very large number of plausible-looking messages.

This is a concrete case where compression would often increase
the density of plausible-looking decrypts by orders of magnitude.
-- 
__
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

--

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Notion of perfect secrecy
Date: 7 Jun 2001 21:32:03 GMT

[EMAIL PROTECTED] (Tom St Denis) wrote in
: 

>
>"Tim Tyler" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]... 
>> Tom St Denis <[EMAIL PROTECTED]> wrote:
>> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
>> : news:[EMAIL PROTECTED]... 
>> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
>>
>> :> : Typically the MEANING of the message is not stored in the length.
>>
>> :> Shannon refers to *any* information about the identity of the
>plaintext.
>> :>
>> :> For perfect secrecy, observation of the cyphertext should make no
>> :> difference to the attacker.
>> :>
>

Cryptography-Digest Digest #554

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #554, Volume #14   Thu, 7 Jun 01 16:13:00 EDT

Contents:
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: shifts are slow? (Bob Jenkins)
  Re: Alice and Bob Speak MooJoo ([EMAIL PROTECTED])
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: shifts are slow? ([EMAIL PROTECTED])
  Re: MD5 for random number generation? (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: MD5 for random number generation? ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Alice and Bob Speak MooJoo (Janne Tuukkanen)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: RSA's new Factoring Challenges: $200,000 prize. (my be repeat) ("Joseph Ashwood")
  new NSA/echelon rant (V.Z. Nuri)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (JPeschel)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)



From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 18:54:57 GMT

Tom St Denis <[EMAIL PROTECTED]> wrote:

: I fail to see how knowing the length of the plaintext reveals any
: information contained within the plaintext.

It lets you rule out plaintexts that were previously possible, and
give them a probability of zero.

Shannon states that for perfect secrecy the cyphertext must not
give *any* clues to the plaintext.

Not "no clues apart from the length", but "no clues at all".

: You fail to solve even the most trivial of examples I pose.

Hardly suprising is it?  I told you that it was obvious to everyone that
such examples were impossible to solve uniquely.  Why do you not tire of
repeatedly presenting them?
-- 
__
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

--

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 18:57:10 GMT

[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:

:> OK - so can you identify one bit in that stream which is *not*
:> significant?

: Everything after the final ``1''.

Which bit is that?  You don't know where the final "1" is, if you ignore
some of the bits, now do you?  So all bits *are* significant.
-- 
__
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

--

Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 07 Jun 2001 15:06:16 -0400

"Tom St Denis" <[EMAIL PROTECTED]> writes:
> <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>> Tim Tyler <[EMAIL PROTECTED]> writes:
>>>
>>> Those points indicate that the chance of getting a false positive in the
>>> system you describe are small.
>>
>> As in, ``you're better off waiting for the sun to burn out and the
>> universe to collapse, than waiting for false positives.'' Yes, correct;
>> I guess you could call that ``small''.
> 
> You're wrong too.  In an OTP like system, it's not that guessing the
> message is hard or improbable.  It's that it's IMPOSSIBLE.

Don't lose track Tom--I wasn't talking about OTP.

I offered a reasonable (though extremely ballpark) estimate of the
likelihood of plausible (or ``false positive'') decryptions when no
compression is used. I then suggested approximately HOW MUCH MORE common
BICOM would have to make the plausible files before it actually translates
into false positive decryptions more often than, say, having our sun
burn out.

The estimate (1) gives strong reasons to doubt that BICOM has *any*
practical benefit, apart from making decryption take a little longer
(and the usual benefits of compression), and (2) gives Tim T. some
idea what he would have to prove, in order to substantiate his claims
for BICOM. ``It's obvious, because there are just lots and lots
of...''  doesn't actually mean diddly.

Are we all together now?

Len.


-- 
The ``attack'' that Warfield mentions was not a qmail problem; it was
a fraudulent marketing stunt by the Postfix author.
-- Dan Bernstein

--

From: [EMAIL PROTECTED] (Bob Jenkins)
Subject: Re: shifts are slow?
Date: 7 Jun 2001 12:11:00 -0700

Jeffrey Williams <[EMAIL PROTECTED]> wrote in message 
news:<[EMAIL PROTECTED]>...

> Realistically, given the spee

Cryptography-Digest Digest #553

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #553, Volume #14   Thu, 7 Jun 01 15:13:00 EDT

Contents:
  Re: Notion of perfect secrecy (Tim Tyler)
  Re: Notion of perfect secrecy (Tim Tyler)
  Re: CBC variant (John Savard)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Alice and Bob Speak MooJoo ("Robert J. Kolker")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Notion of perfect secrecy ("Paul Pires")
  Re: CBC variant (John Savard)
  Re: Knapsack security??? Ahhuh (John Bailey)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Notion of perfect secrecy ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  better yet, perfect secrecy => who cares? ("Tom St Denis")



From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Notion of perfect secrecy
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 18:05:56 GMT

Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> :> Tom St Denis <[EMAIL PROTECTED]> wrote:

:> : In his model WHO, WHEN, LENGTH were not the information he wanted to
:> protect.
:>
:> "Who" and "when" are not modelled by Shannon.  However length /is/
:> information that relates to the identity of the plaintext
:> (except in the case where all possible plaintexts are the same length)
:> and *is* covered by Shannon's definition of perfect secrecy.

: No they are not.

Yes it is - read Shannon's definition of perfect secrecy.

: When will you realize that the contents of the message are
: what an OTP protects.  So if the contents are random than an OTP is
: perfectly secure.

An OTP doesn't have perfect secrecy - the cyphertext leaks information
about the length of the plaintext.

If you don't believe me, just read the definition of perfect secrecy.

:> : You're really mocking the dead here.  I sincerely hope you are some
:> : 12yr kid trying to get a rise out of people, otherwise I wonder how you
:> : did in College challenging all your profs without listening to their
:> : proofs... No offense Tim but you have a lot of growing up todo.  Even
:> : if you are 76 yrs old you're an immature brat as far as I am concerned.
:>
:> Sorry you feel that way Tom.  It seems this is the thanks I get for
:> pointing out your errors.  Maybe I won't bother in the future.

: So far it seems #[sci.crypt] vs #[scott, tim].

: I don't think it's my errors

You never do - but it almost always is.

"Unicity distance", "bijection", "ctr mode", "perfect secrecy" - it
seems to be just one thing after another these days in a long stream
of mistakes ;-/
-- 
__
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

--

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Notion of perfect secrecy
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 18:15:53 GMT

Paul Pires <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...

:> Perfect secrecy says that knowledge of the cyphertext must not allow the
:> space of possible plaintexts to be narrowed down at all.

: The space of the possible plaintexts hasn't been narrowed down
: by the application of the OTP. This narrowing is a characteristic
: of the message, not the method.

Yes indeed.

: By this logic no system could have perfect secrecy since that would
: require the method to have control over the composition of all possible
: messages before encryption.

No system can have perfect secrecy and deal with an infinite set of finite
messages.

However perfect secrecy if you are only dealing with a finite set of
messages is possible, and perfect secrecy is possible with ininite sets
of messages as well, as demonstreated in Shannon's original paper.

: Nothing is leaked that was not already plain. No compromise has occured by
: the application of the OTP. It is perfect without the constraint you
: are proposing.

That doesn't seem to make any sense.  The length of the message is leaked
to the attacker.  What are you talking about?

: This is one clear piece stable ground in a murky field. One thing you can
: know. I don't see how this complex distinction you are proposing aids
: in understanding or what it gets you from a practical sense.

I don't know what distinction you're talking about here :-|

: OTP's can leak the message length. As Tom pointed out, they also can
: leak the point in time, the relative sequence of messages, the sender
: and rec

Cryptography-Digest Digest #552

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #552, Volume #14   Thu, 7 Jun 01 14:13:00 EDT

Contents:
  Re: Notion of perfect secrecy ("Tom St Denis")
  CBC variant
  Re: Notion of perfect secrecy (Tim Tyler)
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes 
("Tom St Denis")
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes 
("Tom St Denis")
  Re: OTP WAS BROKEN!!! ("Paul Pires")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes 
([EMAIL PROTECTED])
  Re: Humor, "I Must be a Threat to National Security" (Dimitri Maziuk)
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes 
("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Medical data confidentiality on network comms (wtshaw)
  Re: Medical data confidentiality on network comms (wtshaw)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")



From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Notion of perfect secrecy
Date: Thu, 07 Jun 2001 17:11:44 GMT


"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> :> : Typically the MEANING of the message is not stored in the length.
>
> :> Shannon refers to *any* information about the identity of the
plaintext.
> :>
> :> For perfect secrecy, observation of the cyphertext should make no
> :> difference to the attacker.
> :>
> :> This is not the case if he was unaware of the length of the plaintext
> :> before observing it - and he knows that the length of the cyphertext
> :> matches that of the plaintext.
>
> : You don't understand his results that's all. [...]
>
> My understanding is fine thanks.
>
> : In his model WHO, WHEN, LENGTH were not the information he wanted to
protect.
>
> "Who" and "when" are not modelled by Shannon.  However length /is/
> information that relates to the identity of the plaintext
> (except in the case where all possible plaintexts are the same length)
> and *is* covered by Shannon's definition of perfect secrecy.

No they are not.  When will you realize that the contents of the message are
what an OTP protects.  So if the contents are random than an OTP is
perfectly secure.


> : You're really mocking the dead here.  I sincerely hope you are some
> : 12yr kid trying to get a rise out of people, otherwise I wonder how you
> : did in College challenging all your profs without listening to their
> : proofs... No offense Tim but you have a lot of growing up todo.  Even
> : if you are 76 yrs old you're an immature brat as far as I am concerned.
>
> Sorry you feel that way Tom.  It seems this is the thanks I get for
> pointing out your errors.  Maybe I won't bother in the future.

So far it seems #[sci.crypt] vs #[scott, tim].

I don't think it's my errors

> : Anyways this is all OT.
>
> You started this thread about perfect secrecy - which incidentally is not
> off topic at all.

Your rants are not on topic.

Tom



--

From: <[EMAIL PROTECTED]>
Subject: CBC variant
Date: Thu, 7 Jun 2001 13:07:09 -0400

Hi,

We know that methods used to inject feedback into a small block cipher,
such as CBC, have known-ciphertext attacks against them, like what
Vaudenay posted here.

I propose a variant of CBC that requires 2 extra block-width XORS and 1
extra encryption per block. (shown here in plain English)

(1) Cipher(block n) in CBC is E(block n XOR block n-1), so I propose an
extra step like this:

(2) XOR block n using a block constant (the constant evolves like the
round constant in TEA)*
(a) Encrypt the sum.
(b) Xor the sum onto block n-1 like a mask.

*Note that (2) and (2)(a) are discarded. (The block is not actually
double encrypted.)

As stated, this needs just two xors and one encryption (same key) in
addition to regular CBC. Can anyone find faults in it? If worth
anything, use freely ;)

Thanks,
thecode







--

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Notion of perfect secrecy
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 17:04:04 GMT

[EMAIL PROTECTED] wrote:

: *IF* I know that the message must be one of k known plaintexts, each
: having different lengths, then I can use the length to deduce which
: plaintext is being sent.

: Note further, however, that this properly belongs to traffic analysis:
: I already knew what the message said; [...]

Not according yo what you said - you said "I know that the
message

Cryptography-Digest Digest #550

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #550, Volume #14   Thu, 7 Jun 01 13:13:01 EDT

Contents:
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("John A. Malley")
  Re: Def'n of bijection ("Paul Pires")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: OTP WAS BROKEN!!! (Tim Tyler)
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and  (Phil 
Carmody)
  Re: OTP WAS BROKEN!!! ("Robert J. Kolker")
  Re: practical birthday paradox issues (Phil Carmody)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)



From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 15:09:19 GMT

[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:> [EMAIL PROTECTED] wrote:
:>: Tim Tyler <[EMAIL PROTECTED]> writes:
:>:> Tom St Denis <[EMAIL PROTECTED]> wrote:

:>:>: Or if you just pad the bloody thing to a multiple of say 64 bytes. [...]
:>:> 
:>:> Still not enough for perfect secrecy :-(
:>: 
:>: Right--no matter what ``a multiple'' means. 
:> 
:> That's correct - so long as no restraints are placed on the set of
:> possible plaintexts.

: Exactly. So why do you keep switching premises? Specifically:

: 1. When somebody says, ``OTP on padded messages gives (Tim Tyler's
:definition of) perfect secrecy,'' you reply, ``No, because no
:amount of padding is enough.'' In other words, you assume that the
:space of plaintexts is infinite.

: 2. When somebody replies, ``Okay: if the space of messages is infinite,
:then (your definition of) perfect secrecy is impossible to achieve.''
:You reply, ``No, because the space of messages is actually finite.''
:(Or alternately, ``...has cardinality 2 in my universe.'')

You dare to misquote me in the course of misrepresenting my postion.

You misquote yourself as well to distort things still further - but I
guess that's your privelidge.

We can talk again when you have learned to put quotation marks around
stuff people have actually said.
-- 
__
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

--

From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 08:18:08 -0700


Tim Tyler wrote:
> 

> 
> : You probably question whether such usage leads to
> : Shannon's perfect security which, as you said, is claimed
> : to be a property of OTP. However, I don't see where in the
> : literature about OTP (in connection with perfect security)
> : the length enters into the argumentation, i.e. plays a role
> : in the proof.

Shannon's paper "Communications Theory of Secrecy Systems" addresses
this. Perfect secrecy is a property of the OTP (i.e. the Vernam cipher
specifically cited in that paper) AND message length DOES enter into the
argument. However, using an OTP is NOT required for perfect secrecy when
the set of messages is finite.  :-)

> 
> I also think that it's not mentioned.  I beleive it is common to
> consider the domain where all plaintexts are the same length -
> perhaps in order to get the "perfect secrecy" result.
> 
> : My memory of Shannon's paper is no good, but I don't think that he
> : considered the length of the messages.
> 
> I don't think it was mentioned either - all the messages were the same
> length in the system in question.
> --

Shannon's important paper on cipher systems carefully considers the
length of the messages. Shannon shows the OTP is NOT required for a
finite set of messages to give perfect secrecy. (I've posted on this
before, given examples of such ciphers, just search google or drop me a
note by email for more specific examples. :-) )

The OTP is required for message sources with an infinite number of
messages.  From page 682 of  "Communications Theory of Secrecy Systems",
C. E. Shannon, Bell System Technical Journal, pp. 656-715, 1949:

"The situation [perfect secrecy] is somewhat more complicated if the
number of messages is infinite. Suppose, for example, that they are
generated as infinite sequences of letters by a suitable Markov process.
It is clear that no finite key will give perfect secrecy. We suppose,
then, that the key source generates key in the same manner, that is, as
an infinite sequence of symbols. Suppose further that only a certain
length of L_k is needed to encipher and decipher a length L_m of
message. Let the logarith

Cryptography-Digest Digest #551

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #551, Volume #14   Thu, 7 Jun 01 13:13:01 EDT

Contents:
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
  Re: Notion of perfect secrecy ("Paul Pires")
  Re: Notion of perfect secrecy ([EMAIL PROTECTED])
  Re: Notion of perfect secrecy (John Savard)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Humor, "I Must be a Threat to National Security" (Douglas Hurst)
  Re: shifts are slow? ("Tom St Denis")
  Re: MD5 for random number generation? ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: OTP WAS BROKEN!!! ("Paul Pires")
  Re: Humor, "I Must be a Threat to National Security" ("Chaotic")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")



Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 07 Jun 2001 12:19:24 -0400

Tim Tyler <[EMAIL PROTECTED]> writes:
> 
> OK - so can you identify one bit in that stream which is *not*
> significant?

Everything after the final ``1''. Just read what he does with those
bits: he throws them out.

Len.

-- 
The Yanomamo Indians employ only three numbers: one, two, and more
than two.  Maybe their time will come.
-- Warren Buffett, 1979

--

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 18:20:52 +0200



Tim Tyler wrote:
> 
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> 
> :> Traffic analysis information is indeed often present -
> :> but we are talking about once a message exists, does
> :> the attacker gain anything by looking at the cyphertext.
> :>
> :> That's what the definition of "perfect secrecy" talks about.
> :>
> :> Perfect secrecy applies to encryption devices.  Time of
> :> message transmission etc is considered to be outside its scope.
> :>
> :> A conventional OTP, [...] does not
> :> have Shannon's perfect secrecy property.
> 
> : I am not of the opinion that size is 'inherently' different
> : from time etc. in the present context.
> 
> Well, you should be.  Length is a property that can be used to
> distingush between elements of the set of possible plaintexts -
> while time cannot be so used.

Why not? I could well agree with my partner that if
a mail (of any innocent content) is sent between 9 and
10 o'clock it means one thing while between 10 and 11
o'clock it means the opposite. At least one bit can
be transmitted that way. (More could be done by
more sophisticated agreement.)

M. K. Shen

--

From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Notion of perfect secrecy
Date: Thu, 7 Jun 2001 09:22:11 -0700


Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>
> :> The OTP leaks information about the length of the plaintext.
> :>
> :> This is a clear security hazzard, and it may be necessary
> :> to take stops to prevent this information being used by the attacker.
> :>
> :> Also, it violates Shannon's perfect secrecy (which is what this
> :> thread is about).
> :>
> :> The OTP that is proven perfectly secure is in a system where only
> :> plaintexts of a given length are possibilities.  That is not the
> :> OTP as commonly used.
>
> : By your logic the TIME you send the message leaks just as much information
> : as the LENGTH of the message.
>
> : Can BICOM go back in TIME to send the message?
>
> : Also WHO is sending the message leaks info too ...etc..
>
> Perfect secrecy is a property of a device that translates between
> plaintext and cyphertext.
>
> It asks what information about the plaintext is present in the cyphertext.
>
> Traffic analysis information is outside the scope of "perfect secrecy"
> as Shannon defined it.
>
> : Shannon was looking at the OTP in an abstract model where the a priori (what
> : exactly does that mean)... er... previous known distribution of messages
> : cannot be used to solve the system.
>
> I believe "a priori" translates roughly as "before knowledge", if that helps.
>
> This isn't about previous messages.  Simple knowledge of the cyphertext
> and the machinery it was encrypted with is enough to reveal information
> about the plaintext.  Previous messages have nothing to do with it.
>
> : Let's say you have a 13 byte OTP message where the plaintext was in ASCII.
> : Obviously you can rule out OTPs that would lead to non-ascii st

Cryptography-Digest Digest #549

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #549, Volume #14   Thu, 7 Jun 01 11:13:00 EDT

Contents:
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes 
(Richard Wash)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes 
(Bob Silverman)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: MD5 for random number generation? (Phil Carmody)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Phil Carmody)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: MD5 for random number generation? (Tim Tyler)
  Re: OTP WAS BROKEN!!! (Al)
  Re: RSA's new Factoring Challenges: $200,000 prize. (Sergei Lewis)
  Re: Brute-forcing RC4 ("Scott Fluhrer")



From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 7 Jun 2001 13:26:33 GMT

[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:

>Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
snap...

>To see how a particular 8 bit cyphertext could map to more than 256
>different plaintexts, just get an 8 bit cyphertext, decrypt it with
>BICOM under a number of keys.
>
>You will see *many* different plaintexts come out - not just 256.

  Mok likes to talk but getting him to actually do anthing
is quite impossible. He would rather say its impossible than
actually check it out. A lot like TOMMY. Sometimes I think
He and Tommy are not real people. Since if they were you would
think Wagner who at least pretends to know something about
crypto would set them straight. Why he does not bother to
make an honest useful comment on a thread like this makes
me wonder just how much he wants the average person to know
about crypto. He could help people like TOMMY on these concepts
but refuses any useful real help. WHY??


David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
 made in the above text. For all I know I might be drugged or
 something..
 No I'm not paranoid. You all think I'm paranoid, don't you!


--

Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 07 Jun 2001 09:44:55 -0400

Tim Tyler <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>: Tim Tyler <[EMAIL PROTECTED]> writes:
>:> Tom St Denis <[EMAIL PROTECTED]> wrote:
>:>: Or if you just pad the bloody thing to a multiple of say 64 bytes. [...]
>:> 
>:> Still not enough for perfect secrecy :-(
>: 
>: Right--no matter what ``a multiple'' means. 
> 
> That's correct - so long as no restraints are placed on the set of
> possible plaintexts.

Exactly. So why do you keep switching premises? Specifically:

1. When somebody says, ``OTP on padded messages gives (Tim Tyler's
   definition of) perfect secrecy,'' you reply, ``No, because no
   amount of padding is enough.'' In other words, you assume that the
   space of plaintexts is infinite.

2. When somebody replies, ``Okay: if the space of messages is infinite,
   then (your definition of) perfect secrecy is impossible to achieve.''
   You reply, ``No, because the space of messages is actually finite.''
   (Or alternately, ``...has cardinality 2 in my universe.'')

3. Of course, if the space of messages is finite, then padding your
   plaintexts *is* enough to achieve (your definition of) perfect
   secrecy...

It's impossible to draw any useful conclusions if you keep changing
your mind about the set of possible plaintexts: first it's infinite;
then it's finite; then there are only two possible messages; then it's
infinite again. Once you make up your mind, one of two things becomes
true (with your definition of ``perfect secrecy''):

a. Perfect secrecy is impossible.
OR
b. Perfect secrecy is achieved using OTP on padded messages.

You keep denying *BOTH* statements, because whenever somebody makes
one statement, you start by assuming whichever hypotheses contradict it.

Len.



-- 
We also believe candor benefits us as managers: the CEO who misleads
others in public may eventually mislead himself in private.
-- Warren Buffett, 1983

--

From: Richard Wash <[EMAIL PROTECTED]>
Subject: Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large 
Primes

Cryptography-Digest Digest #548

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #548, Volume #14   Thu, 7 Jun 01 10:13:00 EDT

Contents:
  Re: Is this a weakness in RSA key generation? (Bodo Moeller)
  Re: shifts are slow? (Jeffrey Williams)
  Re: Brute-forcing RC4 (S Degen)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Humor, "I Must be a Threat to National Security" ("Tom  Gutnick")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Notion of perfect secrecy (SCOTT19U.ZIP_GUY)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)



From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Is this a weakness in RSA key generation?
Date: 7 Jun 2001 12:19:00 GMT

Bill Unruh <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] (Mark Borgerding):

>> I found that pgp 2.6.2 may sometimes generate a private exponent n
>> that does not entirely match the RSA spec (as I know it)

>> 1) d*e = 1 , mod (p-1)*(q-1)

>> 2) d*e = 1 , mod (p-1)
>> 3) d*e = 1 , mod (q-1)

>> pgp seems to occasionally generate a key that satisfies 2&3, but not 1.
>> I know that stmt #1 implies 2&3, but the reverse is not true.
>>
>> My question is: is this something to worry about?  What effect would

> Yes. It will not work. You will not be able to decrypt anything.

Wrong, such keys will work perfectly.  There is no requirement that

d*e == 1   (mod (p-1)(q-1)).

It is only necessary that

d*e == 1   (mod lcm(p-1, q-1)),

which is exactly equivalent to 2&3 above.

(To prove that RSA decryption works in this case, consider decryption mod p
and mod q and apply the Chinese Remainder Theorem.  Most RSA decryption
implementations use the CRT anyway, and in that case only  d mod p-1
and  d mod q-1  are actually used -- the exact choice of  d  does not
matter at all.)


-- 
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

--

From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: shifts are slow?
Date: Thu, 07 Jun 2001 07:35:02 -0500

IIRC, the original poster was talking about a P4, not a unique selection of
hardwired gates.

Before pipelined processors, shifts were frequently faster than adds and
almost always faster than multiplies (or divides).  Pipelining instructions
can (and almost certainly will) change some of our known facts about
programming.

If you really want to optimize your program for a given processor, you really
need to spend some time studying the data book for that processor.  It should
contain lots of information about the relative speeds of instructions.  Note
that figuring things out to an optimal level is not easy when dealing with a
pipelined processor as there are all kinds of options which will affect the
relative speed of an instruction.

Realistically, given the speed of today's processors, and the insanely low
cost per MIP, MOST OF THE TIME, you'd be better off writing your program in a
high-level language and using an optimizing compiler which can take full
advantage of the target processor.  Yes, if you really know the target
processor well, you could probably hand code the program to be faster, but
that "if" is huge.  Very few people will know a target processor well enough
to be a good optimizing compiler.  More to the point, given the rate at which
new processors are introduced, it becomes much more difficult to find people
who can beat the optimizing compiler.

Jeff


Tom St Denis wrote:

> "Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
> news:euGrY4t7AHA.277@cpmsnbbsa07...
> > The new reality is the same. It's just that for a register to shift it
> needs
> > to make use of itself as a shift register, so in a single clock bit 30
> moves
> > to 31, 29->30, 28->29, 27->26 . . .  1->2, 0->1. In order to shift by X
> > takes X clocks. Also because we have gotten to such high frequencies and
>
> This is so wrong.  I can shift a 512-bit register 211 bits in one cycle.
> (Just re-wire the outputs).
>
> 
>
> Boolean operations like AND,OR,XOR,NOT can take one cycle since you just
> apply all the logic in parallel.  So if 1 AND takes 1 cycle 32 ANDs should
> take 1 cycle too.  You get a bit of delay to synchronize the bits but
> generally that's low.
>
> Tom


--

From: S Degen <

Cryptography-Digest Digest #547

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #547, Volume #14   Thu, 7 Jun 01 08:13:00 EDT

Contents:
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Notion of perfect secrecy (Tim Tyler)
  Re: shifts are slow? (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) 
([EMAIL PROTECTED])
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)



From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 10:58:12 GMT

Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> JPeschel <[EMAIL PROTECTED]> wrote:

:> "perfect secrecy is defined by requiring of a system after a
:>  cyptogram is intercepted by the enemy the a posteriori probabilites
:>  of this cryptogram representing various messages be identaically the
:>  same as the a priori probabilites of the same message before the
:>  interception."
:>
:> If the length of the plaintext is revealed by the cyphertext, this
:> condition does not hold.

: How? [...]

It is obvious how the length of the plaintext is revealed by the
cyphertext.

The length of the plaintext is the same as the length of the cyphertext.

: If you have an 8-bit ciphertext all 256 plaintexts are equally
: probable.  That follows this distribution.

I am not considering a system with only 256 possible plaintexts.
That's a toy system, with no practical use.

: You're idea of security only works if your cipher can produce infinite
: length ciphertexts.

Not so.  Finite plaintexts can produce perfect secrecy.

: (of course your idea of security is vastly flawed)

How so, pray tell?

: I would hate to use 1.7 x 10^55 bytes of ram to send a 10 byte message
: home

No - that is not correct.  You could send a 10 byte message home while
retaining prefect secrecty - assuming a genuinely random shared key was
available.
-- 
__
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

--

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 11:15:08 GMT

Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...

:> The opponent knows more about the plaintext after observing the
:> cyphertext than he knew before he saw it - namely the length.
:>
:> The violates perfect secrecy.

: Only if the message is determined by the length.

No.  Regardless of what the message is, in fact - provided that messages
of more than one length are transmitted.

: "Oui" or "Non".  The length will not determine the message.

It won't distinguish between those two particular messages anyway.
Are those the only possible messages in the system?

: Or if you just pad the bloody thing to a multiple of say 64 bytes. [...]

Still not enough for perfect secrecy :-(

: Even still people won't use an OTP to encrypt single byte messages.

The argument that an OTP does not have perfect secrect does not depend on
single byte messages in any way.  I beleive Scott mentioned two and
three byte messages as an example.

Any discussion about one-byte messages seems to be a hangover from the
CTR mode discussion.

:> Traffic analysis information is indeed often present -
:> but we are talking about once a message exists, does
:> the attacker gain anything by looking at the cyphertext.
:>
:> That's what the definition of "perfect secrecy" talks about.

: No [...]

Yes.  Look it up.  Or read the posted definitions in this thread.

: perfect secrecy is defined as having no ability to tell one plaintext
: from another.

Since telling one plaintext from another is normally a trivial operation,
that statement is nonsense if taken literally.

What you probably mean is that the attacker has no ability to distinguish
between enctyptions of different plaintexts given only a single cyphertext
to work on - which is an equivalent formulation to the one I gave above.

: Who cares if you know the entire set of plaintexts [...]

Well, knowledge of the entire set of plaintexts is better than nothing at
all.

However I've not mentioned that subject AFAICS - I believe you've just
raised it for the first time in this thread.

:> Perfect secrecy applies to encryption devices.  Time of
:> message transmission etc is considered to be outside its scope.
:>
:

Cryptography-Digest Digest #546

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #546, Volume #14   Thu, 7 Jun 01 07:13:01 EDT

Contents:
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mark Wooding)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Humor, "I Must be a Threat to National Security" ("Tom St Denis")
  Re: Notion of perfect secrecy (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Notion of perfect secrecy (Tim Tyler)
  Re: Notion of perfect secrecy ("Tom St Denis")
  Re: shifts are slow? (Tim Tyler)
  Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes 
(Mark Wooding)
  Re: Notion of perfect secrecy (Tim Tyler)
  Re: shifts are slow? ("Tom St Denis")
  Re: Evidence Eliminator works great. Beware anybody who claims it doesn't work 
(propaganda) ("John Niven")
  Re: Def'n of bijection (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Notion of perfect secrecy ("Tom St Denis")
  MD5 for random number generation? ("Toby Sharp")
  Re: Notion of perfect secrecy (Tim Tyler)



From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 7 Jun 2001 09:40:31 GMT

Tim Tyler <[EMAIL PROTECTED]> wrote:

> That uses Rijndael in CBC mode.

Now I'm very confused.  You can't get a one-byte ciphertext out of a
128-bit block cipher in CBC mode.  There's nowhere to put an IV, for one
thing.

-- [mdw]

--

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 09:30:22 GMT

Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: "SCOTT19U.ZIP_GUY" wrote:
:> [EMAIL PROTECTED] (Mok-Kong Shen) wrote:

:> >Meanwhile I believe that the following is correct about
:> >the issue: The OTP processing only guarantees that the
:> >particular work that is performed doesn't give the opponent
:> >any (more) information. It doesn't exclude however the
:> >existence of other processing that could reduce the
:> >information that he could otherwise have about the message.

[snip]

:>No "perfect security" means what it says see my
:> other posts where I quote Shannon directly.

: I know Shannon's definition. Tell me, why my view above
: contradicts that in terms of a-priori and a-posteriori
: probability.

You say:

``The OTP processing only guarantees that the
  particular work that is performed doesn't give
  the opponent any (more) information.''

OTP processing gives the opponent information about the length of the
plaintext.

Before he looked at the cyphertext, he did not have this information.

That violates Shannon's perfect secrecy.
-- 
__
 |im |yler  [EMAIL PROTECTED]  Home page: http://alife.co.uk/tim/

--

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 09:45:29 GMT


"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> : Meanwhile I believe that the following is correct about
> : the issue: The OTP processing only guarantees that the
> : particular work that is performed doesn't give the opponent
> : any (more) information.
>
> The opponent knows more about the plaintext after observing the
> cyphertext than he knew before he saw it - namely the length.
>
> The violates perfect secrecy.

Only if the message is determined by the length.

"Oui" or "Non".  The length will not determine the message.  Or if you just
pad the bloody thing to a multiple of say 64 bytes.  Even still people won't
use an OTP to encrypt single byte messages.

> : It doesn't exclude however the existence of other processing
> : that could reduce the information that he could otherwise
> : have about the message.  As a special example, if any
> : message is sent from my home, the opponent knows that
> : some person is present there (or at least someone has
> : programmed my computer to undertake that action) at
> : the particular time point. (That could mean under
> : circumstances quite a lot, e.g. when for months no
> : message had ever been sent.)  No encryption
> : scheme, however 'perfect', could deprive him from
> : obtaining that knowledge. On the other hand, I could
> : manage to send the message from another place, in which
> : case he wouldn't have that information. Thus in a sense
> : the word 'perfect' in 'perfect security' is only to be
> : understood as one of terminology (definition) only and
> : does not have the common connotation of 'perfection'
> : (the ideal, the absolute best).
>
> Traffic analysis information is indeed often present -
> but we are talking about once a message exists

Cryptography-Digest Digest #545

2001-06-07 Thread Digestifier

Cryptography-Digest Digest #545, Volume #14   Thu, 7 Jun 01 06:13:00 EDT

Contents:
  Re: Is this a weakness in RSA key generation? ("Scott Fluhrer")
  Re: fast CTR like ciphers? (Volker Hetzer)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
  Re: Notion of perfect secrecy ("Jeffrey Walton")
  Humor, "I Must be a Threat to National Security" ("David G. Boney")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: AES question ([EMAIL PROTECTED] (=?iso-8859-1?q?=D8yvind?=)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Notion of perfect secrecy ("Tom St Denis")
  Re: Humor, "I Must be a Threat to National Security" ("Chaotic")
  Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
  Re: Def'n of bijection (Mark Wooding)



From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Is this a weakness in RSA key generation?
Date: Wed, 6 Jun 2001 23:21:26 -0700


Bill Unruh <[EMAIL PROTECTED]> wrote in message
news:9fh2l5$6si$[EMAIL PROTECTED]...
> In <[EMAIL PROTECTED]> [EMAIL PROTECTED]
(Mark Borgerding) writes:
>
> ]I found that pgp 2.6.2 may sometimes generate a private exponent n
> ]that does not entirely match the RSA spec (as I know it)
>
> ]An RSA private exponent d
> ]1) d*e = 1 , mod (p-1)*(q-1)
>
> ]which implies
> ]2) d*e = 1 , mod (p-1)
> ]3) d*e = 1 , mod (q-1)
>
>
> ]pgp seems to occasionally generate a key that satisfies 2&3, but not
> ]1.
> ]I know that stmt #1 implies 2&3, but the reverse is not true.
>
> ]My question is: is this something to worry about?  What effect would
>
> Yes. It will not work. You will not be able to decrypt anything.
It won't??? Would you please do me the favor of finding a p, q, d, e, x s.t.

   p, q prime
   p != q
   d*e = 1 mod (p-1)
   d*e = 1 mod (q-1)
   ((x**e)**d) != x mod pq

If, as you say, "it will not work", it should be pretty trivial to find such
a quintuplet.

--
poncho





--

From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: fast CTR like ciphers?
Date: Thu, 07 Jun 2001 09:48:45 +0200

Tim Tyler wrote:
> 
> Volker Hetzer <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> 
> [fast primitive for CTR mode]
> 
> :> My understanding is that what this application requires is a PRF - not a
> :> block cypher.
> 
> : Well, in that case the attacker can distinguish the message stream from
> : a random stream.
> 
> What - if a PRF is used to generate it?
No, if a block cipher (i.e. a prp) was used to generate it.

> While I believe it's customary to describe any system where there's
> a faster attack than brute force as being broken, I don't think
> this case is much of a concern if the opponent is one's little sister.
That's the academic definition. However, if there's a fixed, known and
proven reduction from one property (distinguishable from a random stream)
to a property you want to avoid (guessing the key or decrypting a message)
you can check your numbers and then decide wheather this particular attack
is of relevance to your application.

As it happens, this prp/prf stuff is IMHO only relevant if you either want to
use the ctr mode as a prng or go over so much of the counter space that
known-plaintext attacks or attacks based on the set of remaining blocks become
possible.

Remember, if you look at a fibre optics ocean cable, something like
80-130Gbit/s, we're talking about 2^62 bit per year. (Hoping I got the numbers
right here.) This is still a quarter of the amount of data you need to distinguish,
lets say AES-CTR from a random stream, much less get to work on predicting the
next block. In this case, the conclusion would be that the speed advantage of
CTR is much more important than an attack that only works if the lifetime of the
key exceeds the lifetime of the cable by a ridiculously large number of years.

Greetings!
Volker
--
They laughed at Galileo.  They laughed at Copernicus.  They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.

--

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 10:29:05 +0200



"SCOTT19U.ZIP_GUY" wrote:
> 
> [EMAIL PROTECTED] (Mok-Kong Shen) wrote:
> >>
> >> I would have to read what Shannon wrote in more detail to say how what
> >> this thread is about relates to what he wrote.
> 
>   Actually its Tommy and Mok that need to read up.
> 
> >>
> >> My main concern is with the d