Cryptography-Digest Digest #821, Volume #13 Tue, 6 Mar 01 16:13:01 EST
Contents:
Re: Monty Hall problem (was Re: philosophical question?) (Ken Cox)
Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily crack ...?)
(Mitch)
NTRU - any opinions ("James Russell")
Re: Monty Hall problem (was Re: philosophical question?) (Ken Cox)
Re: => FBI easily cracks encryption ...? ("Daniel Johnson")
Re: Monty Hall problem (was Re: philosophical question?) (John Joseph Trammell)
Re: The Foolish Dozen or so in This News Group ("Doom the Mostly Harmless")
Re: => FBI easily cracks encryption ...? (Free-man)
Re: => FBI easily cracks encryption ...? ("kroesjnov")
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: Super strong crypto (David Wagner)
Re: => FBI easily cracks encryption ...? ("kroesjnov")
Re: PKI and Non-repudiation practicalities ("Lyalc")
Re: PKI and Non-repudiation practicalities ("Lyalc")
----------------------------------------------------------------------------
From: Ken Cox <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Tue, 06 Mar 2001 12:11:59 -0600
"Joe H. Acker" wrote:
> Ken Cox <[EMAIL PROTECTED]> wrote:
> > Are you saying above that from the beginning, when you
> > initially chose among three doors, your chance of picking
> > the right door was always 1/2?
>
> Yes, that's what I think.
So, if I show you three cards, two aces and a queen, and
place them face down on the table in front of you, you
think you have a 50/50 chance of picking the queen? So
this would be a fair game if you payed me a dollar if
you didn't find the queen, and I paid you a dollar if
you did? And it would be in your favor if I paid you,
say, a dollar fifty whenever you found the queen?
Gee, with that variation, grifters wouldn't even have
to cheat at three-card monty.
--
Ken Cox [EMAIL PROTECTED]
------------------------------
From: Mitch <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily crack ...?)
Reply-To: Mitch <[EMAIL PROTECTED]>
Date: Tue, 06 Mar 2001 18:11:38 +0000
On Tue, 06 Mar 2001 10:33:32 -0500, Ron B. enlightened us all with:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Tue, 06 Mar 2001 10:20:35 +0000, Mitch <[EMAIL PROTECTED]>
>wrote:
[..]
>>o Genesis 9:7
[..]
>'Be fruitful, then, and increase in numbers; people the earth and
>rule over it.'
[..]
>Why is this an insult? _Way_ too subfile an insult for this Yankee!
It can be construed as a command to fsck off.
T'is also possible to refer to the banker as a disciple of Onan.
--
Mitch
------------------------------
From: [EMAIL PROTECTED] ("James Russell")
Subject: NTRU - any opinions
Date: 6 Mar 2001 19:20:12 +0100
Does anyone here have any opinions on the viability of NTRU's public key
algorithm?
Thanks.
James
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
Posted from [206.156.202.110] by way of f220.law10.hotmail.com [64.4.15.220]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: Ken Cox <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Tue, 06 Mar 2001 12:19:22 -0600
Mxsmanic wrote:
> "Fred Galvin" <[EMAIL PROTECTED]> wrote:
> > As for your truth table, note that a line of
> > your table does not completely specify an outcome:
> > there should be another column indicating which
> > door Monty opened.
>
> No such lines are necessary, because the results are the same, and the
> probabilities of him opening one door or the other always add up to
> 100%.
Still, to make Fred happy, let's give the full table --
with, of course, the weights, since the lines are not
all equally likely. Let's say, by symmetry, that the
car is behind door 1; and let's say that, when the
contestant happens to pick door 1, Monty then opens
door 2 with probability p and door 3 with probability
1-p.
Choice Open Weight Stay Switch
1 2 p/3 WIN LOSE
1 3 (1-p)/3 WIN LOSE
2 3 1/3 LOSE WIN
3 2 1/3 LOSE WIN
Summing the weights over the rows, the "stay" strategy
wins 1/3 of the time, and the "switch" strategy wins
2/3 of the time.
Note that the technique that Monty uses to pick the
door to open, in the case that the contestant picks
the car at first, doesn't matter. However he does it,
the weights of the first two rows sum to 1/3.
--
Ken Cox [EMAIL PROTECTED]
------------------------------
From: "Daniel Johnson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 6 Mar 2001 12:48:41 -0600
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Beretta wrote in message
<[EMAIL PROTECTED]>...
>On Sun, 4 Mar 2001 13:10:01 +0100, "kroesjnov" <[EMAIL PROTECTED]>
>wrote:
>
><snip>
>>
>>I am willing to trade some privacy for safety.
><snip>
>
>So basically, you are saying that you'll trade your privacy to be a
>sheep? I.e. you'll give up your rights so that the goverment can play
>the role of sheepherder?
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-- Benjamin Franklin, Historical Review of Pennsylvania, 1759
Through the modem, off the server, over the T1, past the frame-relay,
< < NOTHIN' BUT NET > >
Daniel Johnson
[EMAIL PROTECTED]
- -Remove N.o.S.p.A.m. and all dots but the obvious one to reply-
Public PGP Keys & other info: http://dannyj.come.to/pgp/
> > My news server "misses" posts occasionally. If I don't reply to <
> > < a question or something, please repost and/or e-mail me. < <
=====BEGIN PGP SIGNATURE=====
Version: 6.5.8.03ckt http://irfaiad.virtualave.net/
Comment: http://DannyJ.Come.To/PGP/
Comment: KeyID: 0xEAF19C50163E81EF
iQA/AwUBOqUxBurxnFAWPoHvEQIsjwCeMPICdDj04EAMkt/syF+A+32NbAUAoJUJ
YVf5e/0PdwG8AM/tudk/xUNw
=JZMw
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (John Joseph Trammell)
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Tue, 06 Mar 2001 19:13:18 GMT
On Tue, 6 Mar 2001 11:01:06 +0100, Joe H. Acker <[EMAIL PROTECTED]> wrote:
> My tests are contradicting to your test. They give a 50:50 result.
[snip]
OK, for kicks I got this going in Perl (since I'm no VB coder);
the results are at the end. Perhaps there's a bug in that VB.
===========
#!/usr/bin/perl -w
use strict;
use constant SIZE => 100000;
srand(time ^ ($$ + ($$ << 15)));
my (%switch,%stay);
for (1 .. SIZE)
{
my $car = int rand(3); # car is behind 0,1,2
my $choice = int rand(3); # contestant chooses 0,1,2
# determine Monty's door choice
my $monty;
if ($car == $choice) # contestant guessed the car
{
$monty = ($choice + 1) % 3;
}
else # contestant guessed a goat
{
for (0 .. 2) {
next if (($car == $_) or ($choice == $_));
$monty = $_;
}
}
printf("car:%d choice:%d monty:%d\n",$car,$choice,$monty)
if ($_ % 1000 == 0);
# determine success from switching / not-switching
SWTICHING: {
my $new;
for (0 .. 2) {
next if (($_ == $monty) or ($_ == $choice));
$new = $_;
}
if ($new == $car) { $switch{success}++ }
else { $switch{failure}++ }
}
STAYING: {
if ($choice == $car) { $stay{success}++ }
else { $stay{failure}++ }
}
}
printf qq[Number of trials: %d\n], SIZE;
printf qq[Number of switch successes: %d (%f%%)\n],
$switch{success}, 100.0 * $switch{success} / SIZE ;
printf qq[Number of switch failures: %d (%f%%)\n],
$switch{failure}, 100.0 * $switch{failure} / SIZE ;
printf qq[Number of stay successes: %d (%f%%)\n],
$stay{success}, 100.0 * $stay{success} / SIZE ;
printf qq[Number of stay failures: %d (%f%%)\n],
$stay{failure}, 100.0 * $stay{failure} / SIZE ;
__END__
Number of trials: 100000
Number of switch successes: 66436 (66.436000%)
Number of switch failures: 33564 (33.564000%)
Number of stay successes: 33564 (33.564000%)
Number of stay failures: 66436 (66.436000%)
To be frank, this is needlessly bloated -- we know that only
one of (switch,stay) will succeed, so there's no need to
test both.
------------------------------
From: "Doom the Mostly Harmless" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 19:49:16 GMT
> I like my software to be criticized if the criticism has merit.
>
> How about this: "Your interface sucks!"
>
> Now that's criticism.
Technically, yes. That is criticism. But is it criticism with merit? I
suppose that depends on who you ask. My guess is that a poll of sci.crypt
would reveal that people here care a lot less about what you (or your
software) look like, and more about what you (or it) can do.
If you want your interface criticized, I suggest you submit it to one of the
GUI programming newsgroups. Here, we worry about how (or whether) things
actually work.
Two more points. You responded to my last post with a long rant about how
well your software works on floppy disks. I never denied that your software
did what it says. Personally, I've not taken a close enough look at any of
my hardware or the deep internals of my disk drivers to really know. That's
far from my area of specialty. In any case, I don't keep anything on my
hard drive I wouldn't want the gov't (or my parents, for that matter) to
see, so I have no percieved need for your software, and convincing me that
it works ain't gonna do you any good whatsoever.
--
To air is human....
--Doom.
------------------------------
From: [EMAIL PROTECTED] (Free-man)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 06 Mar 2001 20:06:50 GMT
On Tue, 06 Mar 2001 01:45:08 GMT, Beretta
<[EMAIL PROTECTED]> wrote:
>On Tue, 06 Mar 2001 00:25:52 GMT, [EMAIL PROTECTED] (Free-man) wrote:
>
><snip>
>>
>>>So buy a ranch in Montana and declare yourself an independent
>>>country.
>>
>>Great idea. In fact, the right of secession was fundamental in the
>>creation of the US, but, the current tyrants do not respect basic
>>rights.
>>
><snip>
>
>That is such B.S.
>
>There is no right of secession, nor should there be.
>
>We fought a war over that so called right, and the south lost.
So if someone points a gun at your head and forces you to
do something against your will, does that mean that you
have lost your rights forever?
>Deal with it, or leave
I will do as I please because I do not take orders from you
or anyone else.
FYI, this country was founded when the colonies VOLUNTARILY
formed a union. No one would have joined without the right of
secession because everyone feared a powerful central authority.
Lincoln was a major tyrant who broke that agreement, abolished free
speech by jailing dissenters, instituted the military draft, and on
and on. Sic Semper Tyrannus (So Always To Tyrants)
He did free the slaves which was good but now we are all slaves to an
all powerful central authority.
Rich Eramian aka freeman at shore dot net
------------------------------
From: "kroesjnov" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 6 Mar 2001 21:05:42 +0100
"Mxsmanic" <[EMAIL PROTECTED]> wrote in message
news:CmLo6.38761$[EMAIL PROTECTED]...
> "kroesjnov" <[EMAIL PROTECTED]> wrote in message
> news:97vqse$2pdsj$[EMAIL PROTECTED]...
>
> > Be happy...
>
> Is protection the only thing you need to be happy?
Nope
But the protection off the police force, or any other agency, that they give
me from terrorists, makes me feel saver, which in turn makes me happier.
This is nut the only reason why one should be happy, just another gallon in
the bucket...
"Wisdom lies not in obtaining knowledge, but in using it in the right way"
kroesjnov
email: [EMAIL PROTECTED] (remove nov to reply)
UIN: 67346792
pgp fingerprint: 4251 4350 4242 7764 80DA DB1C E2B2 850A DF15 4D85
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 12:12:30 -0800
Eric Lee Green wrote:
>
> On Tue, 06 Mar 2001 03:45:02 -0800, Anthony Stephen Szopa
> <[EMAIL PROTECTED]> wrote:
> >Now when you run it you can see it go to the hard drive 27 times
> >just by watching your hard drive LED access light and perhaps by
> >listening to your hard drive as well. Choose a file about 2 - 6
>
> Please note that the hard drive LED for SCSI drives does not do what
> you think it does. It lights up whenever there is SCSI bus activity to
> the drive, whether or not the drive is actually engaged in reading or
> writing at a given time. For example, if a track is already in the
> drive's internal buffer, all operations take place upon the buffered
> track, not upon the actual disk media. The disk media does not get
> written to until it rotates around to the "dirty" sectors, which could
> be a few milliseconds even with the fastest hard drives. For small
> files in fast machines, this means that you're operating entirely upon
> the SCSI drive's internal buffers, even disregarding OS-level buffering.
>
> I do not know enough about IDE hardware to tell you what it does. I do
> know that all modern IDE drives include a buffer, but whether it is
> used in the same manner or not is not something I know about. (Unlike
> you, I do not make sweeping statements about subjects that I am not
> knowlegable about).
>
> Your particular OS may or may not have disk I/O buffering. Windows 95
> did not, as far as I know, except as a third-party add-on. Windows 98
> supposedly does. I say "supposedly" because I have not noticed it
> doing anything -- I get better I/O performance out of Windows 98 by
> attaching to a Samba fileshare on a Linux server and letting Samba
> handle disk buffering. All versions of Windows NT and Windows 2000
> have a VMS-style disk I/O buffering scheme that is somewhat similar to
> the classic Unix-style disk I/O buffer scheme as described in the
> "Bach Book" or the Linux source code, except with more
> optimizations. In addition, NTFS is a semi-transactional journalling
> filesystem that probably does not do what you think it's doing --
> i.e., it is probably doing the journalling that I mentioned (does not
> write the replacement data to the old sector, but rather, writes it to
> a different sector, then does a "commit" to release the old sector
> only after it has verified that the replacement block is properly on
> disk). Since I do not have the source code to NTFS I cannot verify that
> this is what NTFS does, but this is what journalling filesystems do, and
> Microsoft claims that NTFS is a journalling filesystem.
>
> In any event, if you run your software on Windows 95 you may indeed get
> the effect you desire. That does not help people who run it on Windows NT
> or Windows 2000, and it may or may not help people who run it on Windows 98+.
> And will not help people who are trying to erase smaller files on SCSI
> drives (where the blocks in the file fit inside the drive's buffer cache).
> It may not even help people trying to erase smaller files on IDE drives,
> though I'm not familiar enough with how IDE drives work to tell you
> (I know a very slight bit about how ATAPI works -- ATAPI is SCSI-like
> extensions to IDE -- but only in the context of IDE tape drives, which
> is not useful here).
>
> --
> Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
> AVOID EVIDENCE ELIMINATOR -- for details, see
> http://badtux.org/eric/editorial/scumbags.html
>
> -----= 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! =-----
Almost entirely I have not been making sweeping statements and if I
had I don't believe I said that what I was saying was in fact fact
mostly.
Mostly my statements have been further inquiries about what most of
you all have been saying. And I have been questioning what you have
been saying with some considered thoughts.
I have been pointing things out with reference to what is being said
that I think needs closer scrutiny.
And for me anyway, if has been worth the effort a couple of times.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Super strong crypto
Date: 6 Mar 2001 20:13:28 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Douglas A. Gwyn wrote:
>Since, as you yourself said, "the above attack clearly works only
>under a very restrictive threat model, and I don't think it is
>going to be feasible too often in practice," I'm not too worried [...]
Well, let me make two claims that might sound mutually exclusive and
then argue why they are not.
- Chosen-text attacks seem unlikely to endanger most real-world systems.
- The existence of a chosen-text attack seems like an undesirable
property of a cryptosystem.
How can I argue both of these positions in the same breath? Here's how.
First: "Attacks always get better". History shows that chosen-text
attacks are found first, then improvements to make them work under a
known-text attack model may be found later. After all, chosen-text
attacks are easier for the cryptanalyst; finding known-text or
ciphertext-only attacks usually requires more mental exertion. So,
it would seem prudent to err on the side of caution and assume that,
if with our modest resources we can find a chosen-text attack today,
perhaps next year someone with more persistence and a larger budget
will find a known-text attack.
Second: Chosen-text attacks are a "certificational weakness". Which
would you rather have, a system with no known defects (e.g., AES) or
a system with known defects (e.g., the proposal Gwyn outlined)? Even
if it is not at all clear that those defects will have much impact on
real-world systems, personally I'd prefer to stick with the system
without any known defects, all else being equal. Why take chances?
Third, and perhaps most importantly: With modern systems, chosen-text
attacks are becoming more practical than you might think. Take IPSEC
with per-host keying, for instance. The OS will be multiplexing messages
from many mutually-distrusting users across a single crypto-session
(and thus a single encryption key). If there are chosen-plaintext
attacks on the cipher, one user can choose text of his choosing and
get it encrypted by the OS to mount the chosen-plaintext attack, and
then recovering the key reveals all data sent by other users. If there
are chosen-ciphertext attacks on the cipher, one user can transmit
forged ciphertext of his choosing to the OS and arrange to receive
the decryption; if the cipher is insecure against chosen-ciphertext
attack, this may allow one malicious user to learn the encryption key
and read the traffic of all other users. (Credit for this pointing
out this scenario belongs to Steve Bellovin.)
Therefore, it seems that the requirements of my attack for chosen text
may not be all that impractical at all, and I do not think chosen-text
attacks should be taken lightly,
(Of course, my attack also required funny assumptions about synchronization,
which in practice may the real barrier from applying the attack to real
systems. Still, this seems like an unreliable basis to rest the security
of our system on.)
In conclusion: For a system billed as "super-strong", the mere possibility
of chosen-text attacks seems undesirable, even if this possibility is
primarily theoretical in nature.
------------------------------
From: "kroesjnov" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 6 Mar 2001 21:14:29 +0100
> I just hope he never was in a position to affect how nuclear codes
> are loaded in missles
Something alike, check it out:
http://www.thestandard.com/article/display/0,1151,22589,00.html
May not have as much as an impact as getting the nuclear codes, but yet, it
does have a large impact...
"Wisdom lies not in obtaining knowledge, but in using it in the right way"
kroesjnov
email: [EMAIL PROTECTED] (remove nov to reply)
UIN: 67346792
pgp fingerprint: 4251 4350 4242 7764 80DA DB1C E2B2 850A DF15 4D85
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: PKI and Non-repudiation practicalities
Date: Wed, 7 Mar 2001 07:13:53 +1100
I've always taken the view that non-repudiation, at a commercial level, is
implementation dependent, regardless of the underlying technology.
Certificates/PKI use a shared 'secret' such as a password or biometric
The 'weakest link' rule means that shared secrets/passwords are the thing to
focus on for really getting PKI secure, even after the expertise devoted to
PKI comes up with the answer to the PKI part of the puzzle.
In the meantime, there's always the proven commercially viable methodologies
...
Lyal
Mark Currie wrote in message <3aa4ef99$0$[EMAIL PROTECTED]>...
>In article <Gt4p6.4064$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>>
>>
>>Anne & Lynn Wheeler wrote in message ...
>>>"Lyalc" <[EMAIL PROTECTED]> writes:
>>>
>>>> No one buys security. They do pay for things that improve their
>>business,
>>>> short and long term.
>>>> PKI merely replicates password based processing. Remember, the private
>>key
>>
>>[snip]
>>
>>>
>>>i would have said that public/private key authentication does a little
>>>bit better job than secret-key/pin authentication .... since it
>>
>>>eliminates some issues with the sharing of a secret-key.
>>
>>
>>The difficulty in conventional PKI is ensuring the correct Root public key
>>is distributed, and not superceded or supplanted in the recipients system.
>>Otherwise, the "CA in the middle" (tm) attack occurs. This has similar
>>complexity and cost as the secret key distribution issues. And secret
key
>>distribution is no longer as hard or expensive as it used to be.
>>
>
>PKI also introduces more complexity WRT certificate validation and
revocation.
>On many user payment platforms it is impractical to cope with certificate
>validation checking including CRL syncronisation. In order to address this,
the
>PKI industry has provided support such as certificate validation servers
and
>OCSP responders. However these in turn require trust relationships with the
>user platform hence introducing another level of complexity.
>
>>>hardware tokens can be accessed with pin/secret-key and then do
>>>public/private key digital signatures for authentication ... but there
>>>is no "sharing" of the pin/secret-key.
>>
>>
>>True. Though PIN entry is still required, a point of compromise unless
more
>>wrapping technology is used. Add appropriate 'wrapping technology' and
you
>>end up with a new version of legacy systems called ATMs with new internal
>>encryption. A bit self-defeating, I think.
>>
>>>taken to the extreme, biometrics is a form of secret key .... and
>>>while compromise of pin/secret-key in a shared-secret infrastructure
>>>involves issuing a new pin/secret-key ... current technology isn't
>>>quite up to issuing new fingers if a biometric shared-secret were
>>>compromised (aka there are operational differences between
>>>shared-secret paradigms and non-shared-secret paradigms ... even if
>>>both have similar pin/secret-key/biometrics mechanisms).
>>
>>
>>Exactly. A trusted, tamper-resistant Biometric verifier engine seems
>>required.
>>
>
>Best would be to incorporate all three elements: what you have (portable
secure
>hardware); what you know (pin/passphrase); what you are (biometric). These
>elements can be provided in both a shared secret key system as well as in a
>public key system. The main difference is that the public key based system
adds
>the potential to provide non-repudiation which was the main subject of my
>original post. There are many issues that can be debated around key
>management in symmetric and asymetric systems as can be seen from above
>discussions. However, a shared secret key system can never support
>Non-repudiation by its very nature (sharing). An Asymmetric key system at
least
>provides support at the cryptography level, but as mentioned in my original
>post, it only solves part of the problem.
>
>
>Mark
>
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: PKI and Non-repudiation practicalities
Date: Wed, 7 Mar 2001 07:15:16 +1100
Yep, there is a massive phase out challenge for the migration away from
single DES to 3DES or AES.
Anne & Lynn Wheeler wrote in message ...
>"Lyalc" <[EMAIL PROTECTED]> writes:
>>
>> Not sure I, or the GAO agrees with that in all cases. The recent GAO
report
>> (Advances and Remaining Challenges to Adoption of Public Key
Infrastructure
>> Technology, GAO-01-277) outlines some enormous cost and complexity
>> challenges. $170m merely to make a few legacy applications operate with
PKI
>> seems a lot, when the PKI itself stills needs to be built.
>
>I would expect many are legacy systems that lack authentication
>... claim was for legacy applications that currently have some form of
>authentication process. The estimate is that the cost of replacing
>current shared-secret authentication is well under 5% of the cost of
>the legacy system i.e. a $500m legacy system would possibly cost $25m
>to modify for public key authentication ... the majority of that tends
>to be because of various Q&A and integration issues, if the
>modification can be merged into some ongoing modification cycle, that
>could further be reduced.
>
>the issue tends to be that a front-end PKI for pilots and test
>... involving a small number of accounts can be shown to be less
>costly than modifying the production system and business processes
>... especially if there are various kinds of risk acceptance having
>the PKI information out of synch with the production account
>information.
>
>There tends to be a trade-off attempting to scale to full production
>where the costs of a duplicate PKI account-based infrastructure has to
>be evolved to the same level as the production account-based
>infrastructure ... along with the additional business processes
>maintaining consistency between the PKI accounts and the production
>accounts. Full scale-up might represent three times the cost of the
>base legacy infrastructure, rather than <5% of the legacy
>infrastructure.
>
>That is independent of the costs of a hardware token ... which could
>be the same in either an account-base deployment or a PKI-based
>deployment (and i'm working hard at making the costs of producing such
>a token as low as possible while keeping the highest possible
>assurance standard). There is a pending $20b dollar upgrade issue for
>the existing ATM infrastructure that is going to be spent anyway
>(because of the DES issue). When that is spent, the difference between
>whether or not public-key support is also included in the new swap-in
>is lost in the noise of the cost of the overall swap. Existing ATM
>problem is further confounded that there are master DES keys in
>addition to the individual DES-key infrastructure (representing
>significant systemic risks, similar to CA root keys) ... the back-end
>cost savings with elimination of systemic risk and shared-secrets more
>than offset the incremental front-end costs of adding public key
>technology in a swap-out that is going to have to occur anyway.
>
>A trivial example would be RADIUS ... which possibly represents
>99.999999% of existing client authentication events around the world
>on the internet. A public-key upgrade to RADIUS is well under a couple
>hundred thousand ... resulting in a RADIUS that supports multiple
>concurrent methods of authentication with the connecting authority be
>able to specify authentication protocol on an account by account
>basis.
>
>--
>Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
** 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
******************************
