Re: Internet Privacy Guaranteed ad (POTP Jr.)

At 17:22 2/20/96, IPG Sales wrote:

>If you are able to break the system, and everyone knows what we mean by
>break, then we will publicly admit that we are snake oil salesmen, and
>all the other things that Perry Metzger and others called us.

It is by no means clear to me what "breaking the system" means. One does
not have to be able to decipher a single message to prove a system to be
insecure. Moreover, cryptanalysis is economics: is it more expensive to get
the information by analyzing the crypto than it is to get it by other
means?

Do we have to show an exploitable flaw? Or we have to do the exploit? That
might be expensive. Who would judge the contest?

The alogrithm aside, IPG provides the intial OTP. Seems to me that IPG can
read the messages. End of story.


-- Lucky Green <mailto:shamrock@netcom.com>
   PGP encrypted mail preferred.

On Tue, 20 Feb 1996, Lucky Green wrote:

> At 17:22 2/20/96, IPG Sales wrote:
> 
> >If you are able to break the system, and everyone knows what we mean by
> >break, then we will publicly admit that we are snake oil salesmen, and
> >all the other things that Perry Metzger and others called us.
> 
> It is by no means clear to me what "breaking the system" means. One does
> not have to be able to decipher a single message to prove a system to be
> insecure. Moreover, cryptanalysis is economics: is it more expensive to get
> the information by analyzing the crypto than it is to get it by other
> means?
> 
> Do we have to show an exploitable flaw? Or we have to do the exploit? That
> might be expensive. Who would judge the contest?
> 
> The alogrithm aside, IPG provides the intial OTP. Seems to me that IPG can
> read the messages. End of story.
> 
Hedging, hedging, hedging - why? I did not noitice this in my first 
reply - in addition to giving you the company if you can break the 
system, we will give you the company if you can establish, through our 
employees or any other method, that we retain any Ocopies of the TPs, 
any! - for very large systems, we maintain a temporary copy to insure 
safe arrival, by excuting the check system menu item - 
it is immediate destroyed upon system notification. Anyone that wants to 
audit us cazn do so, unannounced at any time - subject to payment ofd 
expenses! We do not keep copies, we would not be in business 30 days if 
we did.

> 
> -- Lucky Green <mailto:shamrock@netcom.com>
>    PGP encrypted mail preferred.
> 
> 
>

-----BEGIN PGP SIGNED MESSAGE-----

> > Do we have to show an exploitable flaw? Or we have to do the exploit? That
> > might be expensive. Who would judge the contest?
> > 
> > The alogrithm aside, IPG provides the intial OTP. Seems to me that IPG can
> > read the messages. End of story.
> > 
> Hedging, hedging, hedging - why? I did not noitice this in my first 

I think he meant that it might cost him several $10000 in computing time to
actually demonstrate a flaw, should it be found. Proving the flaw exists
should be enough. If a company really needs unbreakable encryption, a few
hundred thou isn't too much for an attacker to pay for million dollar secrets.
On the other hand, it would be quite a bit for an individual to come up with,
just to illustrate a point.

And this thing about keeping a copy of the one-time-pad, now just why is it
that you need to at all?? After all, if it doesn't arrive safely, then who
knows who has it... And if so, then you don't need a copy that could, say,
accidently get smuggled out and sold to [foreign government, domestic
covernment, competitor, curious onlooker - pick one] for the right sum of
money.

For your next version, you might want to add in the capability for a slight
remixing of the random pool at both ends (a passphrase, for example)
protected by secure-hashing properly-sized chunks. There's nothing like
being able to lock the door behind you, ya know...

Don
- -- 
<don@cs.byu.edu>           fRee cRyPTo!   jOin the hUnt or BE tHe PrEY
PGP key - http://students.cs.byu.edu/~don   or PubKey servers (0x994b8f39)
  June 7&14, 1995: 1st amendment repealed.  Junk mail to root@fryser.dk.net
