Cryptography-Digest Digest #781, Volume #13       Fri, 2 Mar 01 16:13:00 EST

Contents:
  test (br)
  Re: => FBI easily cracks encryption ...? ("Douglas A. Gwyn")
  Re: HPRNG (Benjamin Goldberg)
  Re: Super strong crypto (David Wagner)
  Re: super-stong crypto, straw man phase 2 ("Douglas A. Gwyn")
  Re: super-stong crypto, straw man phase 2 ("Douglas A. Gwyn")
  Re: HPRNG ("Douglas A. Gwyn")
  Re: "RSA vs. One-time-pad" or "the perfect enryption" ("Douglas A. Gwyn")
  Re: Will RIJNDAEL EVER HAVE BIJECTIVE MODES? (Benjamin Goldberg)
  Re: ARCFOUR and Latin Squares (Benjamin Goldberg)
  Re: => FBI easily cracks encryption ...? (Jim D)
  Re: super-stong crypto, straw man phase 2 (William Hugh Murray)
  Re: => FBI easily cracks encryption ...? (William Hugh Murray)
  Re: Super strong crypto ("Douglas A. Gwyn")
  Re: super-stong crypto, straw man phase 2 (William Hugh Murray)
  Re: Super strong crypto (SCOTT19U.ZIP_GUY)
  Re: Rabin's Unbreakable Code ("Bart, Mary and Kirk Pruhs")
  Re: Rabin's Unbreakable Code (ZRIS)
  Re: How good is the KeeLoq algorithm? (Fetcher)
  Completly wiping HD (David Griffith)
  Re: Rabin's Unbreakable Code (Ben Cantrick)
  Re: PKI and Non-repudiation practicalities ("Lyalc")

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

From: br <[EMAIL PROTECTED]>
Subject: test
Date: Fri, 02 Mar 2001 14:10:35 -0400

hi

I'm just trying to see if it works

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 2 Mar 2001 18:04:52 GMT

Mxsmanic wrote:
> I question why the FBI has a need to handle information at these levels
> in the first place, at least on any regular basis.  It sounds like there
> might be a lot of overclassification going on, which only weakens the
> security of classifications as a whole.

It's pretty obvious why: consider information about suspected
terrorists.  Some of that information might be obtained via
signals intelligence, the methods and in many cases existence
of which must not be disclosed in order to protect valid
national security concerns.

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

From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: HPRNG
Date: Fri, 02 Mar 2001 19:24:16 GMT

Frank Gerlach wrote:
> 
> > > Sorry to be nit-picky, but it aint a pseudo random number
> > > generator, so the name should be HRNG :)
>
> That there is randomness AT ALL, is a matter of religious belief, not
> science. Ironically, a lot of agnostics would most probably call
> quantum effects "truely random", but I can only call this a religious
> belief.

And does someone who /doesn't/ believe in randomness call quantum
effects "messages from God?"

-- 
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.

PS, Putting HPRNG in the subject line was a typo, I'd meant to put HRNG.

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

From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Super strong crypto
Date: 2 Mar 2001 19:24:58 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)

Douglas A. Gwyn wrote:
>No, that attack assumed that one already had control over
>what plaintext was transmitted *and* could read whatever
>plaintext was deciphered on the receiving end.  I maintain
>that if you can do that then *no* method of encryption can
>attain privacy; cryptanalysis isn't necessary in that case.

No, you misunderstood.  The attack assumed less than that.

The attack assumed that, *for a limited time only*, you have
control over what is transmitted and received.  Then, the
attack permits the adversary to continue reading traffic even
after the adversary loses access to the encryption and decryption
oracle.  This result is simply not possible without cryptanalysis.

My attack is just a straightforward chosen-plaintext/ciphertext
attack, and the attack is no less relevant than any other
chosen-plaintext/ciphertext attack.  There's nothing bogus here.

