Cryptography-Digest Digest #430, Volume #10 Tue, 19 Oct 99 02:13:03 EDT
Contents:
Re: The Quad. in RC6 (Tom St Denis)
Re: Strengthening passwords against dictionary attacks (Tom St Denis)
Re: Ciphertext Stealing in CBC Mode (Wei Dai)
Re: plaintext/cyphertext question (Tom St Denis)
Dictionary download (Amer Neely)
Dictionary download (Amer Neely)
Dictionary download (Amer Neely)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: Testing of randomness (Tom St Denis)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
(DJohn37050)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Tom St Denis)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
(DJohn37050)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Bruce
Schneier)
Export grade SSL used in internet banking (Red_Blue)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The Quad. in RC6
Date: Tue, 19 Oct 1999 01:30:01 GMT
In article <7ufqii$u0n$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Yeah, that's where I get a little fuzzy. I'm not sure how the
> multiplication is affected by a transform like that. I'm under the
> impression that multiplication is affected by the lower bits more than
> the higher bits. Therefore, you want to retain as many of the lower
> bits as possible. With the original 2x, which is equivalent to x <<
1,
> you still retain most of the original bits. By adding 1, you are
> creating an odd number.
But you never actually lose entropy. It's a bijective function (1 to
1) so it can't create or lose any info. You are correct in assuming
that for high values of a the quality of the diffusion is much less.
However xcept for the fixed points the value is always going to change.
I think the last one I had
f(x) = x(ax + b) + c
along with the rest of RC6 would be much better. It would eliminate
the *known* fixed points, and be a tad harder to attack. The problem
is it would make the cipher much slower. You would need a fast
multiplication as well as squaring. In software this might raise it
from the current ~250 cycles to about 300-320. I wouldn't imagine it
that detremental.
> Like I said, I'm not sure. Shift's up to and including 8 probably
won't
> be too detrimental, if I understand binary multiplication correctly.
> You're b will probably have to be picked carefully.
Again you are assuming the rest of the cipher plays no role in the
diffusion of key bits.
> How about f(x) = x * ((x >>> b) AND 1) where b <= 16? This would
> probably have good diffusion and ensure an odd number in the second
part
> of the multiplication.
You mean OR right? Otherwise this would not be bijective. How about
> This function is used to set up the data-dependant rotations, so your
> thinking is backwards if I understand it correctly. The goal of the
> quad is to generate 5 bits to be used for the rotate. The results of
> the quad are also mixed in with the data using an XOR, however I don't
> believe that plays as significant of a role in the security of the
> cipher as the data-dependant rotate.
Another solution would be to construct four 8x5 sboxes and just xor the
result together. (Similar to blowfish). This way you can create high
avalanche rotate values which are data dependant.
so we have
f(x) = x(ax + b)
f(x) = x(ax + b) + c
f(x) = x(ax + b) >>> c
f(x) = x(2x + b) + c
f(x) = x(2x + b) >>> c
The last four remove the *known* fixed point. The last two are faster
in hardware and software. The fourth is faster in hardware and
software then the fifth. I think #2 and #4 would be good bets since
RC6 already has rotates.
Of course for all 'a' = even, 'b' = odd, 'c' = integer (use lower five
bits in rotate of course).
Hmm just my two cents.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Strengthening passwords against dictionary attacks
Date: Tue, 19 Oct 1999 01:43:21 GMT
In article <7udpqf$p8r$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill Unruh) wrote:
> In <7udhan$esn$[EMAIL PROTECTED]> Tom St Denis <tomstdenis@my-
deja.com> writes:
>
> >Basically any login system should work like this
>
> >1) Server sends R (random bit string, say 32 bits)
> >2) Remote sends a = HASH(R + password) and R'
> >3) Server checks a, and sends b = HASH(R' + password)
> >4) Remote checks b
> Server has to store that password in the clear.
> Remote person can still launch a dictionary attack, having both R and
a.
> Ie, that password had better be a good one ( not the weak thing you
> suggested).
> Man in the middle attack works.
> Eve grabs communication. Passes R on to remote, gets a, passes on a,
and
> R' gets b, sends on b. Remote
> thinks he is connected to server, but is connected to Eve. Server
thinks
> he is connected to remote but is connected to eve.
>
> Is it better than clear text password? yes, except for storage of cler
> text passwords. But one can do better.
First off don't put words in my mouth. I hate that.
Second, I personally don't even believe in passwords. (You will note
that if you have seen peekboo). One idea is to use a EKE to setup a
shared key with the server. I could for example send R'' to the server
and we could use HASH(R'' + password). Eve sitting in the middle will
not know the key since he/she doesn't know the password. You can't man
in the middle that because you need the password to make a viable key.
Think about it, if I send you R'' without knowing the password will it
be the same as your shared key?
Third, why does everybody think storing enciphered text on a local
machine is so secure. For example in PGP they encrypt the keys but I
could just as easily make a trojan, distribute it remotely get your key
when you use it, and send it over the net to my machine. I could for
example be collecting millions of private keys right as I type this and
you would never know it.
Basically I don't think you can really protect local machines. You can
however protect remote communications such as information traffic.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Wei Dai)
Subject: Re: Ciphertext Stealing in CBC Mode
Date: Mon, 18 Oct 1999 17:52:58 -0700
In article <380a3747$0$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> I'm reviewing the idea of Ciphertext Stealing in CBC mode
> and having a little trouble with Figure 9.5 page 196 in AC.
> Because Bruce didn't explain much in the book, the Figure
> just isn't clear to me. I would seem that the last full block
> and the final partial block are flipped around. Also what
> is the symbol phi supposed to be? Any good discriptions
> of Ciphertext Stealing out there?
RFC 2040 has a detailed description of ciphertext stealing in the RC5-CTS
section. See http://www.faqs.org/rfcs/rfc2040.html.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: plaintext/cyphertext question
Date: Tue, 19 Oct 1999 01:58:23 GMT
In article <7ugehk$bqp$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I hope this is not a dumb question, I apologize if it is.
>
> If I had a stream of SSL packets, and something happened (irrelevant
> what) that caused a plaintext packet to go out on the SSL session,
> would the plaintext data be of any attack value/aid on the previous
> encrypted packets???
>
> encrypted_packet1
> encrypted_packet2
> encrypted_packet3
> plaintext_packet4 (<----oooops!)
>
> I think it would not, but I am unclear on this. If there was an
> accompanying "encrypted_packet4" with the "plaintext_packet4", I
> understand that problem, but without accompaning cyphertext, I believe
> the plaintext is useless as an attack on the encrypted packets.
>
> Does the plaintext in packet4 (reguardless of how it happened to be
> plaintext) lend any attack advantage on the previous encrypted
packets?
>
> Thanks in advance for any answers, I appreciate it. I know this is
> kind of a wierd question, and security is moot at this point because
> the plaintext packet is obviously in the clear. I need to understand
> any risk on the previous encrypted packets though.
Obviously if there were no ciphertext that corresponds with #4 then you
have no relation to use in a iterative attack. however if #4 contained
keys for a future session, or important information I would worry.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Amer Neely <[EMAIL PROTECTED]>
Subject: Dictionary download
Date: Mon, 18 Oct 1999 21:25:08 -0400
I'm looking for an English dictionary I can download, preferabaly as a
text (ASCII) file.
--
Amer Neely [EMAIL PROTECTED]
Certified Internet Webmaster Designer
Softouch Information Services: http://www.softouch.on.ca/
Research Central: http://www.softouch.on.ca/rc/
Member: HTML Writers Guild: http://www.hwg.org/
Member: Association of Web Professionals: http://www.a-w-p.org/
------------------------------
From: Amer Neely <[EMAIL PROTECTED]>
Subject: Dictionary download
Date: Mon, 18 Oct 1999 21:14:18 -0400
I'm looking for an English dictionary I can download, preferabaly as a
text (ASCII) file.
--
Amer Neely [EMAIL PROTECTED]
Certified Internet Webmaster Designer
Softouch Information Services: http://www.softouch.on.ca/
Research Central: http://www.softouch.on.ca/rc/
Member: HTML Writers Guild: http://www.hwg.org/
Member: Association of Web Professionals: http://www.a-w-p.org/
------------------------------
From: Amer Neely <[EMAIL PROTECTED]>
Subject: Dictionary download
Date: Mon, 18 Oct 1999 21:15:16 -0400
I'm looking for an English dictionary I can download, preferabaly as a
text (ASCII) file.
--
Amer Neely [EMAIL PROTECTED]
Certified Internet Webmaster Designer
Softouch Information Services: http://www.softouch.on.ca/
Research Central: http://www.softouch.on.ca/rc/
Member: HTML Writers Guild: http://www.hwg.org/
Member: Association of Web Professionals: http://www.a-w-p.org/
------------------------------
Date: Mon, 18 Oct 1999 23:23:15 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
DJohn37050 wrote:
> At a recent ANSI X9F1 meeting, where particpents consisted of vendors, bankers,
> auditors and government, there was overwhelming consensus that NIST should
> incorporate future resiliency considerations into AES criteria.
>
> No one is saying that an implementation cannot choose one algorithm, just allow
> the ones that want to (for whatever reason) to be allowed to implement more
> than one and do this in the context of the standard.
I suspect the term resiliency has multiple meanings. One of the meanings we should
inspect is that of future revisions to standard algorithms, and even "Very AES"
(VAES), which may be needed sometime in the future.
DES didn't evolve. It did not get tweaked as a standard. It did gain extra layers
such as DESX and 3DES. Will AES evolve? Will it need more "tweaks"? An
infrastructure without resiliency is brittle. It cracks and fails
catastrophically. Let's not.
At some point in the future we'll be faced with an aging AES and the need to create
a successor standard. Hopefully this will occur before AES is as useless as DES is
today. If we learn from the current tardiness we will create VAES while AES is
still "strong". Which means that when VAES is adopted there will be two standard
ciphers.
If we select a single AES "winner" the switch to VAES will be extremely painful.
Given the expectation that security will become pervasive in the interval between
now and then the switch to VAES will be much tougher than the switch from DES to
AES. It might rival Y2K issues as a societal problem. Given the taste for
litigation today do we want to allow the possibility of this kind of problem?
OTOH, if we select multiple AES winners, and provide for evolutionary changes in
the standard, similar to the round 2 "tweaks", the change to VAES will be
reasonably smooth. Not easy, but comparatively simple.
Speaking ex-cathedra from my navel I assert that the chance of the AES "winner(s)"
being catastrophically weak is small. Very small. Close to zero.
But the chance that we'll need something like VAES is large. Very large. Close to
one.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Testing of randomness
Date: Tue, 19 Oct 1999 03:29:35 GMT
In article <[EMAIL PROTECTED]>,
Jon Haugsand <[EMAIL PROTECTED]> wrote:
> * [EMAIL PROTECTED]
> > > I work in the GB range.
> > >
> > Good at testing randomness? Is this a random series: 45, 87, 3,
30.
>
> Hardly in the GB range.
What is the GB range? And why aren't a million zeros random?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 19 Oct 1999 03:36:22 GMT
The very reason to use parallel links is so if one breaks the other might not.
Don Johnson
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Tue, 19 Oct 1999 03:35:11 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Bruce Schneier wrote:
> >
> > On Sun, 17 Oct 1999 01:29:39 GMT,
[EMAIL PROTECTED]
> > (John Savard) wrote:
> > >I think it *is* correct that users can't memorize _passwords_
which,
> > >because they have digits or punctuation marks thrown in, have
enough
> > >entropy in them to be adequate in themselves.
> > >
> > >And there is a reason I underlined the word *passwords* in the
> > >preceding sentence. Because it is the crucial point where I think
> > >Bruce may have been mistaken. It is possible for the user of a
> > >cryptographic system to memorize a pass phrase. It is possible to
use
> > >the same kind of tricks with a pass phrase as are used with short
> > >passwords to increase entropy - insert an incongruous word, rather
> > >than a non-alphabetic character, into the phrase. One can require
two
> > >or three pass phrases to be entered to produce the key.
> > >
> > >(Note that I've earlier advocated stripping punctuation from pass
> > >phrases, since I think it's easier to memorize the words of a
longer
> > >pass phrase than to get the punctuation exactly right every time.)
> > >
> > >I could be wrong, but I believe it to be - with some effort -
possible
> > >for a user to memorize data, _in a suitable form_, from which a
key of
> > >sufficient (genuine) length can be derived. As there are many cases
> > >where there is simply no reasonable alternative to a user-memorized
> > >secret, I believe this is a vitally important point.
> >
> > I agree that it's possible, but I don't think it likely. It's hard
> > enough getting users to remember four-digit PINs. You and I and
> > everyone who reads this newsgroup can remember high-entropy
> > passphrases (maybe a few), but the general populace cannot.
>
> While people normaly seem to have difficulty to remember a eight or
> more digit number, I suppose it is an exageration that they find
> it hard to remember four digits ones. In my city telephone numbers
> have at least six digits and plenty of people memorize quite a number
> of the phone numbers of their friends well. Further, account numbers
> of my bank has 10 digits and I have seen many people writing down
> these without looking into their note books. If one memorizes six
> (or even four) digits and, as Mr. Savard mentioned, insert these
> into a pass phrase at some irregular positions, I am not sure that
> cracking with a dictionary is that simple. Further, a meaningful
> pass phrase need not be typed in as such, it could be, e.g.
circularly
> rotated a few characters.
I tend to find numbers easier to remember. but the numbers you need
for a strong key are long. For example a 64 bit number has 19 digits,
you could mix in lower case letters with numbers. It would take
practice to remember it. I personally find passwords a waste of time.
If you want to have your own key sake, get a smartcard that does some
sort of authentication (for your needs). You could for example get one
of those keyboards with a 2band magnetic reader (the pharmacy I work at
has em) and put your password in 100 or so chars on a card. They are
cheap, easy to make and will last a year or two. It's way more seucre
then having the user remember something, and the interface is the same
(the chars read off the card are stuffed in the keyboard buffer).
Just my ideas...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 19 Oct 1999 03:51:36 GMT
The "Future Resiliency" presentation I made to X9F1 was EXACTLY the paper I
submitted to 2nd AES, namely that there should be more than one winner and gave
scads of reasons for this.
Some disagree, ok. It remains to be seen what NIST will decide to do in this
area. There are arguments on both sides. Simplicity is the main one for
having only one winner.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 03:55:39 GMT
On 18 Oct 1999 20:42:37 GMT, [EMAIL PROTECTED] (DJohn37050) wrote:
>At a recent ANSI X9F1 meeting, where particpents consisted of vendors, bankers,
>auditors and government, there was overwhelming consensus that NIST should
>incorporate future resiliency considerations into AES criteria.
Who argued in favor of one algorithm, or was there just a presentation
of the virtues of multiple AES algorithms?
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: Red_Blue <[EMAIL PROTECTED]>
Subject: Export grade SSL used in internet banking
Date: Tue, 19 Oct 1999 07:16:01 +0300
==============26AD770B060C321C6C6E55E5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This covers weakness in one implementation of supporting security
measures used with 40-bit SSL and not anything particular to the
security of SSL or any algorithm. Provided just for general security
interest, not crypto point of view.
Ok, everyone here knows that SSL with 40-bit session keys should not be
used for anything needing serious security. It seems however, that at
least in Finland, perhaps in other European countries as well, 40-bit
SSL is routinely used to secure internet banking systems.
In Finland there are 5 major banks that offer internet banking
(handling accounts, making transactions, buying shares etc. with web
browsers) and only one is using Global Certificates. The others rely on
export grade SSL with 40-bit session keys and additional authentication
codes that are delivered to the customer in a paper.
Usually these are numbers. First there are the changing password
numbers which are used to authenticate the user with his/her customer
number. One password number is used only in one session and once almost
all of them are used, a new list is sent by the bank (in paper mail).
Then there are also transaction verification numbers that are needed
when money transactions are made (bills paid online). There is only a
small number of them (18 in one example), and when used they are not
crossed over in the paper as the "running" password numbers are. Instead
the same transaction verification number can be used again at some other
time. So, which of the 18 verification numbers is requested by the
bank's server is random, while password numbers run in sequence.
With enough computing power and time anyone capable of intercepting the
traffic between the client and the bank's server, can get access to
confidential bank account information. This in itself is bad enough, but
there is also a way to commit fraud and get control over someone's
account if sufficient resources are available to the attacker.
First the attacker must decrypt enough sessions of one bank customer to
get a reasonable portion of the transaction verification numbers from
the customer's list. The customer is identified by the attacker from the
customer number that is same for every session. Every time that customer
makes legitimate transaction from his account, one of the verification
numbers is disclosed to the attacker who is capable of decrypting the
traffic. If there are 18 of them and selection is truly random, it takes
62 sessions on average to get every one of them but only 11 sessions to
get 9 on average.
The next part is the tricky one. To utilize these verification numbers
the attacker also needs to get the next "running" password number to
have valid access to the victims account. The problem is that once a
password number is used by the customer it can't be used again and so it
makes no good have it decrypted some time after the exchange between the
client and the server. Now, provided that the attacker has some other
way than the customer number of the victim to identify the browser
client trying to contact the bank's server, the attacker could, not
only, intercept the TCP packet containing HTTP POST of the password
number, but also prevent this packet reaching the bank's server. Now
since the data never reached the bank's server, that password number is
still valid and in the hands of the attacker.
Now the correct customer has to be blocked from connecting to the
bank's site again before the password number is decrypted. The attacker
returns some error message to all GETs to the bank's address by the
customer. The customer might not realize that this is a fraud attempt
and he perhaps just complains to the bank or his ISP. If brute-forcing
the 40-bit session key used by the customer's client to encrypt the
password number takes only a couple hours it might be possible to pull
this off, before proper authorities are alerted or the account closed.
If the verification number requested by the bank is one of those held by
the attacker (the bank uses an index letter to identify the number), he
can make a transaction order to move the money to his account.
Note that with SSL v3 the session keys can be changed during the session
(perhaps every page) and that there are actually two keys, one for each
direction. This increases the key cracking effort needed in the
surveillance part of the operation, but in the attack part many key
cracks are not needed if the correct packet can be identified by traffic
analysis (how many exchanges needed to reach the state where pw number
is sent by the client's browser can be traced in the surveillance part).
At best it requires brute forcing just one RC4-40 key, a feat that can
be accomplished with a powerful Beowulf cluster in a matter of hours.
So what we learn from this? Do not use 40-bit SSL-security to protect
people's money. Go for Global ID so that people using international
browser versions can be protected with full 128-bit keys (and 1024 for
RSA).
Jere Hakanen
==============26AD770B060C321C6C6E55E5
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
This covers weakness in one implementation of supporting security measures
used with 40-bit SSL and not anything particular to the security of SSL
or any algorithm. Provided just for general security interest, not crypto
point of view.
<p>Ok, everyone here knows that SSL with 40-bit session keys should not
be used for anything needing serious security. It seems however, that at
least in Finland, perhaps in other European countries as well, 40-bit SSL
is routinely used to secure internet banking systems.
<br> In Finland there are 5 major banks that offer internet banking
(handling accounts, making transactions, buying shares etc. with web browsers)
and only one is using Global Certificates. The others rely on export grade
SSL with 40-bit session keys and additional authentication codes that are
delivered to the customer in a paper.
<br> Usually these are numbers. First there are the changing password
numbers which are used to authenticate the user with his/her customer number.
One password number is used only in one session and once almost all of
them are used, a new list is sent by the bank (in paper mail). Then there
are also transaction verification numbers that are needed when money transactions
are made (bills paid online). There is only a small number of them (18
in one example), and when used they are not crossed over in the paper as
the "running" password numbers are. Instead the same transaction verification
number can be used again at some other time. So, which of the 18 verification
numbers is requested by the bank's server is random, while password numbers
run in sequence.
<p>With enough computing power and time anyone capable of intercepting
the traffic between the client and the bank's server, can get access to
confidential bank account information. This in itself is bad enough, but
there is also a way to commit fraud and get control over someone's account
if sufficient resources are available to the attacker.
<p>First the attacker must decrypt enough sessions of one bank customer
to get a reasonable portion of the transaction verification numbers from
the customer's list. The customer is identified by the attacker from the
customer number that is same for every session. Every time that customer
makes legitimate transaction from his account, one of the verification
numbers is disclosed to the attacker who is capable of decrypting the traffic.
If there are 18 of them and selection is truly random, it takes 62 sessions
on average to get every one of them but only 11 sessions to get 9 on average.
<br> The next part is the tricky one. To utilize these verification
numbers the attacker also needs to get the next "running" password number
to have valid access to the victims account. The problem is that once a
password number is used by the customer it can't be used again and so it
makes no good have it decrypted some time after the exchange between the
client and the server. Now, provided that the attacker has some other way
than the customer number of the victim to identify the browser client trying
to contact the bank's server, the attacker could, <u>not only</u>, intercept
the TCP packet containing HTTP POST of the password number, <u>but also</u>
prevent this packet reaching the bank's server. Now since the data never
reached the bank's server, that password number is still valid and in the
hands of the attacker.
<br> Now the correct customer has to be blocked from connecting to
the bank's site again before the password number is decrypted. The attacker
returns some error message to all GETs to the bank's address by the customer.
The customer might not realize that this is a fraud attempt and he perhaps
just complains to the bank or his ISP. If brute-forcing the 40-bit session
key used by the customer's client to encrypt the password number takes
only a couple hours it might be possible to pull this off, before proper
authorities are alerted or the account closed. If the verification number
requested by the bank is one of those held by the attacker (the bank uses
an index letter to identify the number), he can make a transaction order
to move the money to his account.
<p>Note that with SSL v3 the session keys can be changed during the session
(perhaps every page) and that there are actually two keys, one for each
direction. This increases the key cracking effort needed in the surveillance
part of the operation, but in the attack part many key cracks are not needed
if the correct packet can be identified by traffic analysis (how many exchanges
needed to reach the state where pw number is sent by the client's browser
can be traced in the surveillance part). At best it requires brute forcing
just one RC4-40 key, a feat that can be accomplished with a powerful Beowulf
cluster in a matter of hours.
<p>So what we learn from this? Do not use 40-bit SSL-security to protect
people's money. Go for Global ID so that people using international browser
versions can be protected with full 128-bit keys (and 1024 for RSA).
<p>Jere Hakanen</html>
==============26AD770B060C321C6C6E55E5==
------------------------------
** 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
******************************