* This user insured by the Smith, Wesson, & Zimmermann insurance company *

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBMSrSo8La+QKZS485AQFXeAL6AviaeMve7k6Oh1F5qix9EOBT29wSXXMa
NAcr8PSTFfQ7kd1FHz2A1N4OPXO+AW2vVPLWiulU/bcXoP5K/+mU36wM17bo9nXz
0tiVmyZcDV4bn6Vs373oYIKt2W0rj02K
=sJQO
-----END PGP SIGNATURE-----

On Tue, 20 Feb 1996, Lucky Green wrote:

> At 17:22 2/20/96, IPG Sales wrote:
> 
> >If you are able to break the system, and everyone knows what we mean by
> >break, then we will publicly admit that we are snake oil salesmen, and
> >all the other things that Perry Metzger and others called us.
> 
> It is by no means clear to me what "breaking the system" means. One does
> not have to be able to decipher a single message to prove a system to be
> insecure. Moreover, cryptanalysis is economics: is it more expensive to get
> the information by analyzing the crypto than it is to get it by other
> means?
> 
> Do we have to show an exploitable flaw? Or we have to do the exploit? That
> might be expensive. Who would judge the contest?
> 
> The alogrithm aside, IPG provides the intial OTP. Seems to me that IPG can
> read the messages. End of story.
> 
> 
> -- Lucky Green <mailto:shamrock@netcom.com>
>    PGP encrypted mail preferred.
> 
> 
> 


Lucky - you know the answer to that, several people have access to Cray's 
and the like - you must prove that we have an exploitable flaw, not 
just claim it - everyone claims it smokes and mirrors, why are you not willing 
to  go ahead and decipher a message - everyone claimed it was so easy - 
why are the cypherpunks so quite all of a sudden, we have been getting 
about 5 messages an hour up until we accepted Dereks challenge - now we 
have not received any messages for over five hours until we received 
yours. If it is so EASY, JUST GO AHEAD AND DO IT!

I have been following this debate with some interest. I think that
it is quite clear that without your publishing the algorithms for your
product, you have to accept our skepticism obout your claims. You have
offered to do this so I will wait to make my judgement. 
	The issue that I have not seen you address is one that has been
brought up by several posters to this thread. This issue has to do with
the fact that if you generate all of the keys (or whatever) what is to
stop someone from offering one of your employees a LARGE bribe to cough up
the keys? 
	I don't think that anyone on this list would accept as secure any
system, no matter how clever, that relies on a human factor. People are
weak, properly used, mathematics is not. To suggest that such a security
breach would not occur with your procedures is disingenuous in the
extreme. 
	I am not trying to start (or continue) a flame war. I am willing
to learn more about your system before I pass judgement but I must tell
you, however, that I have heard nothing yet to give me any confidence 
that your system is secure. 

Regards,
Tim Philp

===================================
For PGP Public Key, Send E-mail to:
pgp-public-keys@swissnet.ai.mit.edu
In Subject line type:
GET PHILP
===================================

Tim  - Thank you for your open mindess -  Perhaps you, Lucky and some of 
the others would like to know how the manufacturing process is done:

1. The OTPs are generated on a standalone diskette only system, no hard 
   disk, networking or anything else - they are generated in packets, 
   10 Nvelopes, or OTPs at a time - a however many packets will fit on a 
   diskette - currently 120 packets, but that may go down -  the 
   diskettes are not labelled,  or identifed in any way.