I assumed you were familiar with the standard justification
for why chosen-plaintext/ciphertext attacks are a concern, but
should I explain it in more detail?

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: super-stong crypto, straw man phase 2
Date: Fri, 2 Mar 2001 18:38:16 GMT

William Hugh Murray wrote:
> The method of encryption has never been the weak link in the system.
> Nation states use duplicity, coercion, and force.

Quite often, it is vulnerabilities in the basic method (think:
algorithm) that have been exploited to crack a system.  It is
true that in some cases, other methods have been more useful.
However, if the basic method is sufficiently vulnerable, those
other methods (with their associated risks) are not necessary;
a chain is best attacked at its weakest link.  To this end, it
behooves us to try to create sufficiently strong basic methods.
And since "sufficiently" is hard to determine, we should use
the conservative criterion that *no* method of cryptanalysis
will be effective against the basic method.  That takes us
well off the beaten path, which is why it is interesting.

> While I cannot prove it, I assert that modern cryptography already
> exceeds the strength of the next strongest component in the _system_
> by orders of magnitude hardly seen in astronomy.

That's the problem; you cannot prove that.  Sure, *some* key
distribution protocols are flawed and *some* cipher "modes"
have exploitable flaws, in which case the enemy has an easier
job than resorting to pure cryptanalysis.  But what about the
other cases?  The typical symmetric cipher is known to resist
only the stupidest kinds of cryptanalysis (or else we would
pick another cipher), and has no protection against *unknown*
(to us, not to the enemy) cryptanalytic techniques.  That makes
the cipher method (algorithm) itself a potentially weak link.
If we can do something about that, it behooves us to do so.

> By inspection, even with block ciphers, as I change the key
> more frequently, the length of the data encrypted under any
> single key approaches the length of the key (sound familiar?),
> the cost of attack goes up with the number of new keys, and
> the value of success for finding a particular key goes down.

But that is not appreciably more practical than using OTP, due
to the immense amount of key that must be securely delivered
separately.  If you instead consider embedding new key in the
data stream itself, you're back to my "straw man" proposal.

It should be observed that one doesn't actually have to send
exactly as much key as plaintext, even if the plaintext has no
redundancy.  A scheme like my "straw man phase 2" should suffice.

> ...  If there are any out there who are chasing provably
> secure and practical systems, then I can only say that I am
> sorry for them.

Actually there are a fair number of people working on just
that, with varying degrees of success.

> I am a security person.  I must live in the real world, not
> the abstract world of mathematical proofs.  In that world, a
> marginal increase in the security of cryptograms does not buy
> me enough to be worth the effort of cryptographers.  In that
> world, the cost of cryptanalysis has always been high and it
> has never dropped suddenly.  The cost of force has always
> been cheapest just when one most needs protection. ...

The use of force has its own limitations, and in fact "pure"
cryptanalysis has resulted in numerous successes, far more
than the public will ever hear about.  Mathematics, and
logic in general, is useful in drawing conclusions from
specified premises; when applied to practice, one needs to
make sure that the model fits sufficiently well.  The
valuable thing about "super strong" crypto would be that it
allows one to concentrate on other aspects of system design.
If you don't know what the weakest link in a chain is, and
strengthen a particular link (the basic method, here), then
you haven't weakened the chain as a whole and you *might*
have strengthened the chain as a whole.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: super-stong crypto, straw man phase 2
Date: Fri, 2 Mar 2001 18:45:45 GMT

"SCOTT19U.ZIP_GUY" wrote:
>   I guess that means by your classifcation scott16u could easily
> be far more secure than any of the proposed AES ciphers that most
> users will be tricked into using. Since it is one of the few
> ciphers that takes Shannons's unicity concept seriously.

I will say that David Scott has addressed similar concerns to
mine, although in a different context.  My particular concern
is to use a one-way channel securely, in a streaming manner,
with a limited amount of key, as described in another posting.
David, as I understand him, has assumed that the entire file
to be protected is available before encryption starts.  Both
contexts arise naturally in practice, and they lead to
different designs.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: HPRNG
Date: Fri, 2 Mar 2001 18:51:54 GMT

