Cryptography-Digest Digest #88, Volume #13 Sat, 4 Nov 00 01:13:00 EST
Contents:
Re: Crypto Export Restrictions (David Schwartz)
Re: On introducing non-interoperability (David Schwartz)
Re: Psuedo-random number generator (David Schwartz)
Re: is NIST just nuts? (Timothy M. Metzinger)
Re: srp-1.7.0 released w/TLS Telnet security, X11 forwarding support (Thomas Wu)
Re: Calculating the redudancy of english? (Matt Mahoney)
Re: ECC choice of field and basis (Greggy)
Re: Is OPT the only encryption system that can be proved secure? (Greggy)
Re: ---- As I study Rinjdael... (Greggy)
Re: Rijndael Security (Tom St Denis)
Re: Rijndael question (Dido Sevilla)
Re: example code for your use (Dido Sevilla)
Re: Microsoft's script encoder (Richard Heathfield)
Re: Microsoft's script encoder (Tony L. Svanstrom)
Re: Crypto Export Restrictions (Terry Ritter)
Re: Is OPT the only encryption system that can be proved secure? (Terry Ritter)
Re: Why trust root CAs ? (David A Molnar)
Re: Microsoft's script encoder (JPeschel)
----------------------------------------------------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Fri, 03 Nov 2000 15:09:18 -0800
Terry Ritter wrote:
> > Yes, like the time between keypresses measured to an accuracy of better
> >than a millionth of a second.
>
> That is extremely deceptive.
>
> Keypress events from an ordinary PC keyboard are quantized by a
> relatively-slow (probably tens of milliseconds) keyboard scan process.
> A key can only be reported after it has been detected by the scan.
> The scan itself, the report queue and handshake timing are all
> deterministic.
No. They may be determinstic, but they're not predictable because they
are all timed by uncompensated quartz oscillators that drift due to
unpredictable microscopic temperature variations.
In any event, the presence of the word "like" is the sentence above is
there because this is not the only source used. Other sources are used
that have better randomness in them, such as low-order TSC bits sampled
at packet arrival.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: On introducing non-interoperability
Date: Fri, 03 Nov 2000 15:13:24 -0800
Mok-Kong Shen wrote:
> To brute force you have to setup the algorithm. To do the
> EFF kind of work, you have to have the hardware
> implementation. But since you don't know the modification,
> you can't start your job. If you consider the additional
> secret material for doing the modifiction as part of
> the (effective) 'key' and do brute force, then you have a
> longer key to brute force and you have to spend
> correspondingly more effort. Brute force cannot in general
> be (absoulutely) 'prevented' as such. It is however
> rendered much more difficult through the modification that
> is unknown to the attacker.
In other words, keeping the algorithm secret is equivalent to making
the key longer.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Fri, 03 Nov 2000 15:11:30 -0800
Herman Rubin wrote:
>
> In article <8ts3j8$8vo$[EMAIL PROTECTED]>,
> Alan Rouse <[EMAIL PROTECTED]> wrote:
> >In article <[EMAIL PROTECTED]>,
> > David Schwartz <[EMAIL PROTECTED]> wrote:
> >> Who said anything about being balanced or having exactly maximal
> >> entropy? I'm talking about having sufficient entropy for cryptographic
> >> purposes, nothing more, nothing less
>
> >How much entropy is sufficient? Enough to support the design criteria
> >of the encryption. Presumably a cryptosystem designer would select the
> >key size, such that the size of the brute force attack would be
> >sufficiently large--that is, above some design threshold.
>
> The total amount of entropy in a pseudo-random generaor
> is the amount in the key. Running a computer program
> cannot generate entropy.
Please take a look at http://youknow.youwant.to/~djls/entropy.c for a
counter-example to this claim. While running a computer program cannot
_generate_ entropy, it can certainly mine it. There's plenty of entropy
in the world around us, much of it easy to get to.
DS
------------------------------
From: [EMAIL PROTECTED] (Timothy M. Metzinger)
Subject: Re: is NIST just nuts?
Date: 03 Nov 2000 23:25:14 GMT
In article <[EMAIL PROTECTED]>, Shawn Willden <[EMAIL PROTECTED]>
writes:
>AES will not be implemented in hardware on smart cards, just as DES is
>not. For smart cards the relevant question is how an algorithm performs
>in software on simple 8-bit architectures.
Both DES and 3DES are common in crypto smart cards nowadays.
Timothy Metzinger
Commercial Pilot - ASMEL - IA AOPA Project Pilot Mentor
'98 M20J - N1067W
Pipers, Cessnas, Tampicos, Tobagos, and Trinidads at FDK
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix,comp.os.linux.security
Subject: Re: srp-1.7.0 released w/TLS Telnet security, X11 forwarding support
Date: 03 Nov 2000 16:58:41 -0800
Paul Rubin <[EMAIL PROTECTED]> writes:
> I'm missing something--what's the point of using SRP in conjunction
> with TLS? If you believe the TLS certificates, then TLS stops MITM
> attacks so you can send the password in the encrypted TLS stream.
In this context there are two reasons why SRP and TLS make sense
together. If you just want password-based authentication, you have
the option of using anonymous TLS sessions, and then using SRP to
verify the TLS Finished messages as well as authenticate the user.
You end up with mutual authentication, but without the overhead of
setting up a PKI, and you can leverage the transport-layer security
of TLS within the Telnet session.
The advantage of using a zero-knowledge protocol is that there's no
way to fool a client into negotiating a secure channel with the adversary
(or a compromised legitimate host) and grabbing the password. TLS-based
telnet will support SRP authentication even when server certs are used,
so that even if you do end up deploying server TLS certs, you get the
security benefits of both technologies.
Having a telnet client and server that supports "everything including the
kitchen sink" and can auto-negotiate security options dynamically should
make life that much easier for users and admins.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: Matt Mahoney <[EMAIL PROTECTED]>
Subject: Re: Calculating the redudancy of english?
Date: Fri, 03 Nov 2000 21:21:11 -0500
Simon Johnson wrote:
>
> How does one calculate the redudancy of english?
In 1950 Shannon estimated the entropy of written English to be 0.6 to
1.3 bits per character, based on how well people can predict successive
characters in text. Cover and King in 1978 estimated 1.3 bpc using a
gambling game in which people placed bets on the next letter rather than
just ranking them. I believe that this method is flawed because people
tend to overestimate the odds of unlikely events (e.g. lotteries), which
would overestimate the entropy. I did some simulations of the Shannon
game which suggest a value around 1.0 bpc. (See
http://cs.fit.edu/~mmahoney/dissertation/entropy1.html ).
I'm surprised that more research hasn't been done on this question. But
until we solve the AI problem, we have to use human subjects, because a
statistical model of English would be equivalent to passing the Turing
test. The best model to date is one developed by Rosenfeld in 1996 on
hundreds of megabytes of text at 1.2 bpc. Among text compressors, RK is
probably the best at 1.8-1.9 bpc. Gzip gets about 3 bpc.
-- Matt Mahoney, [EMAIL PROTECTED], http://cs.fit.edu/~mmahoney/
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: ECC choice of field and basis
Date: Sat, 04 Nov 2000 02:38:19 GMT
> NSA wears 2 hats. In this case, in speaking to NIST,
> they are wearing their infosec hat, that is, goodness
> is the goal.
>
> Don Johnson
You can take the chance you are right. I decline.
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Sat, 04 Nov 2000 02:46:10 GMT
> That's my claim. It's also almost indisputable that this is one of
> the most confusing issues to anyone who is not a crypto expert.
> Claiming that we "have" something which is perfect, but which is not
> possible to realize in a guaranteed perfect way, is just stupid: In
> practice, we don't really "have" it at all. Too bad that bothers you.
>
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
So does it bother you that your cryptosystems are all vulnerable
to divine revelation? How about remote viewers?
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: ---- As I study Rinjdael...
Date: Sat, 04 Nov 2000 02:53:46 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] (Mok-Kong Shen) wrote in
> <[EMAIL PROTECTED]>:
>
> >
> >
> >"SCOTT19U.ZIP_GUY" wrote:
> >>
> >> [EMAIL PROTECTED] (Mok-Kong Shen) wrote:
> >> >
> >> >Greggy wrote:
> >> >>
> >> >> As I study Rijndael, I am constantly haunted by the question I
hope
> >> >> someone can answer:
> >> >>
> >> >> If Rijndael is so strong, why does the US government choose NOT
to
> >> >> use it for ANY (not all) classified information?
> >> >
> >> >I am not aware that the US government 'chooses' not to use
> >> >Rijndael for any classified information. Why should it tell
> >> >you what it uses to encrypt classified information? By
> >> >definition, classified information doesn't concern you
> >> >as normal citizen at all. (You are not supposed to care
> >> >about it.)
> >> >
> >> >M. K. Shen
> >>
> >> Actually every concerned citizen should care about what
> >> the government ecnrypts otherwise we will go down the same
> >> path as the soviets. The amount and type of information the
> >> government tries to hide should be closely watched unless one
> >> wants to be taken care of cradle to grave with little contorl
> >> over ones life. The govenment assumes it knows more than
> >> every one else so they use internal methods that have an additional
> >> security feature of the algorithms being kept secret. Rijndael
> >> fails since the method is not secret. I also suspect it may fail
> >> since there is a gook chance the NSA can already break it. Unless
> >> one uses a chaining mod like "wrapped PCBC" and those kind of
> >> modes will not be approved for use.
> >
> >Aren't you suggesting that a government should keep no
> >secret so that it is entirely open even to hostile
> >foreign countries?
> >
> >M. K. Shen
> >
>
> I don't know why I am replying to you. I guess I don't learn.
> That is not what I meant. I think due to secrecy my country is
> being more and more corrupted by the few. Look at our elections
> we critisize other countries for having unfair elections. But
> look how my country is running this one. There is no doubt in my
> mind. Gore we win because the government is more corrupt than
> ever.
>
Actually, it looks like W, but either is NWO and both will break
their oath of office and continue the insane war against our bill
of rights (aka the war on drugs). I could never vote for either,
for a vote for either is a vote for the NWO, the extinguishment
of the USA and its constitution, the slavery of our children, etc...
--
I would prefer to live in a free society than
a drug free society - even if the latter could
actually be achieved.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Rijndael Security
Date: Sat, 04 Nov 2000 03:14:25 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] (ajd) wrote in
> <3a028dcf$[EMAIL PROTECTED]>:
>
> >
> >How secure is Rijndael when given (most of) the plaintext and the
cipher
> >text? For example if I encrypt a bitmap (and somehow the
interceptor
> >knows its a bitmap), the interceptor then knows that the first block
> >will decrypt to
> >
> >42 4D ** ** ** ** 00 00 00 00 36 00 00 00 28 00
> >
> >where bytes 0-1 are the bitmap identifier
> >2-5 are the file size (which the interceptor doesn't *quite* know as
my
> >encrypted file will be a multiple of the block size, and vthe
plaintext
> >file may not be)
> >6-9 reserved and always zero
> >10-13 is the offset to beginning of bitmap data
> >14-17 is th header size
> >
> >Given this information about the plaintext, and given the encrypted
> >text, can the interceptor work out the key? It seems to me like we
are
> >giving away a bit too much information. Is there a standard to get
> >around this problem?
> >
> >regards
> >andrew
> >
> >
>
> I agree with you especailly if the attacker knows what kind of
file
> your sending. There are many ways to get a round this problem you
could
> use MAtts BICOM he takes exactly this kind of header problem in to
> condsideration. Since after the compression phase the first 20 K of
the
> file is whitetened then the CBC mode of Rijndael occurs. Or you
> could use compress and use a all or nothing encryption pass like
> scott16u to whiten the whole file compressed or not compressed and
> then use the blessed AES method supplied in Matts code. THe advantage
> of the second is that even a one bit change in the input file changes
> the whole file. No matter how long it is.
>
> But if you follow so called experts which may not really care if
> your stuff is safe. THey will either give a none bijectiv method
> or say same crap that modern ciphers are to hard to break so don't
> worry about it.
In other words we may have a bloody clue!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Rijndael question
Date: Sat, 04 Nov 2000 12:59:08 +0800
Tom St Denis wrote:
>
> Actually Rijndael decryption is "slightly" slower not a zillion times
> slower. I would therefore recommend that your idea is not a good one
> for this sole reason.
>
Not exactly. I've been actually able to implement Rijndael itself, both
the encryption and decryption algorithms, on an embedded
microcontroller, and found that due to the choice of coefficients, my
straightforward assembly implementations are quite biased in favor of
encryption. Not a zillion times slower, but significantly slower
nevertheless. My initial benchmarks showed that the decryption
algorithm could be as much as a factor of four slower than the
encryption, mainly because of the difference in coefficients used in the
mixcolumn stage. I wouldn't call a factor of four a "slight"
difference, not by any standard! The 01, 02, 03, and 01 in the
encryption matrix could be computed incrementally, and hence much more
quickly, than the 09, 0e, 0b, and 0d used for decryption.
This should not be true on a 32-bit version that uses the implementation
speedups described in the Rijndael spec, such as the one that's used in
my Perl implementation of Rijndael, as encryption and decryption only
need one table lookup and one xor per round per byte encrypted.
> 1. The server computer has way more data to process then a single
> dopey computer. Therefore the dopey computer can afford to use the
> slightly slower decryption routine.
>
To the originator of this post: Rijndael's decryption algorithm need not
be used by the dinky processors at all. You could use a chaining mode
like CFB which uses the encryption algorithm to do both encryption and
decryption. In my case, encryption and decryption were both needed due
to the way data were being transmitted, but fortunately for me the
embedded processor needed to decrypt far much less data than it had to
encrypt, so the 4x-slower rate wasn't really much of a problem.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: example code for your use
Date: Sat, 04 Nov 2000 13:07:55 +0800
Kenneth Lantrip wrote:
>
> I have written a nice (I think so) little program in C to help me learn the use
> of the language. I'm not sure if it's legal to post an encryption algorithm
> that uses a 128 bit key. I'd like to offer it to whoever wants to see the code
> so that they might can use parts of it or learn from it or whatever.
>
Well, as long as you provide source, you ought to be safe... The now
convoluted US export laws say that SOURCE CODE is free from export
restrictions. Crypto binaries however, still cannot be obtained from US
sources. Source code == speech according to one US ruling, and thus
it's protected under your 1st amendment. The EAR will not have you
arrested for providing it to foreign nationals (except those who dwell
in places like Iraq and North Korea where it's actually illegal for the
United States to actually engage in any sort of trade).
> the key space and avalanche properties of the IDEA algorithm is too great to be
> comprehended by the human mind. It is little more than a crypto-analysis tool
> for the algorithm.
<rant>
Well, IDEA algorithm? No pun intended, but I don't think that's really
a good idea. IDEA's covered by a worldwide patent that doesn't expire
till 2007, so be wary. There are so many other even better ciphers
available that are unencumbered by these silly notions of "intellectual
property", and which have gotten a great deal more hard analysis because
of that.
</rant>
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
Date: Sat, 04 Nov 2000 05:13:50 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Microsoft's script encoder
Lefty Louther wrote:
>
> No i don't think it's secure.Microsoft sais that it's unsecure.
> I think the first part is part of the checksum.
> When i encode different data i get the same AAAAA.
> It's not an encryption, it's an encoding.
>
> I want to learn how it works.
> If you have any idea please help me.
You probably can't learn how it works, because reverse-engineering it
probably contravenes the terms of your licence agreement.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
Subject: Re: Microsoft's script encoder
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Sat, 04 Nov 2000 05:21:11 GMT
Richard Heathfield <[EMAIL PROTECTED]> wrote:
> Lefty Louther wrote:
> >
> > No i don't think it's secure.Microsoft sais that it's unsecure.
> > I think the first part is part of the checksum.
> > When i encode different data i get the same AAAAA.
> > It's not an encryption, it's an encoding.
> >
> > I want to learn how it works.
> > If you have any idea please help me.
>
> You probably can't learn how it works, because reverse-engineering it
> probably contravenes the terms of your licence agreement.
This licence doesn't limit what you can do, as long as you do it
anonymously... ;-)
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
on the verge of frenzy - i think my mask of sanity is about to slip
---���---���-----------------------------------------------���---���---
\O/ \O/ �99-00 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech,alt.hacker
Subject: Re: Crypto Export Restrictions
Date: Sat, 04 Nov 2000 05:33:23 GMT
On Fri, 03 Nov 2000 15:09:18 -0800, in
<[EMAIL PROTECTED]>, in sci.crypt David Schwartz
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>
>> > Yes, like the time between keypresses measured to an accuracy of better
>> >than a millionth of a second.
>>
>> That is extremely deceptive.
>>
>> Keypress events from an ordinary PC keyboard are quantized by a
>> relatively-slow (probably tens of milliseconds) keyboard scan process.
>> A key can only be reported after it has been detected by the scan.
>> The scan itself, the report queue and handshake timing are all
>> deterministic.
>
> No. They may be determinstic, but they're not predictable because they
>are all timed by uncompensated quartz oscillators that drift due to
>unpredictable microscopic temperature variations.
Phooey!
Crystal oscillators use physical quartz resonators to produce some
particular constant frequency. But frequency is not discrete, it is a
real quantity. The longer the period of measurement, the greater the
accuracy we can use to know what the frequency "really" is. But that
does not mean that our earlier less accurate knowledge was wrong, or
that the frequency changed.
Crystal oscillators do drift with temperature, but not much, in
relative terms. These devices are specifically engineered to drift as
little as possible (consistent with cost). So if one was depending on
frequency changes to produce unknowable values, a crystal oscillator
would be the absolute *last* device one would want to use.
"Microscopic temperature variations" will produce tiny frequency
changes, but they will be far too small to notice (unless the crystal
is used in radio, where down-conversions magnify the relative change).
The changes are also reproducible and predictable, given knowledge of
the temperature. Even worse, frequency changes can be inferred and
tracked, when deterministic events occur at somewhat different times
than expected. This is not cryptographic strength.
PC keyboards generally are scanned by a single-chip processor which
has its own crystal for the processor clock oscillator. A cheap
crystal might drift +/- 50 PPM (Parts-Per-Million) with -/+ 10 deg C
temperature change (and much less thereafter). [ See, for example:
http://www.kita.or.kr/catalog/it/it_2.html
http://www.ofc.com/piezo/papers/pcso.html
http://www.anodynecomp.com/joyous/crystals/z49up.html
http://www.cmindhk.com/crystal.htm
www.lecroy.com/labs/volumeIVJitterTiming/default.asp#clockoscillatorstability
which typically talk about +/- 50 PPM over 0 C to 70 C, or -10 C to 60
C. And these are the cheaper crystals; communications crystals are
much better.]
With a keyboard processor clock of 5 MHz, 50 PPM is 250 Hz. So
instead of having the original frequency of 5,000,000 cycles per
second, we now have 5,000,250 or 4,999,750, across 20 deg C. That is
a 500 Hz change out of 5,000,000 Hz, which is 1 part in 10,000 or
1/100th of a percent.
So if we have a keyboard scan rate of 20 msec, and the temperature
changes by 20 deg C, we might get a 20.001 msec scan. But knowing the
scan rate to this precision would lead to pretty good deterministic
prediction estimates, even *with* temperature changes.
> In any event, the presence of the word "like" is the sentence above is
>there because this is not the only source used. Other sources are used
>that have better randomness in them, such as low-order TSC bits sampled
>at packet arrival.
But if those other sources really are "like" the keyboard, they can't
be nearly as helpful as you first implied.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Sat, 04 Nov 2000 05:39:08 GMT
On Sat, 04 Nov 2000 02:46:10 GMT, in <8tvt9i$gar$[EMAIL PROTECTED]>, in
sci.crypt Greggy <[EMAIL PROTECTED]> wrote:
>> That's my claim. It's also almost indisputable that this is one of
>> the most confusing issues to anyone who is not a crypto expert.
>> Claiming that we "have" something which is perfect, but which is not
>> possible to realize in a guaranteed perfect way, is just stupid: In
>> practice, we don't really "have" it at all. Too bad that bothers you.
>>
>> ---
>> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
>
>So does it bother you that your cryptosystems are all vulnerable
>to divine revelation? How about remote viewers?
But there *is* no proven-secure OTP in practice. Does talking about
something which does not -- and probably *can* not -- exit, *not*
bother you?
For more extensive comments, see:
http://www.io.com/~ritter/GLOSSARY.HTM#OneTimePad
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: 4 Nov 2000 05:43:16 GMT
Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote:
> Two years ago, somebody from VISA gave a presentation at an ISO
> meeting regarding the number of (SET) transactions coming into
> consumer issuing financial institutions with the SET authenticated
> flag turned on ... and they could show that there was no SET
> technology involved in the transaction (issue crops up in security
> infrastructures when there isn't end-to-end authentication and
> end-to-end integrity).
Did they go into where and why the offending transactions came from?
Was this a case of poorly implemented software, merchants trying to get
discounts for using SET, or something else?
-David
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Microsoft's script encoder
Date: 04 Nov 2000 06:01:26 GMT
Richard Heathfield [EMAIL PROTECTED]
>You probably can't learn how it works, because reverse-engineering it
>probably contravenes the terms of your licence agreement.
>
You're kidding! They all say that.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
** 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
******************************