2. From there, they go to QC - we perform:

   A: Full autocorrelation to determine if there is any singing, 
      ringing, reverberation, RFI,  or other anomalies present -
      if so discarded, if not continued -

   B. Cross Correlation to determine the existence of staccatic noise 
       or discontinuities if any - if so discaarded - if not continued

   C. Bit, Character, and Couplet, Triplet tests for Standard Deviation, 
      Chi Square - Delta ICs (Deltas on incremental changes), First 
      Differences, Second Differences, and a repaeating sequnce test -) 
      These all must pass threshold tests. They are not perfect, to do so 
      would destroy randomness, but they must meet certain thresholds. 
      If they fail to pass  then they are discarded - if they pass -
      still no labels but-

   D. System Integration - if they are to be downloaded to a customer,    
      they are encrypted for that customer - off line on a network system 
      - but directly from diskette to encrypted form - no labels or 
      anything to identify the data sets. So now it resides off line in a 
      form that can be sent encrypted to the customer. This system does 
      allow decryption, only encryption.

   E. It is then loaded onto a Internet capable system and 
      transmitted to the customer - 

   F. If the system is is a first time delivery - a template is used to 
      design the system - number of users, user types - and the like - 
      the data is unlabelled - there is no way to determine what the data
      is. The system is still unlabelled at this point - but the system 
      size is noted from a manufacture order but no designation of who it 
      is to be sent to - it is then sent to shipping where labels from 
      shipping orders are finally assigned.

      Where during this process do employees have access to the dqta to 
      make copies or determine what the OTPs are?


      Furthermore: For those unsatisfied with the security set out 
                   above, as soon as we can get it set up properly, we 
                   will invite any customer who so desires to come to 
                   our facilities and  manufacture there own OTPs on 
                   their own computers - hard drives disconnectd - in 
                   a RFI and radiation shielded environment - they can 
                   manufacture six months supply, or a year or 
                   whatever - 

        Additionally, we will not - repeat will not comply with any 
        court order to supply copies to anyone - we will go to jail or be 
        shut down first and always -

There is a lot more, but that is a general rundown - 

Thank you again for yuour openmindness - we are sure that we cannot 
satisgfy anyone about the integrity of our security - our 
manufacturing employees - primarily middle aged women operators with 
little if any technical expertise - do not have any access to the OTPs.

Appreciatively,
Ralph 


Stubborness and stupidity are twins - Sophocles

IPG Sales writes:
> Stubborness and stupidity are twins - Sophocles

IPG is both stubborn and stupid. How appropriate.