Frank Gerlach wrote:
> That there is randomness AT ALL, is a matter of religious belief, not
> science. Ironically, a lot of agnostics would most probably call quantum
> effects "truely random", but I can only call this a religious belief.

The genuinely random nature of quantum phenomena has been
verified by a combination of theoretical and experimental
work.  (Bell, Aspect, et al.)  Perhaps you have been misled
by typical textbook presentations, which state the theory
in terms of axiomatic assumptions including some involving
probability.  But the evidence is clearly on the side of
quantum randomness being of a different nature than mere
lack of sufficiently detailed knowledge.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: "RSA vs. One-time-pad" or "the perfect enryption"
Date: Fri, 2 Mar 2001 18:59:22 GMT

William Hugh Murray wrote:
> ...  The Diffie-Hellman work changed history and
> Ellis, Cocks, and Williamson will be no more than a footnote.

I think that is a fair assessment, assuming that the GCHQ/NSA
work wasn't applied in some secret way that had a big effect
on history that is not yet known.  It is said that one such
application may have been in nuclear monitoring.  (I really
don't know one way or the other and don't care to find out.)

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

From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Will RIJNDAEL EVER HAVE BIJECTIVE MODES?
Date: Fri, 02 Mar 2001 19:30:01 GMT

Tom St Denis wrote:
> 
> "SCOTT19U.ZIP_GUY" wrote:
[snip]
> Apparently you didn't read all the papers.  The CTR mode can encrypt
> single bit files just as easily as 8-bit or 128-bit ones.
> 
> Go back to lalala land.

The problem with that advice, Tom, is that he is in lala land, not
lalala land.  And, more important, is that he never left.

-- 
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.

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

From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: ARCFOUR and Latin Squares
Date: Fri, 02 Mar 2001 19:50:05 GMT

r.e.s. wrote:
> 
> ARCFOUR uses mod-256 addition in several of its steps.
> But for 8-bit arguments, (x+y) mod 256 is just one
> of a large number of functions whose value-tables are
> symmetric order-256 Latin Squares. (Another is XOR.)
> 
> So, consider the even-larger number of ARCFOUR-like
> ciphers obtainable by replacing some or all of its
> mod-256 additions by operations defined by other
> symmetric order-256 Latin Squares.  (Many of these,
> like XOR, are computable via "built-in" functions,
> but others would require some sort of table lookup,
> I suppose.  If table lookup were used, then we might
> also consider generating a random symmetric Latin
> Square for the purpose. Hmm... would that be hard?)
> 
> All this would be apart from ARCFOUR's final-stage
> XOR combiner, so invertibility of the Latin Square
> is not an issue.
> 
> Is it reasonable to explore this idea further for at
> least some of the symmetric Latin Squares, e.g. XOR?
> Or am I missing some flaw that would make it a waste
> of effort?

The flaw that you're missing is that doing such things results in a
cipher that is only efficient in hardware, not in software.  Also, they
would have to be analysed, whereas RC4 already has been analysed.

-- 
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.

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

From: [EMAIL PROTECTED] (Jim D)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 02 Mar 2001 19:50:41 GMT
Reply-To: Jim D

On Fri, 02 Mar 2001 10:37:18 GMT, "Mxsmanic" <[EMAIL PROTECTED]> wrote:

>"Jeff Moser" <[EMAIL PROTECTED]> wrote in message
>news:97n22f$g7d$[EMAIL PROTECTED]...
>
>> The point is, I don't think this guy was stupid
>> enough to use poor encryption.
>
>He wouldn't have to be stupid; he could just be naïve.

Bound to be. He's a Yank!

-- 
___________________________________________

Posted by Jim Dunnett

  George Dubya Bushisms No 6:

    CIA? Howdja spell that?
  
[EMAIL PROTECTED]
[EMAIL PROTECTED]

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

