Cryptography-Digest Digest #458, Volume #11 Fri, 31 Mar 00 22:13:00 EST
Contents:
Re: Blowfish (Thomas Luzat)
Re: Proof of Identity (proton)
PGP Strength ("Screech")
Re: Blowfish ("Joseph Ashwood")
Re: Does anybody know of a secure FTP server? (Abid Farooqui)
Re: PGP Strength ("Joseph Ashwood")
Re: Chronometric Cryptography ("Dan Coyle")
Re: Chronometric Cryptography ("Dan Coyle")
Re: Q: Entropy (Bryan Olson)
Re: Re-seeding PRNG's in central key distribution systems (Bryan Olson)
Re: Proof of Identity ("Joseph Ashwood")
Re: LFSR's (Scott Nelson)
Re: new Echelon article (Jerry Coffin)
Re: Chronometric Cryptography (zapzing)
Re: Sunday People 26/3/2000: "FORGET YOUR PASSWORD... END UP IN JAIL" (Johnny Bravo)
Re: general questions on SSL certificates ("Lyalc")
----------------------------------------------------------------------------
From: Thomas Luzat <[EMAIL PROTECTED]>
Subject: Re: Blowfish
Date: Sat, 01 Apr 2000 01:38:23 +0200
Reply-To: [EMAIL PROTECTED]
On 29 Mar 2000 16:06:06 GMT, [EMAIL PROTECTED] (Mark Wooding)
wrote:
>Thomas Luzat <[EMAIL PROTECTED]> wrote:
>
>> I'm currently writing a Blowfish implementation and I am now wondering
>> which key sizes are allowed or given by "the Blowfish standard". I
>> only know that the key can be up to 448 bits in size... Do the key
>> sizes have to be multiples of 32 bits, 64 bits or something like that?
>
>The original definition specified that the key had to be a multiple of
>32 bits in length. However, the official test vectors, generated using
>Eric Young's reference implementation, understands keys whose length is
>any multiple of 8 bits (up to the maximum of 448 bits).
Smaller ones (or multiples of 1 bit...) don't work?
Thanks,
Thomas
------------------------------
From: proton <[EMAIL PROTECTED]>
Subject: Re: Proof of Identity
Date: Sat, 01 Apr 2000 03:51:51 +0200
Tom St Denis wrote:
>
> One idea [while sitting in algebra] for proving that you were present at
> something [or wrote a book, etc] is to embed simple system of equations
> like
>
> 11a + 3b - 9c = -927
> -5a - 11b + 7c = 1561
> ..
>
If they can edit the text, they could just take out the equation, right?
Also, whats to stop them from brute-forcing the sollution? Unless you
choose larger numbers ofcourse, in which case maybe you're better off
with some of the existing digital signature stuff?
/proton
------------------------------
From: "Screech" <[EMAIL PROTECTED]>
Subject: PGP Strength
Date: Thu, 30 Mar 2000 21:29:33 +0100
In the documentation for PGP, I read that it uses ZIP Compression to
generate smaller files and thus less predicatble contents, but does this not
mean tht the files will contain a standard Header(Not Nesscerily "PK" but
some sort of Table that that LZW Compression needs), or does it do this
outside the Encrypted Area, either way I cannot see the ZIP Compression
Improving the strength because using both you are able to predict the
contents even better in my mind.
For Example if there is a default header inside the file, it can then be
used to obtain parts of the key and thus reduce the time needed to perform a
brute force(Stupid Idea from what I read about its strength).
But if the data is stored outside of the Encrypted Area then the
Contents of the file have already been predicted.
Could somebody please correct me as I know I am wrong, but I would like to
know why please.
Screech
Email screech<at>krash<dot>f9<dot>co<dot>uk
PGP Key http://www.krash.f9.co.uk/screech/screech.asc
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Blowfish
Date: Fri, 31 Mar 2000 16:33:30 -0000
> Smaller ones (or multiples of 1 bit...) don't work?
You can always find a way to make it work, a very common way
(one of the AES finalists uses it) is to pad to a usable
value. For example if you have 33 bits pad with 0 to get 40
bits. Just document, document, document.
Joe
------------------------------
From: Abid Farooqui <[EMAIL PROTECTED]>
Subject: Re: Does anybody know of a secure FTP server?
Date: Sat, 01 Apr 2000 00:39:28 GMT
Jaime,
After just a not so detailed look at SPARC instruction set as compared to x86
instruction set, I think Paul Rubin might be right.
Are you sure that SPARC does integer multiplication faster than x86. The algorithms
used
to do multiplication or divison (for that matter) use bit shifting right or left
(depending on what you are doing) and x86 instruction set would apparently seem to
achieve it in fewer instructions than SPARC. But that is not the only thing that needs
to be looked at so I don't want to make a bet. Just that I think x86 architecture needs
to be thoroughly tested before claims of SPARC superiority can be made conclusively.
The
instruction set in x86 is such that one instruction will do more work than SPARC 2 or
sometimes even 3.
Sincerely,
Abid Farooqui
Jaime Cardoso wrote:
> Hy there.
>
> Sorry for the delay but, work waits for no one and my time to check Ng has been
> none.
>
> I see you already checked Rainbow, Has far as i know, this one is the faster SSL
> acelerator card I know and it can do wonders to your web site performance. You still
> need to have SSL enabled (at least with Netscape Enterprise Server, you do) but, Wy
> don't you pay a visit to http://www.rainbow.com and use theire e-mail to have them
> to answer your questions?
>
> I don't know a lot about theire offer because I don't wandle directly with them,
> when I have a business that they may join, I simply redirect the customer to my
> contact in the rainbow reseller in Portugal.
>
> If this card works with Apache? I realy don't know, i believe so because Apahe is
> quite an open platform (obvious, isn't it??) and it has quite a market share for
> this guys to ignore it. Just ask them, it's the easiest way.
>
> I wouldn't use a relational DB to store and authenticate my user's certificates, I
> woul realy recomend you use a Ldap Server. The most performant is Netscpe Directory
> Server but, if you don't have the budget to the big thing, you can get along well
> enouth with an Source free LDAP server.
>
> For the hardware, be aware, SSL uses a lot of calculations so, Intel should be the
> last resource HW platform for you. If you are going with an SSL server, you can
> increse your performance xfold (10X to 20X or more) if you use a CPU that is good
> with math (UltraSparc, Alpha or SGI).
>
> Bye
>
> //Jaime Cardoso
>
> PS. I would be honored if, when you came to Lisbon, you would mail me. Has I am
> doing a paper about criptography, I read this NG a lot, but this is the first thread
> i got involved but, like "them" I will keep watching :)))))
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: PGP Strength
Date: Fri, 31 Mar 2000 16:38:39 -0000
Yes using a known compression algorithm makes the encryption
weaker, the question is by how much. Given that you use
3DES, the required workload given a known plaintext is still
far enough beyond the estimated 80-bit limit that it can be
dismissed without much thought. It basically decreases the
amount of work by LESS than one would at first believe, look
to the DES challenge to see the strength of the building
block, even given a completely known plaintext (more data
than PGP offers) it took a brute force search of the key
space. The known bytes are a weakness but I do not believe
that those bytes form a significant weakness.
Joe
"Screech" <[EMAIL PROTECTED]> wrote in message
news:GpbF4.393$06.7772@wards...
> In the documentation for PGP, I read that it uses ZIP
Compression to
> generate smaller files and thus less predicatble contents,
but does this not
> mean tht the files will contain a standard Header(Not
Nesscerily "PK" but
> some sort of Table that that LZW Compression needs), or
does it do this
> outside the Encrypted Area, either way I cannot see the
ZIP Compression
> Improving the strength because using both you are able to
predict the
> contents even better in my mind.
>
> For Example if there is a default header inside the
file, it can then be
> used to obtain parts of the key and thus reduce the time
needed to perform a
> brute force(Stupid Idea from what I read about its
strength).
>
> But if the data is stored outside of the Encrypted
Area then the
> Contents of the file have already been predicted.
>
> Could somebody please correct me as I know I am wrong, but
I would like to
> know why please.
>
> Screech
>
> Email screech<at>krash<dot>f9<dot>co<dot>uk
> PGP Key http://www.krash.f9.co.uk/screech/screech.asc
>
>
------------------------------
From: "Dan Coyle" <[EMAIL PROTECTED]>
Subject: Re: Chronometric Cryptography
Date: Fri, 31 Mar 2000 19:13:43 -0600
"Gareth Howell" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Dan Coyle" <[EMAIL PROTECTED]> wrote:
>
> > Therefore allowing the application/object to determine the measure of
> > security at run-time instead of design-time. In addition, when
technology
> > changes, and more powerful machines are made that can resolve ciphertext
> > back into plaintext using brute force methods, the hardware which
executes
> > the cipher is the only component that what would need upgrading because
the
> > cipher would still take the same amount of time to execute, it just gets
> > more cycles to do it's job. I call this type of cipher, a Chronometric
> > cipher meaning a cipher whose security is measured by time.
> >
>
>
> I'm not quite sure what you mean by "more work".
> Does this mean encrypting it again with the same cipher ? (Like 3DES ?)
>
> Cheers
> Gareth
> --
> Have courage for the great sorrows of life and patience for the small
ones;
> and when you have laboriously accomplished your daily task, go to sleep in
> peace. God is awake."
> - Victor Hugo
>
Exactly.
The Prototype simply enters a loop, for the specified period of time, where
it encrypts and re-encrypts the message over and over until the specified
period of time is up, all the while changing the key with which it
re-encrypts the message. Then it Xors the Original Key, the Hash of the
User's Key, and the final key that is left after the loop terminates,
together. In order to decrypt the message the algorithm needs to know where
to start. In order to generate the final key from the Xored key, stored in
the message, the program needs the correct Users key. If a malicious user
enters an incorrect key, the program will start with the incorrect key, and
because the algorithm knows when to quit decrypting by comparing the key,
generated after each iteration of decrypting, with the Hashed User Key, it
is extremely unlikely (1 in 2^KeyBitSize) that any given iteration key will
be the correct key upon which to stop, once more even when it does hit the
correct terminating key, it will have used the wrong key with which to
decrypt the message and so it will be gibberish.
DC
------------------------------
From: "Dan Coyle" <[EMAIL PROTECTED]>
Subject: Re: Chronometric Cryptography
Date: Fri, 31 Mar 2000 19:23:25 -0600
"Bill Unruh" <[EMAIL PROTECTED]> wrote in message
news:8c3232$dcu$[EMAIL PROTECTED]...
> In <[EMAIL PROTECTED]> Gareth Howell
<[EMAIL PROTECTED]> writes:
>
> >"Dan Coyle" <[EMAIL PROTECTED]> wrote:
>
> >> Therefore allowing the application/object to determine the measure of
> >> security at run-time instead of design-time. In addition, when
technology
> >> changes, and more powerful machines are made that can resolve
ciphertext
> >> back into plaintext using brute force methods, the hardware which
executes
> >> the cipher is the only component that what would need upgrading because
the
> >> cipher would still take the same amount of time to execute, it just
gets
> >> more cycles to do it's job. I call this type of cipher, a Chronometric
> >> cipher meaning a cipher whose security is measured by time.
> >>
>
> The problem of course is that the cypher has no idea as to what the best
> hardware out there is. Ie, I could be running it on a 386, but that is
> certainly not "state of the art".
> The variable key size algorithms sort of do exactly what you are
> refering to. You can decide on what key size you want to use considering
> everyting you know about the state of the art. That way a 386 will do
> just as strong a crypto as a 1GH Athelon.
Aha, but it still takes longer for the 386 to apply the same level of crypto
as the 1 GHz Athlon. I realize that for a given level of security, a slower
computer will still have to do more work. But my goal with this algorithm,
is that for any given program, If I want the computer to take 1 second
encrypting a certain length piece of data, Even if people are still using
the same program in 10 years, the level of security should never diminish
because the hardware, upon which the program is running, will/should have
been upgraded.
example
I release a program today that utilizes this very algorithm. I then install
it on a 700 MHz Athlon(I like AMD as well), Now let's say that I am still
running the exact same program, but now it's on a 33 GHz Pentathlon, which
is 100 times faster than the original machine upon which it ran. Because
the Program still takes the same period of time to encrypt the message, more
work is being done to encrypt/decrypt the data hence making it more secure
without changing the underlying software. No Upgrades necessary, no
1024,2048, or 65535 bit keys, simply a value of time that never changes,
because the user knows that if it takes 3 seconds for the message to be
encrypted it will take the same 3 seconds to decrypt it on the same
hardware.
DC
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Sat, 01 Apr 2000 01:21:35 GMT
[EMAIL PROTECTED] wrote:
> > Well, there's the definition:
> >
> > entropy of x, in bits = - log_base_2(probability(x))
>
> This definition is false ! The exact one is
>
> X ... discrete random variable
>
> entropy H(X) = - sum p_i * log_2 (p_i)
>
> where the sum is taken over all the elements with a probability > 0.
No, you seem to be thinking about the entropy of the
source. The question was the entropy of a specific
message. Note that the entropy of the source is the
weighted average of the entoropy of each possible
message, as one would expect.
(And of course you need to relate i to X and
X to the problem.)
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Re-seeding PRNG's in central key distribution systems
Date: Sat, 01 Apr 2000 01:37:55 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Bryan Olson <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> Bryan Olson wrote:
>
> :> : Correct, and the requirements on PRNGs for key generation
> :> : are even stronger. Specifically, even given the state
> :> : of the PRNG, one should not be able to determine previous
> :> : outputs. This is not usually a requirement on stream-cipher
> :> : PRNGs, and thus a strong stream cipher is not automatically
> :> : good for key generation. One should not, for example, use
> :> : RC4.
>
> :> [...] I don't see why this requirement is a necessary one for
> :> a PRNG used for key generation.
>
> : Are you familiar with "ephemeral keys" or "forward secrecy"?
>
> I know what these terms mean. I can see the relevance of forward
> secrecy. I am less certain of connection with "epheremeral keys".
> At a guess, perhaps these are used as some type of seed of the PRNG.
>
> :> If you have the *entire* internal state you can predict
> :> future output. This would be very bad. Attackers should
> :> not be able to obtain the entire internal state of the
> :> PRNG in the first place.
>
> : Be carefull not to confuse "in the first place" with "ever".
> : In a lecture, Whit Diffie noted a disadvantage of
> : cryptographic protection, compared with other measures, is
> : that compromised keys can reach backward through time.
> : Cryptographers have learned to destroy secrets as soon as
> : possible.
>
> It's not so much a compromised key, as a compromise of the RNG
> from which the key is derived. Compromise of the RNG can be done
> by a legitimate key-holder.
There are cases in which that is true, but it's
certainly not true in general. Cryptographic
tokens don't usually support "read PRNG state".
> While its true that the ability to work backwards as well as forwards
> from a poistion where the RNG state is known, this is true for
> stream cypher applications as well as key-distribution applications.
I think a predicate got deleted by a typo and I'm not
sure what that means.
> If a known plaintext in the middle of the message can
> be used to recover the internal state, then this
> will only compromise the latter part of the
> message.
I don't think that's relevent. We both granted that
the state must not be tractably derivable from the
output.
> I'd agree that, with stream cyphers, no-one bothers
> much about this issue.
Right. PRNG states often live well beyond individual
sessions, so they're a much greater concern.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Proof of Identity
Date: Fri, 31 Mar 2000 16:55:56 -0000
The bigger problem I see is that one can, using simple
algebra, create a solution, and given that generate an
additional equation that will allow forgery. For example:
> > 11a + 3b - 9c = -927
> > -5a - 11b + 7c = 1561
Simple algebra gives a third equation for a solution as
6a -8b -2c = 634
16a+14b-16c=2488
>From these you can generate any number of valid signature
equations. Just use whatever form of elimination you want.
The signature scheme itself can be broken quite easily, even
given just one equation choose a point on that line and
write an equation that goes through that point, with 2
equations it's a similar proposition, etc.
Joe
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: LFSR's
Reply-To: [EMAIL PROTECTED]
Date: Sat, 01 Apr 2000 02:13:08 GMT
On Fri, 31 Mar 2000, Pascal JUNOD <[EMAIL PROTECTED]> wrote:
>Let be the irreducible polynom x^63 + x + 1 over GF(2).
>It describes a LFSR (linear feedback shift register),
>which is pretty easy to implement in software.
>
>Let's just speak about the period, not about the cryptographic security
>of the generated bits.
>
>The polynomial being irreducible, it produces a sequence of bits
>(normally the lsb of each states) with a period of 2^64 -1.
>
Minor quibble, for the stated poly, it's 2^63-1.
If you want 2^64-1, you'd need something like
x^64 + x^58 + x^15 + x^8 + 1
(I'll assume you meant such a 64 bit irreducible poly)
>Now, instead of taking the lsb, we could take bit
>#56 or #2 or any one of the 64
>bits of the internal state.
>
>All these possible sequences have a period of 2^64 - 1,or am I wrong ?
>
That's right.
In fact, it's the same sequence as the LSB in a different phase.
>Now, if we output the whole internal state, we produce a sequence of
>2^64 - 1
>values of 64 bits each, or 64*(2^64-1) bits. Am I right ?
>
Yes.
>What is the period of such a sequence, if we look at it as a _bit_
>sequence ?
>
Since 64 and 2^64-1 are relatively prime,
they can not form a periodic sequence.
so it's 64*(2^64-1)
Many of the nice properties of an LFSR sequence
are lost however - it no longer (necessarily)
contains all possible n-1 substrings for example.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: new Echelon article
Date: Fri, 31 Mar 2000 19:19:22 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> >You save the transmission and then decrypt it
> >on-line, or you can even decrypt in real time if you have enough computing
> >power.
>
> You'd need a hell of a lot of computing power to store a 10-minute call.
What makes you think that? Digital cell phones typically use only 8
to 14 KBps, so you're looking at roughly 4.5 to 8.2 megabytes of
storage for a 10 minute call. It obviously takes a bit of capability
to intercept the call at all, but once you've done that, storing the
information is pretty trivial.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Chronometric Cryptography
Date: Sat, 01 Apr 2000 02:34:34 GMT
In article <ni1F4.383$[EMAIL PROTECTED]>,
"Dan Coyle" <[EMAIL PROTECTED]> wrote:
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Dan Coyle wrote:
> > >
> >
> > > A simple solution to this problem would be to create a cipher that
uses
> > > processing time as a primary determinate for it's measure of
security.
> That
> > > is, create a cipher that took just as long to encrypt any given
> plaintext
> > > into ciphertext, as it does to convert that ciphertext back into
> plaintext.
> > > Therefore allowing the application/object to determine the measure
of
> > > security at run-time instead of design-time. In addition, when
> technology
> > > changes, and more powerful machines are made that can resolve
ciphertext
> > > back into plaintext using brute force methods, the hardware which
> executes
> > > the cipher is the only component that what would need upgrading
because
> the
> > > cipher would still take the same amount of time to execute, it
just gets
> > > more cycles to do it's job. I call this type of cipher, a
Chronometric
> > > cipher meaning a cipher whose security is measured by time.
> >
> > One problem you should note is that you generally don't exactly
> > know the resources of the opponent. He may have 100, 1000 or 10000
> > processors. So the moderate factor of increase in MHZ of chips
> > with time is not that determining, I suppose.
> >
> > If you have (or believe to have) an idea of how long the (proper,
> > i.e. knowing the key) decryption time should be in order to render
> > the brute force time of the opponent imfeasible, then the best way
> > I believe is to use a cipher that is parametrized in diverse
> > aspects, in particular in the number of rounds. Through tuning
> > the parameters you could arbitrarily increase the processing time
> > to that you want. See my humble WEAK3-EX available on my web page.
> >
> > M. K. Shen
> > ------------------------------
> > http://home.t-online.de/home/mok-kong.shen
>
> It's kind of Ironic, I was originally trying to create an Arbitrary
Key size
> algorithm, like WEAK3-EX, when I hit upon the Idea of a Chronometric
> Cipher.
>
> Even if the opponent has access to 100,000 processors, with which
he/she may
> use for a Brute Force attack, each processor will need to do an
arbitrary
> amount of work, even with the correct key, to decrypt a message. If
the
> attacker doesn't tell the processors to do enough work, the Brute
Force
> attack would not succeed, even if they stumbled upon the correct key.
Once
> more, a machine that tries to decrypt a message, and uses an incorrect
key,
> will come up with an incorrect starting key, and therefore will not
only
> incorrectly decrypt the message, but it would take, statistically,
2^127(128
> bit key) decryption passes, before the algorithm would declare the
message
> decrypted, and that decrypted message would still be incorrect. The
only
> way an attacker could, feasibly, brute force the message, would be to
guess
> how many iterations the program performed upon the message, and after
> decrypting that many iterations, declare that key void, and move on.
And
> like I said before if they are incorrect in guessing the number of
> iterations, and guess too low a number, the message can never be
> successfully decrypted.
>
It sound like you have just made the
processing time a part of the key.
This does have the interesting effect
that the cryptanalyst has to do a
little *less* work than a brute force attack,
The cryptanalyst has to guess the
"processing time " part of the key.
He would start with a processing time of
one "round" ( or whatever) and continue
to increase it by one.The sum of
work would be less than the amount
of work to do a decryption times the total
processing time.
You also have to remember how many rounds
were used with each file.
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,uk.politics.censorship
Subject: Re: Sunday People 26/3/2000: "FORGET YOUR PASSWORD... END UP IN JAIL"
Date: Fri, 31 Mar 2000 21:37:14 -0500
On Fri, 31 Mar 2000 15:47:11 GMT, [EMAIL PROTECTED] (Your Name) wrote:
>There is a most excellent paper, "Assassination
>Politics" by Jim Bell at
>
>http://www.zolatimes.com/v2.26/jimbell.htm
>
>which shows how the technology of PK Encryption,
>anonymous digital cash, and the internet can be
>used to effect political assassinations in order
>to restore freedom.
Interesting idea, but it can't work because there is nothing to insure
that any money is actually paid upon completion. Who would kill someone
for money without knowing who is paying, where to find that person, and
with absolutely no assurance of any kind that they will ever get paid?
The only way to do so would be for the people running the show to
identify themselves and then they are open to prosecution, retaliation and
targeting by people looking to score a large amount of anonymous e-cash.
You may as well proclaim, I will pay a million dollars to the first person
to kidnap and torture me or try to kill a certain politician surrounded by
armed guards 24/7 who now knows someone is trying to kill him. It doesn't
take a genius to figure out which is the easier way to get a million
dollars, assuming that someone believes that I have the million dollars to
start with. Anyone stupid enough to do such a thing better be a masochist
or actually have a million dollars. :)
There aren't many people willing to paint such a big bullseye on their
forehead and become an instant martyr. And then there won't be anyone to
make the payout and the killing still wouldn't get done.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: general questions on SSL certificates
Date: Sat, 1 Apr 2000 07:43:01 +1000
The segregation of knowledge about the card number can be acheived equally
easy with SSL - just send the payment data directly to the payment gateway
with ssl, then provide an appropriate response to the merchant. browsers
can handle several SSL sessions.
Simple, and several million dollars cheaper than SET.
Larry Kilgallen wrote in message <2000Mar31.142921.1@eisner>...
>In article <8c2qv1$8p5$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>> Hello,
>>
>> I would like to find out more about the level of security SSL
>> certificates have to offer. Could someone tell me if there are any
>> differences between SET certificates and SSL ones ?
>
>The big difference about SET is not the certificate format but
>rather the protocols used. Simply put, with SET the merchant
>cannot learn the credit card number of the customer, but does
>get cryptographic assurance that the transaction will be honored.
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
