Re: entropy depletion (was: SSL/TLS passive sniffing)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Enzo Michelangeli Sent: Tuesday, January 04, 2005 7:50 PM This entropy depletion issue keeps coming up every now and then, but I still don't understand how it is supposed to happen. If the PRNG uses a really non-invertible algorithm (or one invertible only with intractable complexity), its output gives no insight whatsoever on its internal state. I see much misunderstanding of entropy depletion and many misstatements because of it. It is true you don't know what the internal state is but the number of possible internal states tends to reduce with every update of the internal state. See Random Mapping Statistics by Philippe Flajolet and Andrew M. Odlyzko (Proceedings of the workshop on the theory and application of cryptographic techniques on Advances in cryptology, Houthalen, Belgium, Pages: 329 - 354, year 1990) for a thorough discussion. The jist is that a well behaved state update function for a PRNG will have one very long cycle. This cycle will be shorter than the number of possible values that the state can hold. States not on the cycle are on branches of states that eventually land on the cycle. Flajolet and Odlyzko go on to show that the expected cycle length for a 1000 bit state will be around 2^500 iterations. So, you start your PRNG by filling the state with 1000 bits of real entropy. You have 2^1000 possible states. You use your PRNG and update the state. Now, there are a certain number of states that the PRNG cannot be in. After one state update, the PRNG cannot be in the states at the ends of the chains of states branched off from the aforementioned cycle. This means that, after one state update, you have slightly less than 1000 bits of entropy. When you update the state again, you now have more states that the PRNG cannot be in, thus reducing your entropy again. Every time you use your PRNG, you reduce your entropy in this way and you keep on doing so in an asymptotic way until, after many many iterations, you are close enough to 500 bits that you don't care anymore. In the real world, our PRNG state update functions are complex enough that we don't know if they are well behaved. Nobody knows how many cycles exist in a PRNG state update function using, for example, SHA-1. You run your PRNG long enough and you may actually hit a state that, when updated, maps onto itself. When this occurs your PRNG will start producing the same bits over and over again. It would be worse if you hit a cycle of 10,000 or so because you may never realize it. I don't know of any work on how not-so well behaved PRNG state update function lose entropy. I figure the state update functions we as a community use in what we consider to be well designed PRNGs probably have multiple long cycles and maybe a few scary short cycles that are so unlikely that nobody has hit them. I don't even know what multiple cycles means for entropy. Because of the lack of knowledge, cryptographic PRNGs have more state than they probably need just to assure enough entropy - at least that is one thing I look for when looking at cryptographic PRNGs. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion (was: SSL/TLS passive sniffing)
On Thu, Jan 06, 2005 at 04:35:05PM +0800, Enzo Michelangeli wrote: By how much exactly? I'd say, _under the hypothesis that the one-way function can't be broken and other attacks fail_, exactly zero; in the real world, maybe a little more. Unfortunately for your analysis, *entropy* assumes that there is infinite compute capacity. From an information-theoretic point of view, there is NO SUCH THING as a perfect one-way function. -- Taral [EMAIL PROTECTED] This message is digitally signed. Please PGP encrypt mail to me. A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpRflyK9JPXi.pgp Description: PGP signature
OpenVPN and SSL VPNs
Hi, I already stumbled several times over OpenVPN but never had the time to look at it in detail. Now I had but didn't find many infos except many lucky users and few negative outputs. I have two open points: a) It would be good to hear from this community if there are any negative aspects of OpenVPN (vs. IPsec VPNs). b) I still have a problem with the term SSL/TLS VPN. What OpenVPN seems to do is use SSL for authentication and key exchange/rekeying, but does use ESP similar data protection schemes/formats. Does the usage of SSL on a control plane make OpenVPN an SSL VPN? This sounds to me like calling something a car just because it uses a steering wheel... So far I thought about SSL VPNs as doing everything over SSL (with the known disadvantages...). tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA signature.asc Description: OpenPGP digital signature
Re: entropy depletion (was: SSL/TLS passive sniffing)
| You're letting your intuition about usable randomness run roughshod
| over the formal definition of entropy. Taking bits out of the PRNG
| *does* reduce its entropy.
|
| By how much exactly? I'd say, _under the hypothesis that the one-way
| function can't be broken and other attacks fail_, exactly zero; in the
| real world, maybe a little more. But in
| /usr/src/linux/drivers/char/random.c I see that the extract_entropy()
| function, directly called by the exported kernel interface
| get_random_bytes(), states:
|
| if (r-entropy_count / 8 = nbytes)
| r-entropy_count -= nbytes*8;
| else
| r-entropy_count = 0;
|
| ...which appears to assume that the pool's entropy (the upper bound of
| which is POOLBITS, defined equal to 4096) drops by a figure equal to the
| number of bits that are extracted (nbytes*8). This would only make sense
| if those bits weren't passed through one-way hashing.
The argument you are making is that because the one-way function isn't
reversible, generating values from the pool using it doesn't decrease its
computational entropy. (Its mathematical entropy is certainly depleted,
since that doesn't involve computational difficulty. But we'll grant that
that doesn't matter.)
The problem with this argument is that it gives you no information about the
unpredictablity of the random numbers generated. Here's an algorithm based
on your argument:
Pool: bits[512]
initializePool()
{ Fill Pool with 512 random bits; }
getRandom() : bits[160]
{ return(SHA(bits));
}
By your argument, seeing the result of a call to getRandom() does not reduce
the effective entropy of the pool at all; it remains random. We certainly
believe that applying SHA to a random collection of bits produces a random
value. So, indeed, the result of getRandom() is ... random. It's also
constant.
Granted, no one would implement a random number generator this way. But
*why*? What is it you have to change to make this correct? Why? Can you
prove it? Just saying you have to change the pool after every call
won't work:
getRandom() : bits[160]
{ Rotate bits left by 1 bit;
return(SHA(bits));
}
This (seems to) generated 512 random values, then repeats. Just what *is*
good enough?
-- Jerry
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[ISN] SSL VPNs Will Grow 54% A Year, Become Defacto Access Standard: Report
--- begin forwarded text Date: Fri, 7 Jan 2005 06:41:49 -0600 (CST) From: InfoSec News [EMAIL PROTECTED] To: isn@attrition.org Subject: [ISN] SSL VPNs Will Grow 54% A Year, Become Defacto Access Standard: Report Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] http://www.informationweek.com/story/showArticle.jhtml;jsessionid=NIOHIDQYVVDQSQSNDBESKHA?articleID=56900844 By Matthew Friedman Networking Pipeline Jan. 5, 2005 Spending on Secure Sockets Layer Virtual Private Networks (SSL VPN) will grow at a 53% compound annual growth rate, and SSL VPNs will surpass traditional IPsec VPNs as the de-facto remote access security standard by 2008, according to a new report from Forrester Research. In SSL VPNs Poised for Significant Growth, Forrester associate analyst Robert Whiteley says companies are attracted by the technology's application-level simplicity. Unlike IPsec VPNs, which require special client software to access the network, SSL VPN supports a wide range of devices, from desktop computers to PDAs, and applications, while offering network administrators greater granularity of user information and providing better endpoint security. According to the report, some 44% of American businesses have deployed SSL VPNs, spending $97 million on the technology last year alone. Despite the impressive adoption rate for a technology that has been in the business mainstream for less than a year, Forrester expects SSL VPN deployments to continue to take off, with the market growing at a 53% compound annual growth rate to $1.2 billion in 2004. SSL VPNs are already well-entrenched in the financial and business services industries and in the public sector. Driven by the need to ensure endpoint security for online services, the financial services industry can boast a 56% penetration rate, with business services just behind at 51%. In both cases, Whiteley predicts a compound annual growth of 34% to 2010 which, though impressive, pales beside the expected SSL VPN growth in late-adopting industries. Indeed, Whiteley writes that retail and manufacturing are poised to leap into SSL VPN with gusto over the next few years. Retail and wholesale allocates 7.8% of its IT spend to security more than even financial services, he notes. This vertical shows the most SSL VPN potential because of its eye toward security, relatively little penetration to date, and the need for large, distributed deployments resulting in 82% annual market growth through 2010. Though only 29% of manufacturers are currently invested in SSL VPNs, Whitely expects that to change dramatically through 2010, predicting a phenomenal 94% compound annual growth rate. IPSec was a poor fit for this vertical's needs, Whiteley observes, but the application-layer flexibility of SSL VPNs should spur rapid adoption. Manufacturing companies typically don't provide employees with corporate-managed laptops, he writes. Thus, SSL VPNs allows a 'bring-your-own computer' model where manufacturing companies still control security and user policy but don't have to incur the cost of unnecessary IT infrastructure. _ Open Source Vulnerability Database (OSVDB) Everything is Vulnerable - http://www.osvdb.org/ --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion
Jerrold Leichter asked: random number generator this way. Just what *is* good enough? That's a good question. I think there is a good answer. It sheds light on the distinction of pseudorandomness versus entropy: A long string produced by a good PRNG is conditionally compressible in the sense that we know there exists a shorter representation, but at the same time we believe it to be conditionally incompressible in the sense that the adversaries have no feasible way of finding a shorter representation. In contrast, A long string produced by a HESG is unconditionally, absolutely incompressible. There does not exist a shorter representation. There cannot possibly exist a shorter representation. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Entropy and PRNGs
Given recent discussion, this is perhaps a good moment to point at a paper I wrote a while back on PRNGs for Dr. Dobbs, where, I'll bet, most of you didn't read it. http://www.apache-ssl.org/randomness.pdf One day, I plan to implement the API I describe there. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[fc-announce] FC05 registration to open next week
--- begin forwarded text User-Agent: Microsoft-Entourage/11.1.0.040913 From: Stuart E. Schechter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [fc-announce] FC05 registration to open next week Sender: [EMAIL PROTECTED] Date: Fri, 07 Jan 2005 11:00:54 -0500 Registration for Financial Cryptography and Data Security 2005 will open early next week. My apologies for the delays and thanks for your patience. In the meantime, please do make sure that you've made all your other travel arrangements (flight/hotel/car rental). For more information, see http://fc05.ifca.ai/travel.html Please don't hesitate to get in touch if there's any further information that I can provide you. Best regards Stuart Schechter General Chair Financial Cryptography and Data Security 2005 ___ fc-announce mailing list [EMAIL PROTECTED] http://mail.ifca.ai/mailman/listinfo/fc-announce --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion
| | random number generator this way. Just what *is* | good enough? | | That's a good question. I think there is a good answer. It | sheds light on the distinction of pseudorandomness versus | entropy: | | A long string produced by a good PRNG is conditionally | compressible in the sense that we know there exists a shorter | representation, but at the same time we believe it to be | conditionally incompressible in the sense that the adversaries | have no feasible way of finding a shorter representation. | | In contrast, | | A long string produced by a HESG is unconditionally, absolutely | incompressible. There does not exist a shorter representation. | There cannot possibly exist a shorter representation. You're using Kolgomorv/Chaitin complexity here, but unfortunately that's a bit hard to apply. *Any* string has a shorter representation - if I get to specify the model *after* you choose the string. K/C complexity is robust when you talk about sets of possible strings, because playing around with the machine can only shorten a fixed number of them. Turning that into a notion useful for cryptography is a bit tougher - and in any case, if you want to get at PRNG's, you need to get at K/C complexity with trapdoor information: The bit stream may *look* uncompressible, but given the internal state, it is easily produced. More generally: We're talking about stretching entropy here. There are certainly theoretical results in that direction, the one usually mentioned being the BBS bit generator, which takes k bits of entropy and gives you p(k) (for some polynomial p) bits that are polynomially-indistinguishable from random bits. But you (a) need some significant work to set this up and prove it; (b) BBS generators are slow. A simpler approach that does work (in some sense) is: Choose a random starting value R, and a number k. Compute SHA^i(R) for i from 0 to k. Emit these values *backwards*. Then given the first k-1 outputs, an attacker cannot determine the next one (under the standard hypotheses about SHA). Unfortunately, this is useless as, say, a key generator: If you send me the k-1'st output for use as a key, I can't determine what your *next* key will be - but I can trivially read your preceding k-2 sessions. The idea that revealing just the hash of random bits doesn't reduce the effective entropy sounds great, but it's naive. It's like the argument that if H is a good hash function, then H(K || message) is a good MAC. Not quite. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion (was: SSL/TLS passive sniffing)
From: John Denker [EMAIL PROTECTED] Sent: Jan 5, 2005 2:06 PM To: Enzo Michelangeli [EMAIL PROTECTED] Cc: cryptography@metzdowd.com Subject: Re: entropy depletion (was: SSL/TLS passive sniffing) ... You're letting your intuition about usable randomness run roughshod over the formal definition of entropy. Taking bits out of the PRNG *does* reduce its entropy. This may not (and in many applications does not) reduce its ability to produce useful randomness. Right. The critical question is whether the PRNG part gets to a secure state, which basically means a state the attacker can't guess in the amount of work he's able to do. If the PRNG gets to a secure state before generating any output, then assuming the PRNG algorithm is secure, the outputs are indistinguishable from random. The discussion of how much fresh entropy is coming in is sometimes a bit misleading. If you shove 64 bits of entropy in, then generate a 128-bit output, then shove another 64 bits of entropy in, you don't end up in a secure state, because an attacker can guess your first 64 bits of entropy from your first output. What matters is how much entropy is shoved in between the time when the PRNG is in a known state, and the time when it's used to generate an output. --John Kelsey - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: entropy depletion
I wrote: A long string produced by a good PRNG is conditionally compressible in the sense that we know there exists a shorter representation, but at the same time we believe it to be conditionally incompressible in the sense that the adversaries have no feasible way of finding a shorter representation. In contrast, A long string produced by a HESG is unconditionally, absolutely incompressible. There does not exist a shorter representation. There cannot possibly exist a shorter representation. Jerrold Leichter wrote: You're using Kolgomorv/Chaitin complexity here, but unfortunately that's a bit hard to apply. It works for me. It is in principle hard to apply exactly, but in practice it's easy to apply to a good-enough approximation. In particular, for any given PRNG I can readily exhibit the compressed representation of its output, namely the PRNG itself along with the initial internal state. K/C complexity is robust when you talk about sets of possible strings, because playing around with the machine can only shorten a fixed number of them. Yes, I stand corrected. I sloppily wrote string when I should have written strings. Specifically, the set of strings collectively cannot be compressed at all. As for each string individually, it is not compressible either, except possibly for trivially rare cases and/or trivial amounts of compression. *Any* string has a shorter representation - if I get to specify the model *after* you choose the string. Yes, for one particular string, or very small set of strings. You get to choose the model, but you only get to choose once. So you can only compress a trivially small subset of all the output strings, unless we're talking about a trivial degree of compression. In any case, you derive no cryptanalytic advantage from compression based on an ad-hoc model, so you might as well not bother, and just stick to some convenient standard model. Turning that into a notion useful for cryptography is a bit tougher - and in any case, if you want to get at PRNG's, you need to get at K/C complexity with trapdoor information: The bit stream may *look* uncompressible, but given the internal state, it is easily produced. Isn't that what I said, as quoted above? I said it was conditionally compressible. It should go without saying that knowing the trapdoor information, i.e. the internal state, is the sufficient condition for feasible compressibility. More generally: We're talking about stretching entropy here. Well, I can agree that that's what we _should_ be talking about. I like to speak of an SRNG (stretched random number generator) as having a nonzero lower bound on the entropy density of the output, as opposed to a traditional PRNG where the entropy density is asymptotically zero. There are certainly theoretical results in that direction, the one usually mentioned being the BBS bit generator, which takes k bits of entropy and gives you p(k) (for some polynomial p) bits that are polynomially-indistinguishable from random bits. But you (a) need some significant work to set this up and prove it; (b) BBS generators are slow. A simpler approach that does work (in some sense) is: Choose a random starting value R, and a number k. Compute SHA^i(R) for i from 0 to k. Emit these values *backwards*. Then given the first k-1 outputs, an attacker cannot determine the next one (under the standard hypotheses about SHA). Unfortunately, this is useless as, say, a key generator: If you send me the k-1'st output for use as a key, I can't determine what your *next* key will be - but I can trivially read your preceding k-2 sessions. When I wanted to stretch entropy, I implemented the Yarrow approach, i.e. encrypted counter plus systematic reseeding: http://www.av8n.com/turbid/paper/turbid.htm#sec-srandom It's not slow, and appears incomparably stronger than the SHA^i example. Indeed it does not have any serious weaknesses that I know of. If anybody knows of any flaws, please explain! The idea that revealing just the hash of random bits doesn't reduce the effective entropy sounds great, but it's naive. We agree it's naive. Indeed it's just wrong, as I've said N times over the last couple of days. And please let's not talk about effective entropy. I have no idea what ineffective entropy is supposed to be, and I can't imagine any way that makes sense to distinguish effective entropy from plain old entropy. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[PadLock] PadLock patches for linux kernel 2.6.10 (fwd from [EMAIL PROTECTED])
From: Michal Ludvig [EMAIL PROTECTED] Subject: [PadLock] PadLock patches for linux kernel 2.6.10 To: [EMAIL PROTECTED] Date: Fri, 7 Jan 2005 17:24:02 +0100 (CET) From: Michal Ludvig [EMAIL PROTECTED] Date: Fri, 7 Jan 2005 17:24:02 +0100 (CET) To: [EMAIL PROTECTED] Subject: [PadLock] PadLock patches for linux kernel 2.6.10 Hi all, Updated VIA PadLock drivers for linux kernel 2.6.10 are available at http://www.logix.cz/michal/devel/padlock/ The recently reported problem with GCC 3.4.3 is addressed there. Good news - initial PadLock support was accepted into the vanilla kernel in 2.6.10-bk1 (i.e. right after 2.6.10 was released). Official kernel 2.6.11 will have it without patching. Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal ___ PadLock mailing list [EMAIL PROTECTED] http://lists.logix.cz/mailman/listinfo/padlock -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net pgpIVdKKi4vFz.pgp Description: PGP signature
Atom demo fixes quantum errors
http://www.alwayson-network.com/comments.php?id=7746_0_6_0_C Always On Atom demo fixes quantum errors TRN NewsTeam | TRN [] | POSTED: 01.07.05 @09:47 Although quantum computers promise fantastic speed for certain types of very large problems, the logical components of quantum computers -- quantum bits -- are quite fragile, which makes for a large number of errors that must be corrected. Researchers from the National Institute of Standards and Technology have demonstrated a way to correct errors in qubits of beryllium ions held in an electromagnetic trap. The ions represent a 1 or 0 of computer information in their spin, which can be pictured as the counterclockwise or clockwise spin of a top. One way to carry out quantum computing is to take advantage of a weird trait of quantum particles -- they can become entangled, or linked, so that properties like spin remain in lockstep. The researchers' prototype uses lasers to control the qubits' states and electrodes to move them together, which allows them to be entangled. The researchers set a primary qubit to a particular state and entangled it with two other qubits. They deliberately induced an error and then disentangled the qubits by separating them. They measured the other two qubits to determine how the primary qubit needed to be corrected. Quantum error correction schemes have been well explored theoretically, but the researchers' experiment was the first demonstration of a repeatable error-correction procedure and the first using trapped ions, which are a promising candidate for practical quantum computers. Practical quantum computing is a decade or more away. The method could be used in quantum communications applications like quantum cryptography within a few years, according to the researchers. The work appeared in the December 2, 2004 issue of Nature. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AOL Help : About AOL® PassCode
In article [EMAIL PROTECTED], Joerg Schneider
[EMAIL PROTECTED] writes
Florian Weimer wrote:
I think you can forward the PassCode to AOL once the victim has
entered it on a phishing site. Tokens à la SecurID can only help if
Indeed.
the phishing schemes *require* delayed exploitation of obtained
credentials, and I don't think we should make this assumption. Online
MITM attacks are not prevented.
So, PassCode and similar forms of authentication help against the
current crop of phishing attacks, but that is likely to change if
PassCode gets used more widely and/or protects something of interest to
phishers.
as in the story of the two hunters and the bear ... the banks only need
to outrun another vulnerable target:
http://www.netfunny.com/rhf/jokes/89q3/oldbear.555.html
so making passive password/PIN collection ineffective and requiring
phishers to operate in real-time may be a sufficient win.
Actually I have been waiting for phishing with MITM to appear for some
time (I haven't any yet - if somebody has, I'd be interested to hear
about),
I've been shown something similar last July ... which was, IIRC, a
PayPal phish where the web page you went to checked that the password it
was given was in fact valid. It wasn't a full-scale MITM attack, but it
did have some real-time elements.
I haven't been bothering to look at phishing sites recently, so I don't
know if the technology to do this has become the general state of the
art, or if it was just one gangs unique coding style ?
because it has some advantages for the attacker:
* he doesn't have to bother to (partially) copy the target web site
* easy to implement - plug an off-the-shelf mod_perl module for reverse
proxy into your apache and add 10 minutes for configuration. You'll find
the passwords in the log file. Add some simple filters to attack PassCode.
* more stealthy, because users see exactly, what they are used to, e.g.
for online banking they see account balance etc. To attack money
transfers protected by PassCode, the attacker could substitute account
and amount and manipulate the server response to show what was entered
by user.
this is the fundamental problem with using the passcode, the user is
signing just the single bit I authorise rather than the full bag of
bits {amount, payee, timestamp} ... as soon as you write out formally
what is going on the shortcoming is entirely obvious
Assuming that MITM phishing will begin to show up and agreeing that
PassCode over SSL is not the solution - what can be done to counter
those attacks?
Mutual authentication + establishment of a secure channel should do the
trick. SSL with client authentication comes to my mind...
The problem with that is that people want (or at least think they want)
to use their online banking from home, from work and from a cybercafe
whilst they are on holiday or a business trip. Carting around the
credentials (and a secure way of checking them) is a non-starter
However, the banks could do a lot by starting to distinguish between
run-of-the-mill transactions : pay my gas bill and more sensitive ones
such as set up a new payee (or indeed change my gas company to
Nigerian OilGas). Insisting that the sensitive ones were only done
from the secured (and credential rich) home site would help. They could
also check the IP address of the connection and form a view as to its
likely validity!
Yo rule out a MITM one might employ a secure side-channel (SMS text
message to one's mobile phone perhaps -- certainly a very plausible
approach in SMS-aware Europe) ... some banks are already using this; but
only as a cheap replacement for a SecureID :( ... so it's ineffective.
Now if Bill's browser could display the last six digits of the SSL key
then those could be compared with the SMS message and the customer would
know that they were safethe banks might even go for this
solution because it dumps the decision to go ahead (and hence the risk
as well) onto the customer :)
--
richard Richard Clayton
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. Benjamin Franklin
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