From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: super-stong crypto, straw man phase 2
Date: Fri, 02 Mar 2001 19:49:08 GMT

> > By inspection, even with block ciphers, as I change the key
> > more frequently, the length of the data encrypted under any
> > single key approaches the length of the key (sound familiar?),
> > the cost of attack goes up with the number of new keys, and
> > the value of success for finding a particular key goes down.
>
> But that is not appreciably more practical than using OTP, due
> to the immense amount of key that must be securely delivered
> separately.

I wondered after I wrote it if you were going to pick up on that.

Are you familiar with the IBM Key Management System or their proposal for
key-management to the IETF?



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

From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: => FBI easily cracks encryption ...?
Date: Fri, 02 Mar 2001 19:55:14 GMT

"Douglas A. Gwyn" wrote:

> Mxsmanic wrote:
> > I question why the FBI has a need to handle information at these levels
> > in the first place, at least on any regular basis.  It sounds like there
> > might be a lot of overclassification going on, which only weakens the
> > security of classifications as a whole.
>
> It's pretty obvious why: consider information about suspected
> terrorists.  Some of that information might be obtained via
> signals intelligence, the methods and in many cases existence
> of which must not be disclosed in order to protect valid
> national security concerns.

Perhaps.  Seems very unlikely that the FBI can collect such information on its
own and even less likely that the NSA would trust the FBI with it.



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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Fri, 2 Mar 2001 19:34:14 GMT

"SCOTT19U.ZIP_GUY" wrote:
>   Doug I think it would be far better if the enemy was
> not just transferring PT zero encrypted data.

You must mean, the legitimate transmitter (not the enemy,
who plays the role of eavesdropper).

> He should be encrypting random data so that traffic much
> harder to analyze.

Sure, but for purposes of evaluating "super strength"
we should assume the worst case that can reasonably be
expected.  For example, about 50 years ago we used
punched paper tape as key in a certain cryptosystem.
Operators in the field reported that long stretches of
the tape consisted of all 0 bits.  It turned out that
the producers of the tape had set their scissors (which
they used to cut it into batches) on top of the unit,
inadvertently activating a "punch leader" button.
Similar "busts" (to use the cryppie vernacular) have
occurred in a great number of systems in actual use,
e.g. a dead stage in a shift register, and often these
have provided the "opening wedge" used by analysts to
pry the system wide open.  So, although a channel might
reasonably be designed to transmit random noise when an
actual message is not present, there is a nonnegligible
chance that something will go wrong and a long stretch
of 0s (or 1s) be transmitted.  Constant 0s or 1s in CT
are not a big security problem since they completely
hide the key, but constant 0s or 1s in PT are sometimes
a serious problem in that they permit some streamlined
method of cryptanalysis (one that can be prepared in
advance, unlike the general case of known PT attack).

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

From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: super-stong crypto, straw man phase 2
Date: Fri, 02 Mar 2001 20:08:34 GMT

> > I am a security person.  I must live in the real world, not
> > the abstract world of mathematical proofs.  In that world, a
> > marginal increase in the security of cryptograms does not buy
> > me enough to be worth the effort of cryptographers.  In that
> > world, the cost of cryptanalysis has always been high and it
> > has never dropped suddenly.  The cost of force has always
> > been cheapest just when one most needs protection. ...
>
> The use of force has its own limitations,

Agreed.  When one breaks fingers, someone screams.  Which is why NSA and
GCHQ are intererested in cryptanalysis in the first place.



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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Super strong crypto
Date: 2 Mar 2001 20:10:39 GMT

[EMAIL PROTECTED] (Douglas A. Gwyn) wrote in 
<[EMAIL PROTECTED]>:

>"SCOTT19U.ZIP_GUY" wrote:
>>   Doug I think it would be far better if the enemy was
>> not just transferring PT zero encrypted data.
>
>You must mean, the legitimate transmitter (not the enemy,
>who plays the role of eavesdropper).

  yes your correct.