Let me give you another quote. It is acually a long extract of a
document written by Phil Zimmermann. Read it.

    Beware of Snake Oil
    ===================
    
    When examining a cryptographic software package, the question always
    remains, why should you trust this product?  Even if you examined the
    source code yourself, not everyone has the cryptographic experience
    to judge the security.  Even if you are an experienced cryptographer,
    subtle weaknesses in the algorithms could still elude you. 
    
    When I was in college in the early seventies, I devised what I
    believed was a brilliant encryption scheme.  A simple pseudorandom
    number stream was added to the plaintext stream to create
    ciphertext.  This would seemingly thwart any frequency analysis of
    the ciphertext, and would be uncrackable even to the most resourceful
    Government intelligence agencies.  I felt so smug about my
    achievement.  So cock-sure.  
    
    Years later, I discovered this same scheme in several introductory
    cryptography texts and tutorial papers.  How nice.  Other
    cryptographers had thought of the same scheme.  Unfortunately, the
    scheme was presented as a simple homework assignment on how to use
    elementary cryptanalytic techniques to trivially crack it.  So much
    for my brilliant scheme.
    
    From this humbling experience I learned how easy it is to fall into a
    false sense of security when devising an encryption algorithm.  Most
    people don't realize how fiendishly difficult it is to devise an
    encryption algorithm that can withstand a prolonged and determined
    attack by a resourceful opponent.  Many mainstream software engineers
    have developed equally naive encryption schemes (often even the very
    same encryption scheme), and some of them have been incorporated into
    commercial encryption software packages and sold for good money to
    thousands of unsuspecting users. 
    
    This is like selling automotive seat belts that look good and feel
    good, but snap open in even the slowest crash test.  Depending on
    them may be worse than not wearing seat belts at all.  No one
    suspects they are bad until a real crash.  Depending on weak
    cryptographic software may cause you to unknowingly place sensitive
    information at risk.  You might not otherwise have done so if you had
    no cryptographic software at all.  Perhaps you may never even
    discover your data has been compromised.
    
    Sometimes commercial packages use the Federal Data Encryption
    Standard (DES), a fairly good conventional algorithm recommended by
    the Government for commercial use (but not for classified
    information, oddly enough-- hmmm).  There are several "modes of
    operation" the DES can use, some of them better than others.  The
    Government specifically recommends not using the weakest simplest
    mode for messages, the Electronic Codebook (ECB) mode.  But they do
    recommend the stronger and more complex Cipher Feedback (CFB) or
    Cipher Block Chaining (CBC) modes.  
    
    Unfortunately, most of the commercial encryption packages I've looked
    at use ECB mode.  When I've talked to the authors of a number of
    these implementations, they say they've never heard of CBC or CFB
    modes, and didn't know anything about the weaknesses of ECB mode. 
    The very fact that they haven't even learned enough cryptography to
    know these elementary concepts is not reassuring.  And they sometimes
    manage their DES keys in inappropriate or insecure ways.  Also, these
    same software packages often include a second faster encryption
    algorithm that can be used instead of the slower DES.  The author of
    the package often thinks his proprietary faster algorithm is as
    secure as the DES, but after questioning him I usually discover that
    it's just a variation of my own brilliant scheme from college days. 
    Or maybe he won't even reveal how his proprietary encryption scheme
    works, but assures me it's a brilliant scheme and I should trust it. 
    I'm sure he believes that his algorithm is brilliant, but how can I
    know that without seeing it?  
    
    In all fairness I must point out that in most cases these terribly
    weak products do not come from companies that specialize in
    cryptographic technology.
    
    Even the really good software packages, that use the DES in the
    correct modes of operation, still have problems.  Standard DES uses a
    56-bit key, which is too small by today's standards, and may now be
    easily broken by exhaustive key searches on special high-speed
    machines.  The DES has reached the end of its useful life, and so has
    any software package that relies on it.
    
    There is a company called AccessData (87 East 600 South, Orem, Utah
    84058, phone 1-800-658-5199) that sells a package for $185 that
    cracks the built-in encryption schemes used by WordPerfect, Lotus
    1-2-3, MS Excel, Symphony, Quattro Pro, Paradox, and MS Word 2.0.  It
    doesn't simply guess passwords-- it does real cryptanalysis.  Some
    people buy it when they forget their password for their own files. 
    Law enforcement agencies buy it too, so they can read files they
    seize.  I talked to Eric Thompson, the author, and he said his
    program only takes a split second to crack them, but he put in some
    delay loops to slow it down so it doesn't look so easy to the
    customer.  He also told me that the password encryption feature of
    PKZIP files can often be easily broken, and that his law enforcement
    customers already have that service regularly provided to them from
    another vendor. 
    
    In some ways, cryptography is like pharmaceuticals.  Its integrity
    may be absolutely crucial.  Bad penicillin looks the same as good
    penicillin.  You can tell if your spreadsheet software is wrong, but
    how do you tell if your cryptography package is weak?  The ciphertext
    produced by a weak encryption algorithm looks as good as ciphertext
    produced by a strong encryption algorithm.  There's a lot of snake
    oil out there.  A lot of quack cures.  Unlike the patent medicine
    hucksters of old, these software implementors usually don't even know
    their stuff is snake oil.  They may be good software engineers, but 
    they usually haven't even read any of the academic literature in
    cryptography.  But they think they can write good cryptographic
    software.  And why not?  After all, it seems intuitively easy to do
    so.  And their software seems to work okay.    
    
    Anyone who thinks they have devised an unbreakable encryption scheme
    either is an incredibly rare genius or is naive and inexperienced. 
    Unfortunately, I sometimes have to deal with would-be cryptographers
    who want to make "improvements" to PGP by adding encryption
    algorithms of their own design.
    
    I remember a conversation with Brian Snow, a highly placed senior
    cryptographer with the NSA.  He said he would never trust an
    encryption algorithm designed by someone who had not "earned their
    bones" by first spending a lot of time cracking codes.  That did make
    a lot of sense.  I observed that practically no one in the commercial
    world of cryptography qualified under this criterion.  "Yes", he said
    with a self assured smile, "And that makes our job at NSA so much
    easier."  A chilling thought.  I didn't qualify either.
    
    The Government has peddled snake oil too.  After World War II, the US
    sold German Enigma ciphering machines to third world governments.
    But they didn't tell them that the Allies cracked the Enigma code
    during the war, a fact that remained classified for many years.  Even
    today many Unix systems worldwide use the Enigma cipher for file
    encryption, in part because the Government has created legal
    obstacles against using better algorithms.  They even tried to
    prevent the initial publication of the RSA algorithm in 1977.  And
    they have squashed essentially all commercial efforts to develop
    effective secure telephones for the general public. 
    
    The principal job of the US Government's National Security Agency is
    to gather intelligence, principally by covertly tapping into people's
    private communications (see James Bamford's book, "The Puzzle
    Palace").  The NSA has amassed considerable skill and resources for
    cracking codes.  When people can't get good cryptography to protect
    themselves, it makes NSA's job much easier.  NSA also has the
    responsibility of approving and recommending encryption algorithms. 
    Some critics charge that this is a conflict of interest, like putting
    the fox in charge of guarding the hen house.  NSA has been pushing a
    conventional encryption algorithm that they designed, and they won't
    tell anybody how it works because that's classified.  They want
    others to trust it and use it.  But any cryptographer can tell you
    that a well-designed encryption algorithm does not have to be
    classified to remain secure.  Only the keys should need protection. 
    How does anyone else really know if NSA's classified algorithm is
    secure?  It's not that hard for NSA to design an encryption algorithm
    that only they can crack, if no one else can review the algorithm. 
    Are they deliberately selling snake oil? 
    
    There are three main factors that have undermined the quality of
    commercial cryptographic software in the US.  The first is the
    virtually universal lack of competence of implementors of commercial
    encryption software (although this is starting to change since the
    publication of PGP).  Every software engineer fancies himself a
    cryptographer, which has led to the proliferation of really bad
    crypto software.  The second is the NSA deliberately and
    systematically suppressing all the good commercial encryption
    technology, by legal intimidation and economic pressure.  Part of
    this pressure is brought to bear by stringent export controls on
    encryption software which, by the economics of software marketing,
    has the net effect of suppressing domestic encryption software.  The
    other principle method of suppression comes from the granting all the
    software patents for all the public key encryption algorithms to a
    single company, affording a single choke point to suppress the spread
    of this technology.  The net effect of all this is that before PGP
    was published, there was almost no highly secure general purpose
    encryption software available in the US.
    
    I'm not as certain about the security of PGP as I once was about my
    brilliant encryption software from college.  If I were, that would be
    a bad sign.  But I'm pretty sure that PGP does not contain any
    glaring weaknesses (although it may contain bugs).  The crypto
    algorithms were developed by people at high levels of civilian
    cryptographic academia, and have been individually subject to
    extensive peer review.  Source code is available to facilitate peer
    review of PGP and to help dispel the fears of some users.  It's
    reasonably well researched, and has been years in the making.  And I
    don't work for the NSA.  I hope it doesn't require too large a "leap
    of faith" to trust the security of PGP.
    
             -- Phil Zimmerman, in the PGP manual.


IPG Sales writes:
> 1. The OTPs are generated on a standalone diskette only system,

They are not One Time Pads. They are keys for a random number
generator. Your continued assertion that they are One Time Pads is
fraudulent. They are not one time pads by any definition ever
previously used.

Furthermore, as has been stated, it is completely unacceptable for
keys to be generated by third parties.

> 2. From there, they go to QC - we perform:

The QC you perform is irrelevant.

The system you sell is insecure in a practical sense, likely uses an
insecure PRNG, and uses names and makes claims that come very close to
being fraudlent. It is harder, not easier, to manage the keys from
your system that supposedly "eliminates key management", and you don't
even have any shame about the fact that you are ignorant of the field
you work in.

> Ralph 
    
Perry

On Wed, 21 Feb 1996, Tim Philp wrote:

> 	The issue that I have not seen you address is one that has been
> brought up by several posters to this thread. This issue has to do with
> the fact that if you generate all of the keys (or whatever) what is to
> stop someone from offering one of your employees a LARGE bribe to cough up
> the keys? 

Not to mention GAK.  No bribe needed - just a "suit" showing up with what
looks like a court order. 
--
Ed Carp, N7EKG    			Ed.Carp@linux.org, ecarp@netcom.com
					214/993-3935 voicemail/digital pager
					800/558-3408 SkyPager
Finger ecarp@netcom.com for PGP 2.5 public key		an88744@anon.penet.fi

"Past the wounds of childhood, past the fallen dreams and the broken families,
through the hurt and the loss and the agony only the night ever hears, is a
waiting soul.  Patient, permanent, abundant, it opens its infinite heart and
asks only one thing of you ... 'Remember who it is you really are.'"

                    -- "Losing Your Mind", Karen Alexander and Rick Boyes

The mark of a good conspiracy theory is its untestability.
		    -- Andrew Spring

IPG Sales writes:
 > We do not keep copies, we would not be in business 30 days if 
 > we did.

How do you ensure that the keys are not intercepted, duplicated by a
man-in-the-middle, and forwarded?

______c_____________________________________________________________________
Mike M Nally * Tiv^H^H^H IBM * Austin TX    * I want more, I want more,
       m5@tivoli.com * m101@io.com          * I want more, I want more ...
      <URL:http://www.io.com/~m101>         *_______________________________

Mike McNally writes:
> 
> IPG Sales writes:
>  > We do not keep copies, we would not be in business 30 days if 
>  > we did.
> 
> How do you ensure that the keys are not intercepted, duplicated by a
> man-in-the-middle, and forwarded?

Besides, how do we KNOW they don't keep the keys? Other than their
vigorous protestations, of course -- and even were they paragons of
virtue instead of being about as slimey as they come it wouldn't be
acceptable.

Any system in which a third, untrusted party generates your keys for
you is, plain and simple, totally unacceptable. Period. I cannot
conceive of the circumstances under which I would allow a client to
use such a system if they had anything more important to protect than
their grocery list.

Perry

Mike, the keys are encrypted with an OTP that only the intended recipient 
can open - a special, subsystem used for that purpose only - employing 
the same techniquers, but entirely separate and apart from the primary 
user system -  any inteceptor would have to break trhe system, which we 
claim is impossible.


On Wed, 21 Feb 1996, Mike McNally wrote:

> 
> IPG Sales writes:
>  > We do not keep copies, we would not be in business 30 days if 
>  > we did.
> 
> How do you ensure that the keys are not intercepted, duplicated by a
> man-in-the-middle, and forwarded?
> 
> ______c_____________________________________________________________________
> Mike M Nally * Tiv^H^H^H IBM * Austin TX    * I want more, I want more,
>        m5@tivoli.com * m101@io.com          * I want more, I want more ...
>       <URL:http://www.io.com/~m101>         *_______________________________
>

IPG Sales writes:
> Mike, the keys are encrypted with an OTP that only the intended recipient 
> can open - a special, subsystem used for that purpose only - employing 
> the same techniquers, but entirely separate and apart from the primary 

Could you please learn how to spell?

You cannot possible send your keys to the recipients encrypted in a
one time pad, because a one time pad can be used only once. Every bit
of keying material you would send your clients would use up one bit of
the material they had. That would mean that you could never send your
clients new keying material this way.

The phrase one time pad is a fraud, plain and simple. I mean that in
the most technical, legal sense. Advertise using that term and the FTC
can and will throw you in jail.

What you have here is some sort of conventional stream cipher conked
up from a PRNG. You've solved no key management problems. What you've
done is simply generate lots of hype. When I see the PRNG I suspect
that I'll discover that the thing is nothing more than some sort of
multi-pass linear congruential generator that cracks open like an egg.

> user system -  any inteceptor would have to break trhe system, which we 
> claim is impossible.
> 
> 
> On Wed, 21 Feb 1996, Mike McNally wrote:
> 
> > 
> > IPG Sales writes:
> >  > We do not keep copies, we would not be in business 30 days if 
> >  > we did.
> > 
> > How do you ensure that the keys are not intercepted, duplicated by a
> > man-in-the-middle, and forwarded?
> > 
> > ______c____________________________________________________________________
_
> > Mike M Nally * Tiv^H^H^H IBM * Austin TX    * I want more, I want more,
> >        m5@tivoli.com * m101@io.com          * I want more, I want more ...
> >       <URL:http://www.io.com/~m101>         *______________________________
_
> > 
>

-----BEGIN PGP SIGNED MESSAGE-----

On Feb 21,  3:16pm, IPG Sales wrote:
> Subject: Re: Internet Privacy Guaranteed ad (POTP Jr.)
> Mike, the keys are encrypted with an OTP that only the intended recipient
> can open - a special, subsystem used for that purpose only - employing
> the same techniquers, but entirely separate and apart from the primary
> user system -  any inteceptor would have to break trhe system, which we
> claim is impossible.

see
http://www.marcus.rts.com.au/faq/one-time.html for a really brief summary
of the assumptions I'm about to use.

a) if I use a chunk of data A to encrypt another chunk of data B, then
   my method of encryption is *not* a one-time pad if size(A) < size(B)

