Cryptography-Digest Digest #827, Volume #13 Wed, 7 Mar 01 10:13:01 EST
Contents:
Re: One-time Pad really unbreakable? (Tim Tyler)
Re: One time authentication ("Henrick Hellstr�m")
IDEA test vectors ("rowan")
Applied Cryptography - SCHNEIER ("Latyr Jean-Luc FAYE")
Re: AES and DES ("Latyr Jean-Luc FAYE")
Re: AES and DES ("Latyr Jean-Luc FAYE")
Super-strong crypto......................(As if). (Keill_Randor)
Re: Applied Cryptography - SCHNEIER ("Jakob Jonsson")
Re: One-time Pad really unbreakable? (John Savard)
Re: AES and DES (John Savard)
Re: One-time Pad really unbreakable? ("Mxsmanic")
Re: One time authentication ("Scott Fluhrer")
Problem with BBS implementation ("Dobs")
Re: PKI and Non-repudiation practicalities (Vernon Schryver)
Question re Asymmetric Encr'n ("Arnold Shore")
Re: PKI and Non-repudiation practicalities (Anne & Lynn Wheeler)
Re: Problem with BBS implementation ("Tom St Denis")
Re: PKI and Non-repudiation practicalities (Anne & Lynn Wheeler)
Re: Question re Asymmetric Encr'n ("Tom St Denis")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 7 Mar 2001 11:00:09 GMT
Mxsmanic <[EMAIL PROTECTED]> wrote:
: One-time pads are indeed unbreakable, and provably so.
Only in mathematical never-never land. The OTP "specification" does not
offer any prescription for the generation of suitable random numbers -
and since no such recipe is likely to be forthcoming, the "provably
secure" OTP will never make it off the paper and into the real world.
For a summary of the problems involved, see:
http://www.io.com/~ritter/NEWS2/OTPCMTS.HTM
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Destroy Microsoft.
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: One time authentication
Date: Wed, 7 Mar 2001 12:26:45 +0100
"Tim Tyler" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> The OTP has long been regarded as providing "perfect secrecy" - assuming
> a shared unguessable stream exists.
>
> However, the OTP provides no authenticatio - it is subject to
> bit-flipping attacks (unless message signatures are used) and
> a known plaintext recovers the entire key.
>
> I have heard that there is an authentication scheme that works on a
> similar principle to the OTP - rather than relying on "confusion"
> sequences.
>
> While not providing "perfect" authentication, I hear this offers the
> guarantee that the recipient is who they claim to be, and that their
> message has not been tampered with with a probability of failure of
> 1/2^N where N is the number of bits of signature employed.
PCFB-mode does that.
> Again, this is subject to the proviso that a siutably "random" shared
> secret is available.
>
> I have not succeeded in locating further details of such a "perfect"
> signature scheme. Can anyone provide a pointer to something like this?
> Or offer a brief description?
http://www.streamsec.com/pcfb.htm
Comments and suggestions are appreciated.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "rowan" <[EMAIL PROTECTED]>
Subject: IDEA test vectors
Date: Wed, 7 Mar 2001 12:01:49 -0000
Has anyone got IDEA test vectors with output after each round? I have one
for after all the encryption but I'd like some that are more specific.
------------------------------
From: "Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]>
Subject: Applied Cryptography - SCHNEIER
Date: Wed, 7 Mar 2001 12:20:27 -0000
Hi
I bought one printed copy of the book Applied Cryptography in a Book shop.
But I have to share it with four other people. So I think that it can be
easier for us to have it in PDF and put it in our Intranet.
Where can I buy the PDF version of the book
Thanks in advance.
Latyr
--
Latyr Jean-Luc FAYE
http://faye.cjb.net
------------------------------
From: "Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]>
Subject: Re: AES and DES
Date: Wed, 7 Mar 2001 12:23:45 -0000
Thank you.
I have downloaded the HAC and bought the AC of Bruce Schneier
Latyr
--
Latyr Jean-Luc FAYE
http://faye.cjb.net
"Tom St Denis" <[EMAIL PROTECTED]> a �crit dans le message news:
9m6p6.30932$[EMAIL PROTECTED]
>
> "Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Hi
> >
> > As I told in my previous submission, I am begining in Crypto.
> > I red some stuff about AES that will replace DES.
> > Can somebody explain me the differecences and the advantages.
> > A brief dicuss or some useful links with this informations.
> > Regards
>
> AES is advanced :-o
>
> I would suggest you read up on background before becomming politically
> influenced. Hmm Bruce Schneier has a wickedly cool list of papers
available
> check out his site (http://www.counterpane.com/labs.html). I would also
> pick up a copy of his book or the HAC (the url for HAC has been posted
about
> 2^2000 times this month so it's easy to find).
>
> Tom
>
>
------------------------------
From: "Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]>
Subject: Re: AES and DES
Date: Wed, 7 Mar 2001 12:24:33 -0000
Thank you for these informations
--
Latyr Jean-Luc FAYE
http://faye.cjb.net
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> a �crit dans le message
news: [EMAIL PROTECTED]
> [EMAIL PROTECTED] (Latyr Jean-Luc FAYE) wrote in
> <[EMAIL PROTECTED]>:
>
> >Hi
> >
> >As I told in my previous submission, I am begining in Crypto.
> >I red some stuff about AES that will replace DES.
> >Can somebody explain me the differecences and the advantages.
> >A brief dicuss or some useful links with this informations.
> >Regards
> >
> >Latyr
> >
> >
> >
>
> A good place to learn about crypto is to read certain books
> like the puzzle palace and the code breakers. Encryption is fun
> since it is one of the black arts where government is always trying
> to mislead the people. You should never fully trust one source for
> your data or encryption needs. If I was you I would read various
> sources. However as weak as many systems tend to be if you use
> systems in series that add no information you would go a long ways
> to haveing a more secure system. I only know of 2 systmes that don't
> add information to a file. Matts version of Rijndeal adds no information
> and does the right kind of compression as a first pass. You could use
> his coded. Followed by one of mine like scott16u or scott19u. After
> that then you could use one of the methods the so called crypto gods
> claim is safe such as BLOW FISH or TWO FISH or what ever smelly product
> people talk you into.
>
> 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: Keill_Randor <[EMAIL PROTECTED]>
Subject: Super-strong crypto......................(As if).
Date: Wed, 07 Mar 2001 11:55:10 +0000
The only way to have a secure encryption system, (and uncrackable), is to make sure
that the only way to crack an encrypted peice of data - (or any other peice of
information - (I just concentrate on computing)), is to run through every peice of
data known to a computer - (Even the NSA won't be able to deal with that).
I.e. the only secure system, is one that allows you to encrypt any peice of data (or
stream), using any other peice / peices or stream / streams of data.
(Like what mine does, but I don't think it's a good idea to post it, somehow..:).
(I'm trying to deal with GCHQ, but they don't seem to want to know...(Idiots))). The
word random shouldn't really be needed...
Keill Randor
[EMAIL PROTECTED]
_______________________________________________
Submitted via WebNewsReader of http://www.interbulletin.com
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: Applied Cryptography - SCHNEIER
Date: Wed, 7 Mar 2001 14:05:04 +0100
Go to http://www.counterpane.com/contact.html and ask Bruce Schneier
directly, preferably (I presume) via the form.
Jakob
"Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> Hi
>
> I bought one printed copy of the book Applied Cryptography in a Book
shop.
> But I have to share it with four other people. So I think that it can be
> easier for us to have it in PDF and put it in our Intranet.
> Where can I buy the PDF version of the book
> Thanks in advance.
> Latyr
>
> --
> Latyr Jean-Luc FAYE
> http://faye.cjb.net
>
>
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: One-time Pad really unbreakable?
Date: Wed, 07 Mar 2001 13:07:06 GMT
On Wed, 7 Mar 2001 11:00:09 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote, in
part:
>Only in mathematical never-never land. The OTP "specification" does not
>offer any prescription for the generation of suitable random numbers -
>and since no such recipe is likely to be forthcoming, the "provably
>secure" OTP will never make it off the paper and into the real world.
In that case, Las Vegas ought to find another industry with which to
support itself.
In other words: here is a counterexample - a sequence of physically
generated random numbers that cannot effectively be predicted. The
series of numbers generated by throwing dice and the like is indeed
sufficiently clearly unpredictable that the mathematical proof of the
OTP is still highly relevant - even if the unbreakability of a "real"
OTP is no longer at the absolute level of truth of a mathematical law,
it is still quite obviously at a high enough level of confidence to
warrant no concern over attacks based on using the previous key to
determine the position of all the molecules in the room and so on.
Of course, key distribution can be compromised, but that can happen to
any system.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES and DES
Date: Wed, 07 Mar 2001 13:10:29 GMT
On Tue, 6 Mar 2001 14:00:05 -0000, "Latyr Jean-Luc FAYE"
<[EMAIL PROTECTED]> wrote, in part:
>As I told in my previous submission, I am begining in Crypto.
>I red some stuff about AES that will replace DES.
>Can somebody explain me the differecences and the advantages.
>A brief dicuss or some useful links with this informations.
Well, the idea is basically that the algorithm picked as the AES is
more efficient (takes less time to encrypt something) than DES,
particularly when done on a computer instead of on a special chip, and
it is also more secure, partly because it encrypts 128 bits of data at
a time instead of 64 bits, but mostly because it uses a key of 128
bits (or more) instead of 56 bits and is designed to fully use all of
that key.
There is more detailed technical information about the algorithm
(Rijndael) chosen as the AES and about DES on my web site.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Wed, 07 Mar 2001 13:41:43 GMT
Radioactive decay is a source of truly random numbers.
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Mxsmanic <[EMAIL PROTECTED]> wrote:
>
> : One-time pads are indeed unbreakable, and provably so.
>
> Only in mathematical never-never land. The OTP "specification" does
not
> offer any prescription for the generation of suitable random numbers -
> and since no such recipe is likely to be forthcoming, the "provably
> secure" OTP will never make it off the paper and into the real world.
>
> For a summary of the problems involved, see:
> http://www.io.com/~ritter/NEWS2/OTPCMTS.HTM
> --
> __________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ Destroy
Microsoft.
>
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: One time authentication
Date: Wed, 7 Mar 2001 05:35:32 -0800
Henrick Hellstr�m <[EMAIL PROTECTED]> wrote in message
news:9855ud$f0v$[EMAIL PROTECTED]...
> "Tim Tyler" <[EMAIL PROTECTED]> skrev i meddelandet
> news:[EMAIL PROTECTED]...
> > The OTP has long been regarded as providing "perfect secrecy" - assuming
> > a shared unguessable stream exists.
And (of course) the same stream is never used twice...
> >
> > However, the OTP provides no authenticatio - it is subject to
> > bit-flipping attacks (unless message signatures are used) and
> > a known plaintext recovers the entire key.
> >
> > I have heard that there is an authentication scheme that works on a
> > similar principle to the OTP - rather than relying on "confusion"
> > sequences.
> >
> > While not providing "perfect" authentication, I hear this offers the
> > guarantee that the recipient is who they claim to be, and that their
> > message has not been tampered with with a probability of failure of
> > 1/2^N where N is the number of bits of signature employed.
Actually, that guarantee would be as close to "perfect" as you can get.
Given you have an authentication method that takes an arbitrary M bit
plaintext as input, and produces an authenticated output with M+N bits, then
the attacker can guess an arbitrary message of M+N bits, and have a
probability at worse 1/2^N of guessing the message for some original M bit
plaintext.
> PCFB-mode does that.
Are you sure? It would appear that a computationally unbounded adversary
could bruteforce the block cipher key, and that would appear allow the
possibility (given one authenticated message) of forging another. And, the
computationally unbounded adversary model appears to be the one the OP is
worrying about
>
>
> > Again, this is subject to the proviso that a siutably "random" shared
> > secret is available.
> >
> > I have not succeeded in locating further details of such a "perfect"
> > signature scheme. Can anyone provide a pointer to something like this?
> > Or offer a brief description?
Well, there's been some work on hashing methods based on "Universal
Hashing", where the message is combined with a long secret in a manner such
that two distinct messages have a provably small probability of hashing to
the same value. Now, research in this area has not been in using the
authentication bits as efficiently as possible, instead, they have been
trying to come up with methods that use authentication bits relatively
efficiently, and are practical in real use (that is, are efficient, and
reuse the same shared secret over several messages). However, if you are
willing to give up the secret-reuse, I suspect that some of these techniques
can be adapted to have the perfect efficiency you are looking for.
http://www.cs.ucdavis.edu/~rogaway/umac/
http://cr.yp.to/papers.html (Re: "Floating-point arithmetic and message
authentication")
--
poncho
------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: Problem with BBS implementation
Date: Wed, 7 Mar 2001 15:41:26 +0100
Hello,
I am trying to implement blum blym shub generator , however I came accross a
problem. As some of U might know in BBS generator I have to generate two
large random prime p and q, each congruated to 3 moulo 4, and compute
n=pq.Then select integer s( the seed) in the interval [1,n-1] such that
gcd(s,n)=1.
And here is the problem.
It is difficult to find such an s that it will have gcd witch n equal to 1
(gcd(s,n)=1.)
Everythink is ok for small primes as p=11 and=7, but if I will take p=104683
q=103483(large primes as it shoul be), than computer is starting to look for
it and it could take ages.
My cource code is like this:
#include "stdio.h"
#include "iostream.h"
#include "stdlib.h"
#include "time.h"
#include "conio.h"
int gcd (int x, int y)
{
int g;
if (x<0)
x=-x;
if (y<0)
y=-y;
g=y;
while (x>0)
{
g=x;
x=y%x;
y=g;
}
return g;
}
int main(int argc, char* argv[])
{
int p,q,l,n,s;
int xprev,xnext;
int z;
char wynik[100];
cout << "The program is generating random numbers" << endl ;
do
{
cout << "Write first prime: ";
cin >> p;
if (((p-3)%4) != 0)
cout << "Given prime is not congruent to 3 mod 4" << endl;
}while(((p-3)%4) != 0);
do
{
cout << "Podaj druga liczbe pierwsza: ";
cin >> q;
if (((q-3)%4) != 0)
cout << "Given prime is not congruent to 3 mod 4" << endl;
}while(((q-3)%4) != 0);
cout << "Give the length of the random number U want to generate: ";
cin >> l;
n=p*q;
srand( (unsigned)time( NULL ) );
do
{
s = 1+rand()%(n-1);
cout << "a";
} while (gcd(s,n)==1);
// } while ((s%p)!=0 && (s%q)!=0);
// sprawdzic to
xprev = (s*s)%n;
for (int i=1; i<=l; i++)
{
xnext = (xprev*xprev)%n;
xprev = xnext;
z = xnext & 0x00000001;
cout << z;
}
getch();
return 0;
}
Best Regards, Michal
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: PKI and Non-repudiation practicalities
Date: 7 Mar 2001 08:02:36 -0700
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> ...
>The weakest link is still access to the secret. An attacker merely
>needs to get access to a token and open it up, and avoid the tamper
>resistance, and he has the secret. This is conceptually no different
>from beating a password out of the user with a rubber hose.
> ...
>The difference between theory and practice is that in theory, theory and
>practice are identical, but in practice, they are not.
In the spirit of that last sentence, judging from current practice,
the weakest link is in associating the secret or whatever with the
entity to be authenticated. The Verisign and Thwate systems for
authenticating you when you submit a key to be associated with a domain
is not exactly strong. The cost for a bad guy to pretend to represent
any except one of the Fortune 50 is surely not much more than the cost
that Verisign charges for a year of PKI service. It's not as if a
Dun & Bradstreet DUNS number or "articles of incorporation, partnership
papers, business license, or fictitious business license" are unforgeable
or even difficult to forge proofs of identity.
Pretending to be one of the Fortune 50 is a different kind of problem.
Then there are holes that result from the use of unsigned etc. UDP/IP by
the DNS, the history of DNS implementation weaknesses, and that the fact
DNSSEC is not in use.
Vernon Schryver [EMAIL PROTECTED]
P.S. Get Verisign's "Secure Site Services" guide starting at
http://verisign.com/products/site/index.html When deciding which email
address to submit to get those instructions, recall that Versign has a
continuing history (as did Network Solutions) of using all available
email addresseses as targets of interesting marketing information.
------------------------------
From: "Arnold Shore" <[EMAIL PROTECTED]>
Subject: Question re Asymmetric Encr'n
Date: Wed, 7 Mar 2001 10:04:55 -0500
I'm using a product that's based on CAST-128 and Elliptic Curve
implementation, and will appreciate information on how these work.
Specifically, I see that given fixed values for a private key and cleartext,
the encrypted output varies - but nonetheless decrypts correctly.
How can this be? Apparently, there's some other input - how acquired?
Will appreciate any reply, including a reference URL/text that might be
suitable for the non-mathematician. Thanks, all.
Arnold Shore
Annapolis, MD USA
------------------------------
Subject: Re: PKI and Non-repudiation practicalities
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Wed, 07 Mar 2001 15:04:20 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> Even if your authentification is via a token, which in turn is activated
> via biometrics, there still is a secret. It's the data in the token!
> If all tokens were identical (allowing for them needing different
> biometrics to activate), they would be useless. The token needs to
> contain something to uniquely identify it electronically, and
> authenticate that identity. Identification is simple; give each token a
> unique id. Authentification, however, requires some sort of secret --
> either a private key, or a shared secret.
>
> The weakest link is still access to the secret. An attacker merely
> needs to get access to a token and open it up, and avoid the tamper
> resistance, and he has the secret. This is conceptually no different
> from beating a password out of the user with a rubber hose.
the difference is whether the secret is known by only one person or a
lot of people (i.e. which also represents the semantic difference
between "secret" and "shared-secret").
in the "shared-secret" scenerios ... the "shared-secret" are
registered someplace and are subject to harvesting ... aka effectively
credit card numbers are treated as "shared-secrets" (witness all the
stuff written about protecting master credit-card databases at
merchant servers). Harvesting of master database files of
shared-secrets is significantly simpler than defeating tamper-evident
and/or beating somebody with rubber hose.
eliminating shared-secrets was the point of the discussion ... and
distinquishing shared-secret infrastructures vis-a-vis secret
infrastructures, along with the difference in fraud ROI; aka a
scenerio where somebody can electronically steal 100,000 shared
secrets in a couple of minutes ... vis-a-vis taking hrs to steal one
secret significantly changes the risk, exploit, and fraud
characteristics of an infrastructre. If it is possible to deploy a
"secret" infrastructure for approximately the same cost as a
"shared-secret" infrastructure and the "secret" infrastructure reduces
the fraud ROI by five to ten orders of magnitude (i.e. it takes a
thousand times as much effort to obtain 1/100000 useable fraudulant
material).
> --
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
random ref
http://www.garlic.com/~lynn/2000b.html#22
the other part of the scernio ... is financial and various other
commercial infrastructures strongly push that in shared secret
scenerios that the same shared secret can't be shared across multiple
different organizations with multiple different objectives i.e. an
employer typically has strong requlations against "sharing" a
corporate access password shared-secret with other organizations (i.e.
using the same shared-secret password to access the corporate intranet
as is used to access a personal ISP account and misc. random
webservers around the world).
I would guess that a gov. agency would not be too please if an
gov. agency employee specified their employee access (shared-secret)
password ... as an access (shared-secret) password for some webserver
registration site in some other country.
However, it is possible to specify a public key in multiple places and
employees of one organization couldn't use the harvesting of the
public keys at that organization for penetration of other
organizations.
Furthermore, the rubber-hose approach is going to take quite a bit
longer to obtain a million secrets and hardware tokens that correspond
to the registered public keys (as compared to some of the
shared-secret harvesting techniques). Lets say that the rubber-hose
approach takes something like two days per ... planning, setup,
capture, executing, etc and involves minimum of two people. That is
four person days per secret. For a million secrets using the rubber
hose method, it then takes four million person days, or 10,959 person
days. By comparison some of the shared-secret harvesting techniques
can be done in a couple person weeks for a million shared-secrets.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Problem with BBS implementation
Date: Wed, 07 Mar 2001 15:07:54 GMT
"Dobs" <[EMAIL PROTECTED]> wrote in message news:985hnk$h0p$[EMAIL PROTECTED]...
> Hello,
> I am trying to implement blum blym shub generator , however I came accross
a
> problem. As some of U might know in BBS generator I have to generate two
> large random prime p and q, each congruated to 3 moulo 4, and compute
> n=pq.Then select integer s( the seed) in the interval [1,n-1] such that
> gcd(s,n)=1.
> And here is the problem.
> It is difficult to find such an s that it will have gcd witch n equal to
1
> (gcd(s,n)=1.)
> Everythink is ok for small primes as p=11 and=7, but if I will take
p=104683
> q=103483(large primes as it shoul be), than computer is starting to look
for
> it and it could take ages.
The product is 34 bits long which is why it won't work. You must use a big
integer package to use large numbers.
BTW what they mean by "large prime" is >= 512 bits in length not 17 bits...
<snip>
Tom
------------------------------
Subject: Re: PKI and Non-repudiation practicalities
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Wed, 07 Mar 2001 15:07:58 GMT
"Lyalc" <[EMAIL PROTECTED]> writes:
> True, although operating support costs may theoretically be double or more,
> since the legacy method can't be switched off anytime soon, at least until
> the whole world comes into a steady, single state condition. Esxpecially
> for payment cards.
the card/crypto part of the operating costs is rather trivial part of
the overall operating & total business process costs. biggest issue is
the deployment of technology in such a way that old & new technologies
can concurrently co-exist during the transition phase, while all
technologies continue to utilize the same operating & business process
infrastructures.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Question re Asymmetric Encr'n
Date: Wed, 07 Mar 2001 15:09:29 GMT
"Arnold Shore" <[EMAIL PROTECTED]> wrote in message
news:987lij$9cv$[EMAIL PROTECTED]...
> I'm using a product that's based on CAST-128 and Elliptic Curve
> implementation, and will appreciate information on how these work.
> Specifically, I see that given fixed values for a private key and
cleartext,
> the encrypted output varies - but nonetheless decrypts correctly.
>
> How can this be? Apparently, there's some other input - how acquired?
Well most likely CAST is used in a chaining mode such as CBC where the
InitialVector (IV) is different for each ciphertext message you make.
If you want to learn about the CAST block cipher look up Carlise's (sp?)
papers on Bruce Schneiers lists of cool papers
(www.counterpane.com/labs.html).
Tom
------------------------------
** 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
******************************