>
>> He should be encrypting random data so that traffic much
>> harder to analyze.
>
>Sure, but for purposes of evaluating "super strength"
>we should assume the worst case that can reasonably be
>expected.  For example, about 50 years ago we used
>punched paper tape as key in a certain cryptosystem.
>Operators in the field reported that long stretches of
>the tape consisted of all 0 bits.  It turned out that
>the producers of the tape had set their scissors (which
>they used to cut it into batches) on top of the unit,
>inadvertently activating a "punch leader" button.
>Similar "busts" (to use the cryppie vernacular) have
>occurred in a great number of systems in actual use,
>e.g. a dead stage in a shift register, and often these
>have provided the "opening wedge" used by analysts to
>pry the system wide open.  So, although a channel might
>reasonably be designed to transmit random noise when an
>actual message is not present, there is a nonnegligible
>chance that something will go wrong and a long stretch
>of 0s (or 1s) be transmitted.  Constant 0s or 1s in CT
>are not a big security problem since they completely
>hide the key, but constant 0s or 1s in PT are sometimes
>a serious problem in that they permit some streamlined
>method of cryptanalysis (one that can be prepared in
>advance, unlike the general case of known PT attack).
>

   Yes I see what you mean and I agree it should be
tested for worst case. Nothing is done correctly in the
field. If something can go wrong it will.



David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
        http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
        http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
        http://radiusnet.net/crypto/  then look for
  sub directory scott after pressing CRYPTO
Scott famous Compression Page
        http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:

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

From: "Bart, Mary and Kirk Pruhs" <[EMAIL PROTECTED]>
Subject: Re: Rabin's Unbreakable Code
Date: Fri, 2 Mar 2001 15:36:45 -0700

There is a paper here
http://www.deas.harvard.edu/~zong/paper.html
entitled
Provably Secure and Non-Malleable Encryption
The server won't let me download a copy of
the paper, so I don't know what the technical
result is. Given the AP's history of reporting
scientific/technical/mathematical results, I wouldn't
put much confidence in their story being
substantially correct.






====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
=======  Over 80,000 Newsgroups = 16 Different Servers! ======

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

From: [EMAIL PROTECTED] (ZRIS)
Subject: Re: Rabin's Unbreakable Code
Date: Fri, 02 Mar 2001 20:38:45 GMT

Sorry if this is a dumb question:

While Reading the thread about Dr. Rabin's new method of encrypting
messages, how does the reciepient get the same randomly generated
string and does he not have to store it to read the message?

Chris


On Fri, 02 Mar 2001 04:11:44 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:

>Bob Harris wrote:
>> I searched the web, and this newsgroup, but haven't been able to ...
>
>It has been discussed for several days now in this newsgroup.
>Check the past week or so, e.g. thread "The Key Vanishes".


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

From: [EMAIL PROTECTED] (Fetcher)
Subject: Re: How good is the KeeLoq algorithm?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 02 Mar 2001 20:43:57 GMT

On Fri, 02 Mar 2001 09:29:01 GMT, Søren A.Møller
<[EMAIL PROTECTED]> wrote:

>Hi,
>
>I am not a crypto specialist, so I hope somebody here can help me.
>
>Does there exist any analysis og the KeeLoq crypto algorithm?
>
>A bit of info about KeeLoq:
>Was invented by Nanoteq, implemented in chips by Exel and now owned and used by 
>Microchip.
>It is a 32 bit block cipher with a 64 bit key.
>It is mainly used in remote keyless entry systems for cars, where it is used to 
>encrypt a counter for 
>each transmission to validate the transmitter.
>The algorithm is sort of secret; you need to buy the decryption part from Microchip 
>(a $10 disk) 
>and it comes with a 4 page licence agreement. The encryption part can easily be 
>derived from the 
>decryption part.
>