b) the security of a one-time-pad O is only as good as any encryption used
   to exchange O between two parties, which leads to...

c) if C. lu`Lez, an Idiotic Pseudo-security Generator, wishes to transmit
   a chunk of data A to L. User, then for A (if A is truly random to begin
   with) to have the security of a one-time pad, A must be exchanged using
   a one-time pad B where size(B) > size(A)

d) CONTRADICTION: If C and L already share B, which is greater in size
   than A, *why is C sending more keys*?

Of course, it all works out if you stop expecting A to be a one-time pad when
it gets to L.

richard

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMSuj3h1gtCYLvIJ1AQF1hwP/a7RabRjyXfLSa1IbpdJjP91Su/Rskwjh
8k9GiihQsiQ/nyWkqp8wbNehjNj/n8smz0q+3wQUu5tSotWtv6ws8qJA4ntQhMGi
MePVQBX/1XMg2pMOr7VUca0cys/GXxXyJAOgzU/muSLxUkLtlGxwLV06yc5npuo0
j+y4M6igowI=
=TVkd
-----END PGP SIGNATURE-----

-- 
Richard Martin
Alias|Wavefront - Toronto Office [Co-op Software Developer, Games Team]
rmartin@aw.sgi.com/g4frodo@cdf.toronto.edu      http://www.io.org/~samwise
Trinity College UofT ChemPhysCompSci 9T7+PEY=9T8 Shad Valley Waterloo 1992

IPG Sales <ipgsales@cyberstation.net> said:

IS> Mike, the keys are encrypted with an OTP that only the intended
IS> recipient can open - a special, subsystem used for that purpose
IS> only - employing the same techniquers, but entirely separate and
IS> apart from the primary user system - any inteceptor would have to
IS> break trhe system, which we claim is impossible.

	So you send not one, but two sets of one time pads out of
band?  Well, if _both_ OTP shipments are intercepted and duplicated,
what keeps the interceptor from getting the keys?

-- 
#include <disclaimer.h>                               /* Sten Drescher */
Unsolicited email advertisements will be proofread for a US$100/page fee.