As others have indicated, the primary stated use of heartbeat is for DTLS, which is not over TCP.
The payload length is not actually superfluous. The packet has an arbitrary amount of both payload and padding, of which only the payload is echoed to the sender. Roughly: { uint16 payload_len; char payload[]; char padding[]; } The intent of payload_len is to tell you which of the bytes following it are payload rather than padding. Of course, you need to check that it's less than the remaining data in the packet. (Per the spec, at least 16 less -- at least 16 bytes of random padding are required.)
He didn't say they weren't different. He said people think that vinyl is "more genuine" or "more accurate" than digital. Genuine is a weasel word -- it's ill-defined. (Probably the most reasonable definition here is "closest to how the creator of the music intended for you to hear it". But, I digress. It's hard to measure.) Vinyl is certainly less accurate than a good digital representation.
It can be different, though, because it introduces flaws that the digital representation doesn't have. Maybe those flaws make the music "better" in some sense, but not "more accurate".
You don't. Your field of vision through the back window is tiny compared to the field of vision of the camera.
I thought they were a stupid gimmick until I got a car with one. Now I curse every time I drive a car that doesn't have one, because backing up is a lot harder.
He wasn't making an analogy between how you find a hash collision and how you win the lottery -- only comparing the odds.
Dropbox uses SHA-256 hashes. I'm assuming this is what they use for this feature, since it's what they use internally for file identification and deduplication. They actually hash 2 MB file chunks, which means that any file more than 2 MB produces multiple hashes (one per chunk, naturally).
The "many chances of winning" you're referring to here is the birthday collision problem. A good, rough approximation is that for an N-bit hash, while the number of different hashes is 2^N, the number you can generate before risking a collision is about 2^(N/2). So, with SHA-256, we run no significant risk of collision until we've generated around 2^128 ~= 10^38 hashes.
The total amount of data stored worldwide is on the order of 1 ZB. That's room enough for about 10^15 2-MB chunks. Of course, some of our files might be smaller than this 2 MB chunk size, enabling us to be more efficient with storage. We might be able to get somewhere around 10^20 different files in there.
That's a strange and untenable use of all of the world's storage, and it still puts us about 18 orders of magnitude short of being able to risk a SHA-256 collision. If you had this giant set of a ton of different files, the probability of a collision existing is about 1 in 10^37.
So, short of a flaw in SHA-256, you can assume that a hash collision will never happen. We know of no such flaws. (If we do, it will almost certainly be the case that the collision only occurs because one of the two files was specifically manipulated to produce the collision.)
On the other hand, the odds of winning the lottery are rarely worse than 1 in 10^9.
One site I've worked on uses the user ID, username, join date/time, and a secret per-site string as the salt for the password. User IDs are sequential and can be sort of guessed from the join date, but I'm under the impression that there's enough entropy in the minutes and seconds of the join date/time, and the secret per-site string keeps the lookup table from applying to more than one site.
The function of salt is to make password cracking efforts more difficult when the attacker has access to the site's password database. So, predictability is not as important, since all the listed information is available to the attacker anyway. (Similarly, the salts are available to the attacker.) That doesn't look like much entropy, though. Really, storing an extra column of random, per-user salts in a database is not particularly hard and has tangible (though not magical) benefits.
The bad guys can already do that by trying to register an account with that username or by trying to send a private message to that username.
Yeah. IMO, usernames should never be relied on for security. Just assume an attacker can determine what usernames are taken and which aren't, and further assume that an attacker with a particular target can figure out the username for that target. (Unless pseudonymity is a key design aspect of your system.)
They're not talking about a fixed value that's different from "+123456". They're talking about using a different, random value for each user. That is more secure. (There's still plenty of security problems, but it's better than every user's password being completely predictable.)
Of course, if you're bothering to store a different random value for each user, there's no reason to include their username in the password. Just store a long random password for each user. (That's still not great security -- never mind that the password is exposed in cleartext and transmitted over HTTP -- because a user can't change a compromised password.)
It looks from the video that the password is simply the username concatenated with a global string, "123456".
That's not salt. That's not what the word means. A salt is data that is not part of the password but is combined with the password when hashed. The client side never sees salt.
So all these discussions of salt are not at all relevant.
This is fundamentally a case of hard-coded credentials, which is more stupid than a non-random salt. (Also, really, transmitting credentials over HTTP?)
Normally I'd agree, but the article summarizes a collection of studies, so is a work by itself. To skip the article, you'd either need to just link a number of studies and skip any useful summary of them, or you'd need to reproduce the summary in the article (which would be plagiarism, or at least wasted effort).
Energy received and energy emitted by the Earth aren't equal. You might have heard of global warming.
True, they're not equal. To a reasonable approximation, they are equal: the heat picked up via global warming is tiny compared to the amount of heat added by the Sun each day (and subsequently lost to space by radiation).
No, but a distribution of radiation does. When, in physics, someone says that radiation is "X Kelvin", it's shorthand for "a distribution of radiation very close to the ideal black-body radiation at X Kelvin". The great bulk of the Sun's and Earth's radiation is black-body radiation.
You can only define entropy for a thermodynamic system (i.e. Earth, or Earth + atmosphere).
Radiation certainly does have entropy. See, for example, Planck's "the Theory of Heat Radiation" or some more modern text.
All oher things being equal, the entropy goes up with the temperature (0 at 0K, higher at 6000K than at 300K)
This is just a misunderstanding of the meaning of 6000K vs. 300K light. Though it's incorrect to just assume zero entropy at 0K.
Entropy more or less describes the disorder of a system.
It's enormously more complicated than that. That's a Brian-Greene-level description.
Encrypting data at rest doesn't get you much. Anyone who gets access to the backend gets access to the cryptographic keys used to read the data at rest.
This is the case whenever the attacker has access to the cryptographic endpoint. The fact is, as long as Google is one of the cryptographic endpoints, if you have access to Google's data, you have access to it regardless of whether you pretend to encrypt it. The only way you can significantly change that is to make yourself (that is, the person sending and the person receiving the e-mail) the cryptographic endpoint, so that Google only ever sees ciphertext.
I actually used the more-recent numbers for "healthcare spending as % GDP". Arguably, healthcare spending per capita (adjusted for purchasing-power parity) may be more useful, but the gap between the US and other nations is a lot smaller there. Both numbers are available.:-)
There is really no way for any code running on top of another layer to verify that lower layer's integrity - it has to rely on what is reported and a malicious BIOS or UEFI layer can simply just lie to it.
Theoretically, yes. Practically, it's often not that easy to "just lie to it". (So, in practice, it becomes an arms race of effort just like everything else.)
For example:
Hell, it's possible for a low-level hypervisor to run another, clean, BIOS/UEFI and simply virtualize every piece of hardware in the box.
That's easy to detect through timing attacks, it turns out. You would also have to be very careful to exactly replicate the behavior of the hardware you're virtualizing, or that's detectable, too.
something outside of the device has to detect the suspicious traffic that such an attack must generate in order to be useful
Now, talk about difficult problems! The easy part would be having trustworthy networking gear. The hard part would be that "detect the suspicious traffic" boils down to "detect a side-channel attack used for exfiltrating data", which is somewhere in between very difficult and impossible.
Roughly, across the US, there seems to be an average conviction rate for police misconduct of 50/month. The average rate of people being killed by police is about 35/month.
So, for every cop convicted of misconduct, there appears to be about 0.7 that get away with murder (assuming, almost certainly incorrectly, that every person killed by police qualifies as "murder" and that all of them "get away with it").
"Yes" and "no" are the only ways you get to vote on a bill. They point out quite clearly what needs to be addressed in the bill in order for it to be acceptable to them. They also actively lobby to suggest new legislation and amend in-process legislation. You don't see that here, because that's not what this story is about, because this bill is up for vote.
Slashdot Mirror
...then there is a real world cost to not optimizing this code.
Turns out there's a real-world cost to optimizing it, too!
There are languages that are neither C nor run on a virtual machine.
As others have indicated, the primary stated use of heartbeat is for DTLS, which is not over TCP.
The payload length is not actually superfluous. The packet has an arbitrary amount of both payload and padding, of which only the payload is echoed to the sender. Roughly: { uint16 payload_len; char payload[]; char padding[]; } The intent of payload_len is to tell you which of the bytes following it are payload rather than padding. Of course, you need to check that it's less than the remaining data in the packet. (Per the spec, at least 16 less -- at least 16 bytes of random padding are required.)
He didn't say they weren't different. He said people think that vinyl is "more genuine" or "more accurate" than digital. Genuine is a weasel word -- it's ill-defined. (Probably the most reasonable definition here is "closest to how the creator of the music intended for you to hear it". But, I digress. It's hard to measure.) Vinyl is certainly less accurate than a good digital representation.
It can be different, though, because it introduces flaws that the digital representation doesn't have. Maybe those flaws make the music "better" in some sense, but not "more accurate".
They're replayable.
You don't. Your field of vision through the back window is tiny compared to the field of vision of the camera.
I thought they were a stupid gimmick until I got a car with one. Now I curse every time I drive a car that doesn't have one, because backing up is a lot harder.
He wasn't making an analogy between how you find a hash collision and how you win the lottery -- only comparing the odds.
Dropbox uses SHA-256 hashes. I'm assuming this is what they use for this feature, since it's what they use internally for file identification and deduplication. They actually hash 2 MB file chunks, which means that any file more than 2 MB produces multiple hashes (one per chunk, naturally).
The "many chances of winning" you're referring to here is the birthday collision problem. A good, rough approximation is that for an N-bit hash, while the number of different hashes is 2^N, the number you can generate before risking a collision is about 2^(N/2). So, with SHA-256, we run no significant risk of collision until we've generated around 2^128 ~= 10^38 hashes.
The total amount of data stored worldwide is on the order of 1 ZB. That's room enough for about 10^15 2-MB chunks. Of course, some of our files might be smaller than this 2 MB chunk size, enabling us to be more efficient with storage. We might be able to get somewhere around 10^20 different files in there.
That's a strange and untenable use of all of the world's storage, and it still puts us about 18 orders of magnitude short of being able to risk a SHA-256 collision. If you had this giant set of a ton of different files, the probability of a collision existing is about 1 in 10^37.
So, short of a flaw in SHA-256, you can assume that a hash collision will never happen. We know of no such flaws. (If we do, it will almost certainly be the case that the collision only occurs because one of the two files was specifically manipulated to produce the collision.)
On the other hand, the odds of winning the lottery are rarely worse than 1 in 10^9.
But computing a hash-value IS going through your files.
In the same sense that receiving them from you, storing them, or transmitting them to others (at your request) is "going through" your files.
Dropbox already uses SHA-256 hashes internally for file identification and deduplication. So it's been hashing all of your data this whole time.
One site I've worked on uses the user ID, username, join date/time, and a secret per-site string as the salt for the password. User IDs are sequential and can be sort of guessed from the join date, but I'm under the impression that there's enough entropy in the minutes and seconds of the join date/time, and the secret per-site string keeps the lookup table from applying to more than one site.
The function of salt is to make password cracking efforts more difficult when the attacker has access to the site's password database. So, predictability is not as important, since all the listed information is available to the attacker anyway. (Similarly, the salts are available to the attacker.) That doesn't look like much entropy, though. Really, storing an extra column of random, per-user salts in a database is not particularly hard and has tangible (though not magical) benefits.
The bad guys can already do that by trying to register an account with that username or by trying to send a private message to that username.
Yeah. IMO, usernames should never be relied on for security. Just assume an attacker can determine what usernames are taken and which aren't, and further assume that an attacker with a particular target can figure out the username for that target. (Unless pseudonymity is a key design aspect of your system.)
They're not talking about a fixed value that's different from "+123456". They're talking about using a different, random value for each user. That is more secure. (There's still plenty of security problems, but it's better than every user's password being completely predictable.)
Of course, if you're bothering to store a different random value for each user, there's no reason to include their username in the password. Just store a long random password for each user. (That's still not great security -- never mind that the password is exposed in cleartext and transmitted over HTTP -- because a user can't change a compromised password.)
It looks from the video that the password is simply the username concatenated with a global string, "123456".
That's not salt. That's not what the word means. A salt is data that is not part of the password but is combined with the password when hashed. The client side never sees salt.
So all these discussions of salt are not at all relevant.
This is fundamentally a case of hard-coded credentials, which is more stupid than a non-random salt. (Also, really, transmitting credentials over HTTP?)
...is it possible that MtGox is just that incompetent?
Absolutely. It's just a question of whether their incompetence happened to be the cause here.
On the contrary; it's a shortage of companies willing to provide on-the-job training and the salaries and rates necessary!
Tomato, tomato.
Normally I'd agree, but the article summarizes a collection of studies, so is a work by itself. To skip the article, you'd either need to just link a number of studies and skip any useful summary of them, or you'd need to reproduce the summary in the article (which would be plagiarism, or at least wasted effort).
Orbital energy. Or, you know, just forward motion.
Rotational energy maintains the night/day cycle.
Energy received and energy emitted by the Earth aren't equal. You might have heard of global warming.
True, they're not equal. To a reasonable approximation, they are equal: the heat picked up via global warming is tiny compared to the amount of heat added by the Sun each day (and subsequently lost to space by radiation).
The energy emitted by the Earth isn't all infrared radiation.( http://en.wikipedia.org/wiki/F... [wikipedia.org] and http://www.eoearth.org/view/ar... [eoearth.org] )
True, though it's mostly infrared and albedo.
Temperature doesn't have color
No, but a distribution of radiation does. When, in physics, someone says that radiation is "X Kelvin", it's shorthand for "a distribution of radiation very close to the ideal black-body radiation at X Kelvin". The great bulk of the Sun's and Earth's radiation is black-body radiation.
You can only define entropy for a thermodynamic system (i.e. Earth, or Earth + atmosphere).
Radiation certainly does have entropy. See, for example, Planck's "the Theory of Heat Radiation" or some more modern text.
All oher things being equal, the entropy goes up with the temperature (0 at 0K, higher at 6000K than at 300K)
This is just a misunderstanding of the meaning of 6000K vs. 300K light. Though it's incorrect to just assume zero entropy at 0K.
Entropy more or less describes the disorder of a system.
It's enormously more complicated than that. That's a Brian-Greene-level description.
You're probably talking about exergy
... Are you an engineer?
Super usable! And it's not like it ignores the hardest problem, with is operating PKI properly.
That's true. The messages really are never encrypted at all. :-)
Encrypting data at rest doesn't get you much. Anyone who gets access to the backend gets access to the cryptographic keys used to read the data at rest.
This is the case whenever the attacker has access to the cryptographic endpoint. The fact is, as long as Google is one of the cryptographic endpoints, if you have access to Google's data, you have access to it regardless of whether you pretend to encrypt it. The only way you can significantly change that is to make yourself (that is, the person sending and the person receiving the e-mail) the cryptographic endpoint, so that Google only ever sees ciphertext.
But that's not very convenient.
I actually used the more-recent numbers for "healthcare spending as % GDP". Arguably, healthcare spending per capita (adjusted for purchasing-power parity) may be more useful, but the gap between the US and other nations is a lot smaller there. Both numbers are available. :-)
There is really no way for any code running on top of another layer to verify that lower layer's integrity - it has to rely on what is reported and a malicious BIOS or UEFI layer can simply just lie to it.
Theoretically, yes. Practically, it's often not that easy to "just lie to it". (So, in practice, it becomes an arms race of effort just like everything else.)
For example:
Hell, it's possible for a low-level hypervisor to run another, clean, BIOS/UEFI and simply virtualize every piece of hardware in the box.
That's easy to detect through timing attacks, it turns out. You would also have to be very careful to exactly replicate the behavior of the hardware you're virtualizing, or that's detectable, too.
something outside of the device has to detect the suspicious traffic that such an attack must generate in order to be useful
Now, talk about difficult problems! The easy part would be having trustworthy networking gear. The hard part would be that "detect the suspicious traffic" boils down to "detect a side-channel attack used for exfiltrating data", which is somewhere in between very difficult and impossible.
In a strange world where 15 is nearly double 11, yes.
Roughly, across the US, there seems to be an average conviction rate for police misconduct of 50/month. The average rate of people being killed by police is about 35/month.
So, for every cop convicted of misconduct, there appears to be about 0.7 that get away with murder (assuming, almost certainly incorrectly, that every person killed by police qualifies as "murder" and that all of them "get away with it").
"Yes" and "no" are the only ways you get to vote on a bill. They point out quite clearly what needs to be addressed in the bill in order for it to be acceptable to them. They also actively lobby to suggest new legislation and amend in-process legislation. You don't see that here, because that's not what this story is about, because this bill is up for vote.
They are part of the process. They're a pretty influential lobbying organization.