I have looked at the KeeLoq algorithm in detail, and it appears to be
as secure as any 64-bit key 32-bit block algorithm could be.  It is
well-suited for remote keyless entry, but for little else because
it is so very slow, using over 500 rounds.

-Fetcher


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

From: David Griffith <[EMAIL PROTECTED]>
Subject: Completly wiping HD
Date: Fri, 02 Mar 2001 20:44:39 +0000

I wish to completly wipe a 2gig harddisk. There is now no data i want to
keep, however neither do i want anything to be recoverable.
I thought a linux boot disk, root fs from a ramdisk , with a shell
script doing this kind of thing

dd if=/dev/random of=/dev/hda
dd if=/dev/zero of=/dev/hda


Is this enough to wipe it clean?
Is /dev/urandom enough so as not to run out random data?

Thanks in advance



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

From: [EMAIL PROTECTED] (Ben Cantrick)
Subject: Re: Rabin's Unbreakable Code
Date: 2 Mar 2001 13:48:08 -0700

In article <[EMAIL PROTECTED]>,
ZRIS <[EMAIL PROTECTED]> wrote:
>While Reading the thread about Dr. Rabin's new method of encrypting
>messages, how does the reciepient get the same randomly generated
>string and does he not have to store it to read the message?

  The sender and receiver have to agree on a time to start recording
the random bits that are being continually broadcasted, and also how
many bits to record. And then they have to store the bits so they
can use them to encrypt the message later.

  At this point, you start to get an idea as to why most crypto
people aren't that excited about Rabin's idea. If you can securely
tell someone a piece of info, like a time and a number of bits, why
didn't you just give them a one-time encryption pad while you were
at it? That also has the advantage that nobody can record your
one-time pad because it's not being broadcast to the public.

  About all Rabin's scheme buys you is that you don't have to know how
to build a decent random number generator. In all other respects it's
just a standard one-time pad.


          -Ben
-- 
Ben Cantrick ([EMAIL PROTECTED])        |   Yes, the AnimEigo BGC dubs still suck.
BGC Nukem:     http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs:  http://www.dim.com/~mackys/spamdogs
"I think you have enough angst without wrapping yourself in videotape." -Mark

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

From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: PKI and Non-repudiation practicalities
Date: Sat, 3 Mar 2001 07:48:54 +1100

2 answers
Not yet much literature on the practical issues.  The PKI vendors are
building CA component systems for the wrong business model.

Non-repudiation of what?
- The existence of an unaltered message?
- or proof that I digitally signed the message that appears to be from me
(thus becoming an electronic signature).
Common PKi does the former well enough, alebit with the overheads you
mention.  Totally useless with the latter, since non-Public key technology
is an essential component required to acheive this outcome.

Lyal


Mark Currie wrote in message <3a9f90cc$0$[EMAIL PROTECTED]>...
>Hi,
>
>Non-repudiation is often used as a selling point for PKI but this can be
>misleading. Non-repudiation requires additional infrastructure such as
>databases for storing each signed message together with its corresponding
>signature. In high-throughput applications the amount of storage needed can
be
>very large indeed. There are many applications of public key cryptography
(i.e.
>communications security) where Non-repudiation is impractical because of
the
>storage requirement. Non-repudiation would also require independent
validation
>services that are capable of verifying the message originator given a
message,
> signature & certificate. These services would have to demonstrate a high
level
>of trustworthiness since the output is likely to be a simple Yes/No. The
full
>implications of supporting Non-repudiation may not be that clear to PKI
>customers and their application developers. The message that often comes
across
>is that PKI / PK technology gives you Non-repudiation. It does not. It
seems to
>me that there needs to be more information around the practical
implementation
>of Non-repudiation.
>
>It is possible that these issues are now being addressed by PKI vendors.
Does
>anyone know of any literature that covers the practical issues around
>Non-repudiation ?
>
>Mark
>



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


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list by posting to sci.crypt.

End of Cryptography-Digest Digest
******************************

Reply via email to