And it would be a little pointless to only allow the past 20 _successful_ inputs, because they would all match the original fingerprint and no drift would occur.
To millisecond accuracy? I don't think so. The verification algorithm has to accept each correct keypress within some margin of error; they won't all be exactly the same. Then the last 20 successful samples can be averaged and used as the baseline for new verifications each time.
Mr. Cracker either doesn't know the correct keys, or will be so far off-base with regard to keystroke timing, that his attempts will not be successful, not be included in the average, and so not be able to skew the baseline.
as far as I can tell, Sun has made no legally binding commitment to allow "anyone" to implement Java.
Does this count?
Sun Microsystems, Inc. (SUN) hereby grants to you a fully paid, nonexclusive, nontransferable, perpetual, worldwide limited license (without the right to sublicense) under SUN's intellectual property rights that are essential to practice this specification. This license allows and is limited to the creation and distribution of clean room implementations of this specification that: (i) include a complete implementation of the current version of this specification without subsetting or supersetting; (ii) implement all the interfaces and functionality of the required packages of the Java 2 Platform, Standard Edition, as defined by SUN, without subsetting or supersetting; (iii) do not add any additional packages, classes, or interfaces to the java.* or javax.* packages or their subpackages; (iv) pass all test suites relating to the most recent published version of the specification of the Java 2 Platform, Standard Edition, that are available from SUN six (6) months prior to any beta release of the clean room implementation or upgrade thereto; (v) do not derive from SUN source code or binary materials; and (vi) do not include any SUN source code or binary materials without an appropriate and separate license from SUN.
It's from the copyright statement for The Java Language Specification, Second Edition by Sun. You can download your own copy, complete with this license, here.
what about the spammers with... a spare computer to install linux and sendmail?
Well, that's kind of the target victim of this program, actually. The people who get their connections slowed down are the ones who use their own SMTP client to connect directly to the tar-proxy. (And not the ones who use open SMTP relays, as the parent post to yours points out.)
So the next time you feel like condemning Hebrew law ("an eye for an eye") as a "morally bankrupt code", please consider the other options available at the time.
Um... actually the idea of 'an eye for an eye' and 'a tooth for a tooth' was pretty much taken straight out of the Code of Hammurabi.
The Code of Hammurabi is the oldest known written legal code, older than the Hebrew law which you are attempting to contrast it with, and is considered to be the inspiration for most legal codes which followed it.
The Jews didn't invent the principle, they inherited it from the Babylonians.
It sounds like the BBC reporters may have actually talked to the researchers, rather than just repeating what they posted online.
Most people here seem to be latching on to this quote, as well as the one on the swiss site which mentions that other web-based services using SSL may also be vulnerable, and assuming that a contradiction exists.
By "a different type of SSL," they may be referring to the SET protocol that machines use when communicating directly with credit card companies. It's been a long time since I looked at SET authentication, but it may not be vulnerable to this sort of attack.
I can imaging the BBC reporters learning this, through talking to the researchers, and eventually coming up with that line, which implies that e-commerce sites over SSL are safe (which is very likely wrong)
The exploit is a timing attack; a side-channel attack against an actual implementation of the protocol, not the protocol itself.
Nearly every crypto protocol has 'flaws' such as this, and power-analysis 'flaws', and other sorts of issues which don't involve the protocol itself, but the fact that it has been implemented in a real-world device.
In nearly every case, once an attack like this becomes known, the response should be simply "so don't implement it like that anymore". The protocol itself doesn't actually change.
The attack works because the attacker can distinguish between an error in the message padding and an error in the MAC, by careful timing of the wait for the response from the server.
This is possible because SSL implementations typically abort processing a message immediately if the padding is incorrect, without testing the MAC, meaning that they respond a couple of milliseconds sooner than they would have if the padding was correct.
The openssl countermeasure is simply to perform a MAC test in all cases, whether the padding was correct or not, before returning an error to the client.
Many people read/. with signature lines turned off. Also, your sig won't be included with your post when this thread gets archived, and if you decide to change your sig tomorrow, then your post won't make any sense at all.
Re:And this is relevant because?
on
Copyright Rumblings
·
· Score: 4, Informative
Last I checked US went in for stricter copyright terms to comply with the European agreements. That gave as the +70 years.
The European agreement you're probably thinking of is the Berne Convention, which sets a minimum copyright term for signatory countries of 50 years after the author's death. That is the term that much of the world (including Canada and Australia) still use. The US is actually in the minority, having increased copyright terms past this.
Isn't the point so that lazy people don't have to be bothered with remembering passwords? Doesn't this defeat the purpose? (sigh)
<sigh> No, that isn't the point at all. The technology is intended to stop the problem of people walking away from their computers ("I'm sure I'm only going to be away for a minute" -- gets dragged into a five hour meeting...) without locking them first.
The article even says that it was designed for use by people who are already using passwords, but are bothered by the inconvenience of having to lock the computer, and reenter the password every time they are called away for a few seconds. Not because they don't want to remember a password, but because it's a hassle to have to enter it all the time.
<pedantic>
"TEMPEST" was actually the name of the US military program for emissions security, not the actual insecure emissions themselves.
</pedantic>
That's right, the name TEMPEST applies to the shielding; the emissions are often referred to as 'Van Eck radiation,' at least in the civilian world, after Wim Van Eck, who published the original paper on the subject in 1985
I think C++ treats string literals as arrays of characters because strings *are* arrays of characters
That's true, strings are arrays (or at least sequences) of characters. The problems that the author refers to arise from the fact that C++ (and C) treat strings as null-terminated arrays of characters.
This means that: 1) You can't determine the length of a string without a linear-time operation; and 2) You can't ever have a string which includes an ASCII NUL character.
What else could they be?
Well, for one, you could get rid of the terminator and prefix each string with a byte (or a word) containing its length. Pascal does this; so does Java. I believe that PHP uses this representation, and I'm sure that a boatload of other languages do as well.
You aren't really wasting any more space than the C representation, and you gain the ability to include any binary data you want within a string, and to determine the length of a string with a constant-time operation. Most string operations are not made significantly more complex with this representation, either.
All web site disclaimers say the company can change the text as they please (but some say without notification/notice and some say they will notify you by 30 days.)
Yes.
All agreements say if one part is invalid, the rest is still valid.
Yes.
All agreements say you are responsible for taxes and anything that happens to you from using their services.
Yes.
Each of your points is correct (for sufficiently loose interpretations of the word 'all').
I'm not really sure what points of mine you're trying to respond to here -- what I'm trying to point out here is that this agreement appears to explicitly say: "By clicking here now, you agree to be bound in the future by whatever we choose to write in this space, forever." And it does appear to be forever, too -- I couldn't find a clause in the agreement which explains how you could get yourself out of this agreement if they changed the terms against your liking.
I do tend to read these agreements, or at least skim them, when they are important to me, and I've never encountered language like that before.
If you still insist that such wording is standard in online service usage agreements, perhaps you could provide a link or two.
I read the whole thing. There's nothing particularly bad in there.
Are you sure? You'd better read it again.
It's still okay? Well, you'd better read it again tomorrow, just to be sure.
From the agreement:
American Airlines reserves the right to change this Agreement and to make changes to any of the products or programs described in the Site at any time without notice or liability. Any such revisions are prospectively binding on you and therefore you should periodically visit this page when you use the Site to review the then current Agreement that binds you.
After reading this far, I came to the conclusion that there's no point reading any further, since they can change the agreement at any time, and you agree to let them.
They could conceivably have changed the entire text of the agreement between the time you get the original text and the time you post your acceptance. (This is especially likely given the amount of time it would take to read and understand the entire agreement).
I don't know about your experience with these things, but this looks like about the most offensive language I've ever seen in a set of terms and conditions like this.
Yah, 'cos you know colors add in your head so much easier than numbers.
Sure, why not? They're both just arbitrary symbols.
If I look in my wallet, and I've got two blues, a red and a green, then I know I've got $80. I don't do any algebraic addition, but then, neither do you when you see two $5's, a $20 and a $50.
Slashdot Mirror
To millisecond accuracy? I don't think so. The verification algorithm has to accept each correct keypress within some margin of error; they won't all be exactly the same. Then the last 20 successful samples can be averaged and used as the baseline for new verifications each time.
Mr. Cracker either doesn't know the correct keys, or will be so far off-base with regard to keystroke timing, that his attempts will not be successful, not be included in the average, and so not be able to skew the baseline.
Yes they do.
Don't they call the quarter-pounder with cheese a Royale with cheese?
No they don't. Watch the movie again; that's France.
Of course, the last time the Canadian $20 was changed was back around 1986, and people still knew what a pound was back then :)
But then, Canadian bills have never said "This note is legal tender for all debts public and private", so the whole anecdote could just be made up.
No, it's actually very close to a foot. (c ~= 29.9 cm / ns)
Yes, even if you do seem to be reusing someone else's work
Does this count?
It's from the copyright statement for The Java Language Specification, Second Edition by Sun. You can download your own copy, complete with this license, here.
So, the original post was the bait that attracted your flame, and, therefore, flamebait.
The original moderation stands.
Well, that's kind of the target victim of this program, actually. The people who get their connections slowed down are the ones who use their own SMTP client to connect directly to the tar-proxy. (And not the ones who use open SMTP relays, as the parent post to yours points out.)
Um... actually the idea of 'an eye for an eye' and 'a tooth for a tooth' was pretty much taken straight out of the Code of Hammurabi.
Check out paragraphs 196 and 200, specifically.
The Code of Hammurabi is the oldest known written legal code, older than the Hebrew law which you are attempting to contrast it with, and is considered to be the inspiration for most legal codes which followed it.
The Jews didn't invent the principle, they inherited it from the Babylonians.
Most people here seem to be latching on to this quote, as well as the one on the swiss site which mentions that other web-based services using SSL may also be vulnerable, and assuming that a contradiction exists.
By "a different type of SSL," they may be referring to the SET protocol that machines use when communicating directly with credit card companies. It's been a long time since I looked at SET authentication, but it may not be vulnerable to this sort of attack.
I can imaging the BBC reporters learning this, through talking to the researchers, and eventually coming up with that line, which implies that e-commerce sites over SSL are safe (which is very likely wrong)
Nearly every crypto protocol has 'flaws' such as this, and power-analysis 'flaws', and other sorts of issues which don't involve the protocol itself, but the fact that it has been implemented in a real-world device.
In nearly every case, once an attack like this becomes known, the response should be simply "so don't implement it like that anymore". The protocol itself doesn't actually change.
This is possible because SSL implementations typically abort processing a message immediately if the padding is incorrect, without testing the MAC, meaning that they respond a couple of milliseconds sooner than they would have if the padding was correct.
The openssl countermeasure is simply to perform a MAC test in all cases, whether the padding was correct or not, before returning an error to the client.
BTW, RFC2616 has obsoleted RFC2068.
Also, sections 3.12 and 14.35 are pretty good, if anyone here is looking for info on resuming HTTP downloads.
Many people read /. with signature lines turned off. Also, your sig won't be included with your post when this thread gets archived, and if you decide to change your sig tomorrow, then your post won't make any sense at all.
The European agreement you're probably thinking of is the Berne Convention, which sets a minimum copyright term for signatory countries of 50 years after the author's death. That is the term that much of the world (including Canada and Australia) still use. The US is actually in the minority, having increased copyright terms past this.
And when that didn't pan out, they started using .NET... any day now they're going to accuse the gtld servers of domain-squatting :)
You don't. You can get 6.0e23 molecules, easily:
(18.0 g/mol) * (1 mL/g) * (6.0e23 molecules/mol) / (18 mL) = 6.0e23 molecules / 18 mL
He was just off by an order of magnitude or so.
These guys are number 2; they try harder
<sigh> No, that isn't the point at all. The technology is intended to stop the problem of people walking away from their computers ("I'm sure I'm only going to be away for a minute" -- gets dragged into a five hour meeting...) without locking them first.
The article even says that it was designed for use by people who are already using passwords, but are bothered by the inconvenience of having to lock the computer, and reenter the password every time they are called away for a few seconds. Not because they don't want to remember a password, but because it's a hassle to have to enter it all the time.
<pedantic>
"TEMPEST" was actually the name of the US military program for emissions security, not the actual insecure emissions themselves.
</pedantic>
That's right, the name TEMPEST applies to the shielding; the emissions are often referred to as 'Van Eck radiation,' at least in the civilian world, after Wim Van Eck, who published the original paper on the subject in 1985
</offtopic>
That's true, strings are arrays (or at least sequences) of characters. The problems that the author refers to arise from the fact that C++ (and C) treat strings as null-terminated arrays of characters.
This means that: 1) You can't determine the length of a string without a linear-time operation; and 2) You can't ever have a string which includes an ASCII NUL character.
What else could they be?
Well, for one, you could get rid of the terminator and prefix each string with a byte (or a word) containing its length. Pascal does this; so does Java. I believe that PHP uses this representation, and I'm sure that a boatload of other languages do as well.
You aren't really wasting any more space than the C representation, and you gain the ability to include any binary data you want within a string, and to determine the length of a string with a constant-time operation. Most string operations are not made significantly more complex with this representation, either.
I think that any more would probably just be confusing.
I thought we were talking about virtual Las Vegas here -- forget the remote controlled fridge, I want a virtual cocktail waitress to get me that beer!
All web site disclaimers say the company can change the text as they please (but some say without notification/notice and some say they will notify you by 30 days.)
Yes.
All agreements say if one part is invalid, the rest is still valid.
Yes.
All agreements say you are responsible for taxes and anything that happens to you from using their services.
Yes.
Each of your points is correct (for sufficiently loose interpretations of the word 'all').
I'm not really sure what points of mine you're trying to respond to here -- what I'm trying to point out here is that this agreement appears to explicitly say: "By clicking here now, you agree to be bound in the future by whatever we choose to write in this space, forever." And it does appear to be forever, too -- I couldn't find a clause in the agreement which explains how you could get yourself out of this agreement if they changed the terms against your liking.
I do tend to read these agreements, or at least skim them, when they are important to me, and I've never encountered language like that before.
If you still insist that such wording is standard in online service usage agreements, perhaps you could provide a link or two.
Are you sure? You'd better read it again.
It's still okay? Well, you'd better read it again tomorrow, just to be sure.
From the agreement:
After reading this far, I came to the conclusion that there's no point reading any further, since they can change the agreement at any time, and you agree to let them.They could conceivably have changed the entire text of the agreement between the time you get the original text and the time you post your acceptance. (This is especially likely given the amount of time it would take to read and understand the entire agreement).
I don't know about your experience with these things, but this looks like about the most offensive language I've ever seen in a set of terms and conditions like this.
Sure, why not? They're both just arbitrary symbols.
If I look in my wallet, and I've got two blues, a red and a green, then I know I've got $80. I don't do any algebraic addition, but then, neither do you when you see two $5's, a $20 and a $50.