Historically, a day was defined as 1 earth rotation.
And that's where you went wrong. Historically, a day was one sunrise to
the next.
That doesn't make sense since humanity have been living on parts of the
Earth with constant night during winter and constant day during summer since
god knows when. "One sunrise to the next" doesn't make sense there. There were probably local units all over the place.
Read this very carefully as you quoted only part of it. "Between
1000 (when al-Biruni used seconds) and 1960 the second was defined as
1/86,400 of a mean solar day". So, that means before the year 1000 the
second did not exist as a defined standard; and may not have existed at all;
still fuzzy on that.
I have a hard time imagining all people on Earth of the 11th century all
agreeing on the definition of time units at all, let alone on the
second. It's probably one of those things where the now standardized time units of hours, minute and second was used more and more, and gradually took over any existing local units and standards.
But why 60ths? Was a minute always that long?
I imagine
it's because it was convenient to divide the minute in the same way as the
hour. There's 60 minutes in an hour thanks to the Babylonians, who used that
as their base (just as we use base-10).
Anyway, since you were to lazy to do it, the difference is this added preamble (sans some layout changes):
NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it.
Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.
No, I think he's straight on. Secure boot stems from a broken threat model: that kernel access is extremely important. I know about userspace security, but the kernel already secures userspace without secure boot and proper privilege separation secures the kernel. Secure boot is a way of securing the system from root, which is futile (look at SELinux, for example).
This is primarily a technology for vendor lock-in. Always has been, always will be.
All of those patents are most likely incredibly trivial and all companies and organizations that sucessfully lobbied them in, did so not for their technological benefits but to make sure their patents were as widely used as possible.
If the ITU were to demand patent-free standards, they would be just as good but without the royalties.
Back in 2008--2009, they were violating the GPL knowingly and I don't think that's changed. Buying stuff from them is a big no-no for me, no matter how good they are.
I also went through 2 WRT54G's in as many years. I find both stories believeable, but of the people I know, no one is actually still using their WRT54G for anything other than one guy is using it for a small wired subnet. The wireless generally loses range on them as they get older for some inexplicable reason.
I'm still using my WRT54GL as my primary wireless router and I haven't noticed it's range decreasing at all. Perhaps it's just me, but I think it's working as flawlessly as when I first got it and installed OpenWRT on it six years ago.
Was that ever true? I thought long=2*int always. Otherwise, what's the point of long?
You are only guaranteed that sizeof(long) >= 32 bits and sizeof(int) >= 16, so it's perfectly valid to have sizeof(long) == sizeof(int). There is no data type guaranteed to be >= 2*sizeof(int) (a long long is >= 64 bits). This is all for crappy legacy reasons. If you don't believe me, wikipedia has a good list.
To be honest, I have seen one or two proof of concepts of this. It's not that difficult to do, either (especially if there's money and tax avoidance in it). They should probably look into this as well as open sourcing the code, as a complement.
A strike is probably whenever the entertainment industry who has paid Verizon to do this, enter your IP in a list and report you. If you think the ISP will do anything except tell you to "stop pirating stuff" (such as cross-checking or verifying their data), I think you're sadly mistaken.
People on Slashdot seem to see oversubscription as some kind of evil - it's really not. It keeps your costs down in the name of accommodating real-world demands rather than peak demands.
I don't think so, people on Slashdot see oversubscription as an excuse to not expand your network as evil. To use your car analogy: It's perfectly fine to build a 4-lane highway instead of a 15-lane highway as the latter would be hopelessly oversized almost all day, except for peak hours. The problem is when you build a 2-lane highway and tell people "You can't take your car to work more than twice a week, or you are using an unreasonable amount of highway space".
Just to preempt all comments about imperial or home-grown measurement systems: All measurement systems in the world are defined from the metric base units, which are in turn defined from a few physical constants and this kilogram prototype. When the kilogram prototype gains mass, this affects the kilogram, pound, liter and fluid ounce equally.
You are right that it's perfectly possible, especially if you've had some practice. However, I'd dare say that doing a rough count of 70x180 is easier in my head than doing a matrix multiplication of [2 4] and [6 2], then doing unit conversions.
You don't tell the accounting troll you're almost done and just developing unit tests and refactoring your code before checkin. You tell them it doesn't work yet (which is true, because you're not done until you've refactored and added the appropriate test cases).
There's unit tests, and then of course the ultimate test: the production environment. If you set up perfect unit tests every single time, then you won't notice the difference between the two. If you're human like the rest of us, then every so often an assumption you hadn't even realized you'd been making will slip through your unit tests and you've got a production bug.
...and if you've left the old code commented out, it's much faster to hotpatch the production servers by flipping some comments around, than doing a full rollback.
/me ducks and covers.
If that is the case, your version control system sucks big time. It's that simple. Seriously, git revert oldhash takes about two seconds. One minute if you have a large merge conflict.
It's ridiculous, if you think about it. I don't have to consult a dictionary every few words I read or write of a sentence, so why should I have to consult a language reference for every few lines of code I am reading or writing?
As programmers, we are telling the computer what to do. Why can't the language resemble more readable (English, or native language) rather than obfuscated math.
Because you need more information in your programming statements than English provides. The languages we use to communicate with other humans contain a lot of information in the context of the language, and we still often misunderstand oneanother. Computers need precise and unambiguous instructions, i.e. not language but math.
What you propose is of course doable as it's just a technical problem. However, if we did it, computers would suddenly have to use ambiguous language context to interpret their instructions and you would have bugs that depended on the context of the situation. Good luck finding those. Imagine the consequences when your car misunderstands its programming when you're on the highway...
And forget functional programming, that is the most obfuscated coding I have ever seen, I can't even read it except in the most trivial of cases.
Functional programming is an entirely different paradigm. You can't compare readability with imperative programming.
Even if you did this, how do you know the software that is freely available and audited is really the software running on the machines? Even if you bring on all cryptographic signatures in the world, one exploit or overlooked design flaw is all that is needed.
Paper, while old and cumbersome, cannot be broken in all places at the same time in the same way. It's incredibly more difficult to rig a paper ballot election.
The next logical step would be to make use of cryptography illegal, but then it reaches the point where the majority of the population is breaking the law routinely. When the law has turned the majority of the population into criminals, it becomes unenforceable and completely toothless.
I don't think they will try to make encryption illegal, they would simply make not disclosing the key to the authorities illegal. That's how it is in the UK right now, for example. Which, of course, also makes both forgetting your key and storing random data illegal...
You said, "golden plates that no-one ever saw". Now, if you knew even a smidgen of Mormon history you would know about the three Witnesses and the eight Witnesses. In fact, their testimony is printed in every Book of Mormon. Each of those eleven men to their dying day never denied seeing the plates.
I found it a bit interesting so I did a quick google on Book of mormon witnesses. The second hit was this at exmormon.org, which is very interesting reading. Much of it was apparently seeing through "secondary vision", "the spiritual eye", etc. Wikipedia also has a quick run-through.
It makes no difference how. none at all. name a security algorithm that's remained secure for ten years. I'll point you to the numeral in sha2,
I won't bite for this straw man because it wasn't what we were discussing. The interested reader is refered to google and wikipedia.
Your original point was that using a password longer than the hash keyspace would not increase security, quoting your post:
yeah, and you get 16 bytes. that's what they do. and as a result, there's no reason to ever give it any more than the 16 bytes of input. since "tnloehurlildoeucidtnoehudibwhmoeudbitnh" hashed produces "tughetucnoturecn" and "ilcroeuoeuitnsh" produces the exact same hash. so what benefit is there to having the longer input? It doesn't increase security at all.
And "resistant" is different than "proof" for a reason.
Spare me the nitpicking. Unless you're a professional mathematician or cryptologer, let's just say your opinion about mathematical proofs in cryptology is invalid and leave it at that.
And I never said that you can find two strings that hash to the same value. I said that two exist, and hence there is no additional hash space created by a longer input string -- because the output is still the same 16 bytes.
Read harder.
Of course, but that is a straw man and wasn't your whole post. The important part is that you added:
so what benefit is there to having the longer input? It doesn't increase security at all.
which implies that a) either a deliberate or random hash collision would easily occur or b) the keyspace is small enough to let it happen at random.
For the first point: If you don't trust their one-way property, I recommend you to retreat into a non-electrified shed in the outback and never use the Internet, as all cryptographic security in the whole world are based on it. Every single last protocol we use are based on one way hashes in some manner.
As to the second, the possibility of two 128 bit numbers, both chosen truly randomly, being the same is 2^128 (i.e. 3.4*10^38 or, in laymans terms, "never gonna happen during the lifetime of the universe, even if we get our best supercomputers cracking on it").
I can put this to scale if you want as there are also thermodynamic proofs to this. An ideal computer using the least amount of energy possible to cycle through a 128 bit counter would require a about 1/100th of all the energy usage on the Earth combined for one year. A 256 bit counter in this ideal computer would require the entire energy output of a substantial number of supernovas to flip through all states. If this is your threat scenario, then go ahead and design for it, but please keep in mind that there are probably more credible threats out there.
However, I won't have the time to reply to you any more. My point was that anyone reading this thread in the future and thinking along your lines would know why they're wrong. I think that has been accomplished, both by me and others. Feel free to read up when you feel you have the time.
Look, "Resistant" in this case means "Such a attack is not possible to execute". It is, by design, impossible to carry out the kind of attack you are proposing against today's secure hash functions (e.g. SHA2). That's the whole point of a secure hash function.
It sounds like you're insinuating that it is trivial to generate hash collisions for a 128 bit secure hash, I don't know where you're getting that. There are 128 bit hash functions susceptible to hash collision attacks (MD5 comes to mind), but you don't attack them by trying the whole 128 bit keyspace. You do it by utilizing weaknesses in the algorithm, reducing the keyspace and making the attack feasible.
Slashdot Mirror
Historically, a day was defined as 1 earth rotation.
And that's where you went wrong. Historically, a day was one sunrise to the next.
That doesn't make sense since humanity have been living on parts of the Earth with constant night during winter and constant day during summer since god knows when. "One sunrise to the next" doesn't make sense there. There were probably local units all over the place.
Read this very carefully as you quoted only part of it. "Between 1000 (when al-Biruni used seconds) and 1960 the second was defined as 1/86,400 of a mean solar day". So, that means before the year 1000 the second did not exist as a defined standard; and may not have existed at all; still fuzzy on that.
I have a hard time imagining all people on Earth of the 11th century all agreeing on the definition of time units at all, let alone on the second. It's probably one of those things where the now standardized time units of hours, minute and second was used more and more, and gradually took over any existing local units and standards.
But why 60ths? Was a minute always that long?
I imagine it's because it was convenient to divide the minute in the same way as the hour. There's 60 minutes in an hour thanks to the Babylonians, who used that as their base (just as we use base-10).
Uhm yes, the license text itself? Just diff COPYING in the kernel tree with the one available at gnu.org. Honestly, it's not that difficult.
Anyway, since you were to lazy to do it, the difference is this added preamble (sans some layout changes):
NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it.
Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.
Linus Torvalds
No, I think he's straight on. Secure boot stems from a broken threat model: that kernel access is extremely important. I know about userspace security, but the kernel already secures userspace without secure boot and proper privilege separation secures the kernel. Secure boot is a way of securing the system from root, which is futile (look at SELinux, for example).
This is primarily a technology for vendor lock-in. Always has been, always will be.
Unless you passed the entire memory image trough the TPM, how are you going to accomplish this without compromising the key to the operating system?
All of those patents are most likely incredibly trivial and all companies and organizations that sucessfully lobbied them in, did so not for their technological benefits but to make sure their patents were as widely used as possible.
If the ITU were to demand patent-free standards, they would be just as good but without the royalties.
Back in 2008--2009, they were violating the GPL knowingly and I don't think that's changed. Buying stuff from them is a big no-no for me, no matter how good they are.
I also went through 2 WRT54G's in as many years. I find both stories believeable, but of the people I know, no one is actually still using their WRT54G for anything other than one guy is using it for a small wired subnet. The wireless generally loses range on them as they get older for some inexplicable reason.
I'm still using my WRT54GL as my primary wireless router and I haven't noticed it's range decreasing at all. Perhaps it's just me, but I think it's working as flawlessly as when I first got it and installed OpenWRT on it six years ago.
Was that ever true? I thought long=2*int always. Otherwise, what's the point of long?
You are only guaranteed that sizeof(long) >= 32 bits and sizeof(int) >= 16, so it's perfectly valid to have sizeof(long) == sizeof(int). There is no data type guaranteed to be >= 2*sizeof(int) (a long long is >= 64 bits). This is all for crappy legacy reasons. If you don't believe me, wikipedia has a good list.
To be honest, I have seen one or two proof of concepts of this. It's not that difficult to do, either (especially if there's money and tax avoidance in it). They should probably look into this as well as open sourcing the code, as a complement.
A strike is probably whenever the entertainment industry who has paid Verizon to do this, enter your IP in a list and report you. If you think the ISP will do anything except tell you to "stop pirating stuff" (such as cross-checking or verifying their data), I think you're sadly mistaken.
People on Slashdot seem to see oversubscription as some kind of evil - it's really not. It keeps your costs down in the name of accommodating real-world demands rather than peak demands.
I don't think so, people on Slashdot see oversubscription as an excuse to not expand your network as evil. To use your car analogy: It's perfectly fine to build a 4-lane highway instead of a 15-lane highway as the latter would be hopelessly oversized almost all day, except for peak hours. The problem is when you build a 2-lane highway and tell people "You can't take your car to work more than twice a week, or you are using an unreasonable amount of highway space".
Just to preempt all comments about imperial or home-grown measurement systems: All measurement systems in the world are defined from the metric base units, which are in turn defined from a few physical constants and this kilogram prototype. When the kilogram prototype gains mass, this affects the kilogram, pound, liter and fluid ounce equally.
You are right that it's perfectly possible, especially if you've had some practice. However, I'd dare say that doing a rough count of 70x180 is easier in my head than doing a matrix multiplication of [2 4] and [6 2], then doing unit conversions.
Sure, 2' 4" x 6' 2" is a pain, but so is 70 cm x 180 cm.
No it's not: (70 * 200) - (70 * 20) cm^2 = 7000 * 2 - 700 * 2 cm^2 = 6300 * 2 cm^2 = 12600 cm^2 = 1.26 m^2
Seriously, doing math by rough count is the stuff we learn in 4th grade.
We don't boil water on a daily basis, but we're expected to use the boiling and freezing points of water for our daily experience?
You don't for example cook food on an every day basis ... ?
You don't tell the accounting troll you're almost done and just developing unit tests and refactoring your code before checkin. You tell them it doesn't work yet (which is true, because you're not done until you've refactored and added the appropriate test cases).
There's unit tests, and then of course the ultimate test: the production environment. If you set up perfect unit tests every single time, then you won't notice the difference between the two. If you're human like the rest of us, then every so often an assumption you hadn't even realized you'd been making will slip through your unit tests and you've got a production bug.
...and if you've left the old code commented out, it's much faster to hotpatch the production servers by flipping some comments around, than doing a full rollback.
/me ducks and covers.
If that is the case, your version control system sucks big time. It's that simple. Seriously, git revert oldhash takes about two seconds. One minute if you have a large merge conflict.
It's ridiculous, if you think about it. I don't have to consult a dictionary every few words I read or write of a sentence, so why should I have to consult a language reference for every few lines of code I am reading or writing?
As programmers, we are telling the computer what to do. Why can't the language resemble more readable (English, or native language) rather than obfuscated math.
Because you need more information in your programming statements than English provides. The languages we use to communicate with other humans contain a lot of information in the context of the language, and we still often misunderstand oneanother. Computers need precise and unambiguous instructions, i.e. not language but math.
What you propose is of course doable as it's just a technical problem. However, if we did it, computers would suddenly have to use ambiguous language context to interpret their instructions and you would have bugs that depended on the context of the situation. Good luck finding those. Imagine the consequences when your car misunderstands its programming when you're on the highway ...
And forget functional programming, that is the most obfuscated coding I have ever seen, I can't even read it except in the most trivial of cases.
Functional programming is an entirely different paradigm. You can't compare readability with imperative programming.
The summary makes absolutely no mention at all of the next-gen rocket, SLS (capable of well over 100mT to orbit), which is being finished up.
I didn't know they started using magnetic engines! ... and with a field strength of only 100 millitesla to orbit, that's perfectly alright, nice!
Even if you did this, how do you know the software that is freely available and audited is really the software running on the machines? Even if you bring on all cryptographic signatures in the world, one exploit or overlooked design flaw is all that is needed.
Paper, while old and cumbersome, cannot be broken in all places at the same time in the same way. It's incredibly more difficult to rig a paper ballot election.
And please, although the Chinese government is very corrupt, it is not more corrupt than US government or US corporations.
Yes, because in the US, bridges regularly collapse because they are made of garbage and corruption measurements support your view. Oh wait, that was China. And they don't.
The next logical step would be to make use of cryptography illegal, but then it reaches the point where the majority of the population is breaking the law routinely. When the law has turned the majority of the population into criminals, it becomes unenforceable and completely toothless.
I don't think they will try to make encryption illegal, they would simply make not disclosing the key to the authorities illegal. That's how it is in the UK right now, for example. Which, of course, also makes both forgetting your key and storing random data illegal ...
You said, "golden plates that no-one ever saw". Now, if you knew even a smidgen of Mormon history you would know about the three Witnesses and the eight Witnesses. In fact, their testimony is printed in every Book of Mormon. Each of those eleven men to their dying day never denied seeing the plates.
I found it a bit interesting so I did a quick google on Book of mormon witnesses. The second hit was this at exmormon.org, which is very interesting reading. Much of it was apparently seeing through "secondary vision", "the spiritual eye", etc. Wikipedia also has a quick run-through.
It makes no difference how. none at all. name a security algorithm that's remained secure for ten years. I'll point you to the numeral in sha2,
I won't bite for this straw man because it wasn't what we were discussing. The interested reader is refered to google and wikipedia.
Your original point was that using a password longer than the hash keyspace would not increase security, quoting your post:
yeah, and you get 16 bytes. that's what they do. and as a result, there's no reason to ever give it any more than the 16 bytes of input. since "tnloehurlildoeucidtnoehudibwhmoeudbitnh" hashed produces "tughetucnoturecn" and "ilcroeuoeuitnsh" produces the exact same hash. so what benefit is there to having the longer input? It doesn't increase security at all.
And "resistant" is different than "proof" for a reason.
Spare me the nitpicking. Unless you're a professional mathematician or cryptologer, let's just say your opinion about mathematical proofs in cryptology is invalid and leave it at that.
And I never said that you can find two strings that hash to the same value. I said that two exist, and hence there is no additional hash space created by a longer input string -- because the output is still the same 16 bytes.
Read harder.
Of course, but that is a straw man and wasn't your whole post. The important part is that you added:
so what benefit is there to having the longer input? It doesn't increase security at all.
which implies that a) either a deliberate or random hash collision would easily occur or b) the keyspace is small enough to let it happen at random.
For the first point: If you don't trust their one-way property, I recommend you to retreat into a non-electrified shed in the outback and never use the Internet, as all cryptographic security in the whole world are based on it. Every single last protocol we use are based on one way hashes in some manner.
As to the second, the possibility of two 128 bit numbers, both chosen truly randomly, being the same is 2^128 (i.e. 3.4*10^38 or, in laymans terms, "never gonna happen during the lifetime of the universe, even if we get our best supercomputers cracking on it").
I can put this to scale if you want as there are also thermodynamic proofs to this. An ideal computer using the least amount of energy possible to cycle through a 128 bit counter would require a about 1/100th of all the energy usage on the Earth combined for one year. A 256 bit counter in this ideal computer would require the entire energy output of a substantial number of supernovas to flip through all states. If this is your threat scenario, then go ahead and design for it, but please keep in mind that there are probably more credible threats out there.
However, I won't have the time to reply to you any more. My point was that anyone reading this thread in the future and thinking along your lines would know why they're wrong. I think that has been accomplished, both by me and others. Feel free to read up when you feel you have the time.
Look, "Resistant" in this case means "Such a attack is not possible to execute". It is, by design, impossible to carry out the kind of attack you are proposing against today's secure hash functions (e.g. SHA2). That's the whole point of a secure hash function.
It sounds like you're insinuating that it is trivial to generate hash collisions for a 128 bit secure hash, I don't know where you're getting that. There are 128 bit hash functions susceptible to hash collision attacks (MD5 comes to mind), but you don't attack them by trying the whole 128 bit keyspace. You do it by utilizing weaknesses in the algorithm, reducing the keyspace and making the attack feasible.