And I disagree that the "commercial schemes" aren't trustworthy. I have a high degree of confidence in the openssl library, for example (horrible ugliness of the code notwithstanding). I think PGP / GnuPG are also quite excellent. Stick with widely-used, widely-reviewed open source tools, with current-generation ciphers, adequate key sizes and find good ways to protect your keys.
"Trust me," said the fox to the hen, "You can keep your eggs in my basket and I'll make sure the other foxes don't eat them."
Google is saying exactly the opposite. Google is saying you should find someone you do find trustworthy, and route your traffic through their machine, not suggesting that you trust Google.
No, if Google actually wanted that, they'd make their search engine work with Tor instead of saying "I'm sorry, but we're recieving a high volume of suspicious requests from your computer..."
Did you miss the articles about the NSA's penetration of Tor? Why would you want to use their service? Google's solution is much better: route your traffic through the machines of people you know personally, or at least friends of friends, etc.
Note that I'm not saying Google's failure to work through Tor is because they think Tor is a bad idea. It's much simpler: Tor outlet nodes are indistinguishable from clickbots. uProxy nodes that have too many users will have the same issue, but the idea is that uProxy makes the barrier to entry low enough that the traffic will be more distributed.
(Disclaimer: I work for Google, but not on search, uProxy, or anything else discussed here. I do think uProxy is a cool and clever hack, though, and I applaud Google for supporting it.)
But expecting to be able to make a significant contribution to improving security with just a little math is misguided.
That's a huge jump, and a red flag for a shitty argument. As you wrote it, yes it is misguided. You don't have to make a significant contribution, just understand what's already out there. And it's way more than "a little math".
For that matter, will studying the mathematics of RSA make it clear why a chosen ciphertext attack renders RSA with PKCS#1 v1.5 padding vulnerable, and how using Optimal Asymmetric Encryption Padding instead addresses the issue?
Yes. That was simple, wasn't it?
Actually, no. Simply understanding the mathematics will not make it clear. Understanding the math, then having it pointed out, or reading Bleichenbacher's paper, will make it clear. But merely learning the math will not... else it wouldn't have taken decades for someone to discover that problem.
The MD5 collision was an algorithm based on math.
No, it wasn't/isn't. MD5, like all modern hash functions, are based on repeated mixing. It can be modeled mathematically, but it's not "based" on math in any meaningful sense.
But the basic statistical analyses which show whether something may be vulnerable, is all math.
Yes, statistics is math. Do the stats for me and tell me if SHA-256 is vulnerable, would you?
The math for AES can be found on the wikipedia.
The algorithm can. Block ciphers aren't really based in any meaningful sense on mathematics either. Mathematical tools are used to model them and look for weaknesses... but there's also a healthy dose of good "intuition" that goes into cipher design.
The current choices for Dual ECC were proven suspect by math.
Partly. The concern derives as much from observation of process as from the math.
The advice is not laughable in context- trust no one. And, it's not impossible to learn this stuff, you can either choose to or choose not to.
I've spent a big part of the last 20+ years learning it (among other things; I'm not a researcher and crypto is only part of my job), and I work with a bunch of other people who've devoted their whole lives to it. And you know what? If you ask them if anything is good, they'll immediately start looking for research papers to find out... because there is no realistic option but to trust the work that others have done, and which has been peer reviewed and vetted.
Don't trust the researchers - verify it yourself. That's not original research, it's just common sense (for the paranoid).
That's not what the researchers do. But you're smarter and more paranoid than they are. Gotcha.
I stand corrected. That's what I get for jumping in in the middle. However, I'll still assert that all of the actual security in your frankenscheme is coming from the commercial encryption.
If party C can't figure out how a message was encoded, they can't exploit gaps in that encoding to extract your message.
Nonsense.
Many amateur ciphers are easily crackable without any knowledge of the exact technique used. And amateur cipher designers can't tell the difference between those that are and those that aren't.
If you want to use your own cipher, fine. Use it. Then encrypt the result with AES.
Applying the mantra of open source to the underlying mathematics: Learn the mathematics of cryptography yourself to find the bugs within the mathematics. Don't place your trust in any person other than yourself. Especially don't worship some brand-name as a god who, as diviner-intercessor, is your sole information-provider on the subject.
Care to point me to the "mathematics" of AES? How about SHA-2? For that matter, will studying the mathematics of RSA make it clear why a chosen ciphertext attack renders RSA with PKCS#1 v1.5 padding vulnerable, and how using Optimal Asymmetric Encryption Padding instead addresses the issue?
Seriously, the above is laughable advice. Oh, by all means learn crypto if you're interested, it's a fascinating subject -- one which you can easily devote your entire lifetime to, though you'll have to pick a sub-specialty if you really want deep understanding of the sort that will let you meaningfully evaluate the security of some real-world elements.
The reality is that you must rely on someone else. Even serious academic cryptography researchers make no claims to be able to fully understand anything outside their narrow area of focus, and they're also quick to point out that even when the theory is great, implementations may contain subtle defects which are extremely hard to find. The "open source" mantra is indeed exactly what we need, but your average developer -- bright though he or she may be -- simply doesn't have the background needed to contribute very effectively, and it doesn't make sense for everyone to invest the time needed to acquire that much background.
Instead, what we need is what we have: An open security research community. It could be bigger, of course, and I'd encourage anyone who has an interest in this stuff to get involved. And I'd also encourage everyone else to become more informed. But expecting to be able to make a significant contribution to improving security with just a little math is misguided.
So, when Ubuntu Touch is having a seizure, it kindly induces one in the user as well. How clever! The user will never notice that their tablet has become unresponsive when they're spasming uncontrollably on the floor, trying not to bite through their tongue. As long as the user's seizure ends before the tablet's, the user will remain blissfully unaware that there was any problem!
Do you really think Brazil or Mexico is running operations hacking President Obama's email account? Do you think Germany is?
Absolutely. Whether or not they're succeeding is a separate question, and perhaps they're not confident enough of success to focus their limited resources on Obama's e-mail, but I have absolutely no doubt that if they thought the likely reward was worth the cost, they'd be trying.
You heat the fuel in an oxygen-poor environment (the heat comes from burning a part of the fuel itself using what little oxygen is present) which releases volatile compounds and produces carbon monoxide. This syngas is then fed into an internal combustion engine where it's burned to completion to produce power.
So, not carbon-neutral, just carbon-reduced. And definitely not carbon-negative. Carbon-reduced can still be useful, of course.
Standard Oil developed WITHOUT government involvement, and it was the Supreme Court ruling that broke it up.
Standard Oil is a very poor example for your case. During it's run, Standard Oil dramatically lowered retail consumer prices (from 30 cents per gallon to 6 cents), improved quality control by driving out of business many producers of substandard kerosene (which was prone to exploding) and was generally beneficial to the consumer, not an anti-competitive extractor of monopoly rents. It also wasn't really a monopoly, having many successful competitors at the time it was broken up.
The true legacy of the antitrust action against Standard Oil was to teach the oil industry the important of lobbyists. Where the industry in general and Standard Oil in particular had never much worried about government, and never really bothered to establish a presence in DC, within six years after the breakup all of the companies that previously composed Standard Oil, and most of their competitors, had full-time lobbyists in Washington working hard to tilt public policy in their favor.
If you give government sufficient power to harm corporations, corporations will fight back by suborning that power and using it to their advantage.
One other point about the Standard Oil outcome: Standard Oil was almost certainly about to go down anyway. The 18 companies in the Standard Oil trust were deeply invested in kerosene, and did not see any value in gasoline, since it was too volatile and hard to manage. At that time, refining technology was focused primarily on a single output, and the Standard Oil infrastructure wasn't capable of producing gasoline, and would have required significant re-tooling to produce. Rockefeller was uninterested in making any investments like that; even as practical automobiles started being produced in large numbers he considered it a flash in the pan. I have no doubt that Standard Oil would eventually have gotten the ship turned around, but by then they'd have lost whatever semblance of market domination they had.
In short, Standard Oil was about to be innovated right out of the market just when it was broken up.
So, the antitrust action against Standard Oil did very little at all, other than to make corporations aware that they must obtain and exercise control over the government.
Sure, comment things that aren't expressible as code. Such as *why* you're doing something. If you keep your functions sensible sizes, then a simple 1-line comment should be sufficient to explain what the whole thing does, and you don't need to go into *how* it does that - the how should be precisely described by the code itself, as you say.
Ideally, you should be able to completely capture the "why" in the names. I agree that's not always possible, and there are often usage notes that need to be added at the level of a function, method or class. Information about thread-safety, description of the contract, etc. (though much of the latter can also be expressed as pre- and post-conditions). And I think there's a lot of value in class and method/function-level comments which can be automatically extracted to generate API documentation, like Javadoc or Doxygen -- but they also create a maintenance burden, so balance is important.
I'd be surprised too, as the Tea Baggers tend to think that climate change is some kind of made up science (Yale Climate Change Study).
However, that result is consistent with the other study which showed that people who hold a strong position only get more certain of that position as the get more information, regardless of what the information says. So you'd expect more scientifically-informed climate deniers to deny more strongly than less-informed client deniers.
It's also worth pointing out that the Tea Party movement as such has no position on climate change at all.
All this really says is that your company is in Silicon Valley where you need 100k a year to rent a decent apartment.
Most of these companies have offices that aren't in Silicon Valley, or other really expensive areas.
Huh? At least 7 out of 10 of the companies listed have their main engineering offices in Silicon Valley. Twitter's in San Francisco, where the rents are also ridiculous.
Main, yes, all, no. FWIW, I work for Google, in Colorado.
Or, as happens in the real world, they focus on training all of the new recruits your bombs motivated, so they can send 10X as many terrorists out to fight you.
Why? Because they're almost inevitably wrong. Many comments are wrong when they're written, and all comments eventually become wrong.
I write comments as I'm writing code, whenever something isn't clear. Then I go back after it all works (and passes a unit test suite with near 100% coverage), and refactor and rename until the comments are no longer required, until the code is clear and readable enough to stand on its own.
Some key techniques:
Temporary variables: Just because a calculation can be completed compactly in-line doesn't mean it should. Results, especially interim results, can often usefully be extracted and assigned to well-named variables. The well-named variables are the key... they give you an opportunity to explain what this value is/means and to imply the rationale for computing it.
Helper functions: Writing short functions is a good idea in and of itself, but I frequently find little blocks of code with a comment at the top explaining what the block does. Extract the block into a separate function, and give it good, descriptive name. If the block needs a bunch of data, you might need to rethink how it works a bit or use the next technique.
Helper data structures: If you have big lists of parameters, or sometimes even if you don't, collect them into data structures and... bet you can predict this at this point... give them good, descriptive names. In OO code, I sometimes even collect groups of member variables into internal, helper classes, purely so I can name the helper classes and maybe add some methods that use those variables, so that I can name those. In C++ there's no cost to this as long as everything is by value (well, perhaps a few bytes for alignment, but it's rare that I'm paying attention to alignment). Even in Java and other reference/pointer-heavy languages the cost is small, and well worth it for the improved readability.
General refactoring: If you can't get something that's readable without comments even with all of the above, it's a really good sign that your abstractions are wrong and need to be rethought -- so that you can define new wones and give them good, descriptive names.
Yes, the secret to readable, comment-free code is good naming. Of course, there's still the risk that the names may become wrong over time just as the comments do, but I find that to be less of a problem, as long as good refactoring tools are available. Programmers -- at least the ones that care about names -- are pretty sensitive to inaccurate naming, in a way that they're not sensitive to comments, which often go unread.
The most annoying and maddening thing I've ever had to do was follow a changing spec list from a manager who thought it was some iterative process, instead of giving me an actual complete task description to work on.
The solution to that is to accept that the spec is a snapshot in time of an iterative and ultimately unknown and unknowable document. In fact, that is the essence of the Agile methodology. Agile isn't appropriate for everything, but your case was exactly what it's for.
In all seriousness, this is why I have become death on comments. I hate comments in code. If your code needs comments, fix the code until it doesn't need them. Because the code is never wrong, and the comments inevitably become wrong, if they're even ever right.
With a sufficiently smart compiler/reference management engine, you can even go to using copy-on-write-to-shared, so that operations on an unshared value that is about to be replaced can be done inline. That gets the number of copies down even further, to nearly the level that you have with classic shared-writable-state programming, except without any of that mysterious changing-behind-your-back behaviour.
The best way to get the smart compiler/reference management engine, of course, is to use a functional programming language rather than try to emulate functional style in an imperative language.
Slashdot Mirror
Negligible protection, assuming anyone actually cares.
And I disagree that the "commercial schemes" aren't trustworthy. I have a high degree of confidence in the openssl library, for example (horrible ugliness of the code notwithstanding). I think PGP / GnuPG are also quite excellent. Stick with widely-used, widely-reviewed open source tools, with current-generation ciphers, adequate key sizes and find good ways to protect your keys.
"Trust me," said the fox to the hen, "You can keep your eggs in my basket and I'll make sure the other foxes don't eat them."
Google is saying exactly the opposite. Google is saying you should find someone you do find trustworthy, and route your traffic through their machine, not suggesting that you trust Google.
No, if Google actually wanted that, they'd make their search engine work with Tor instead of saying "I'm sorry, but we're recieving a high volume of suspicious requests from your computer..."
Did you miss the articles about the NSA's penetration of Tor? Why would you want to use their service? Google's solution is much better: route your traffic through the machines of people you know personally, or at least friends of friends, etc.
Note that I'm not saying Google's failure to work through Tor is because they think Tor is a bad idea. It's much simpler: Tor outlet nodes are indistinguishable from clickbots. uProxy nodes that have too many users will have the same issue, but the idea is that uProxy makes the barrier to entry low enough that the traffic will be more distributed.
(Disclaimer: I work for Google, but not on search, uProxy, or anything else discussed here. I do think uProxy is a cool and clever hack, though, and I applaud Google for supporting it.)
That's a huge jump, and a red flag for a shitty argument. As you wrote it, yes it is misguided. You don't have to make a significant contribution, just understand what's already out there. And it's way more than "a little math".
Yes. That was simple, wasn't it?
Actually, no. Simply understanding the mathematics will not make it clear. Understanding the math, then having it pointed out, or reading Bleichenbacher's paper, will make it clear. But merely learning the math will not... else it wouldn't have taken decades for someone to discover that problem.
The MD5 collision was an algorithm based on math.
No, it wasn't/isn't. MD5, like all modern hash functions, are based on repeated mixing. It can be modeled mathematically, but it's not "based" on math in any meaningful sense.
But the basic statistical analyses which show whether something may be vulnerable, is all math.
Yes, statistics is math. Do the stats for me and tell me if SHA-256 is vulnerable, would you?
The math for AES can be found on the wikipedia.
The algorithm can. Block ciphers aren't really based in any meaningful sense on mathematics either. Mathematical tools are used to model them and look for weaknesses... but there's also a healthy dose of good "intuition" that goes into cipher design.
The current choices for Dual ECC were proven suspect by math.
Partly. The concern derives as much from observation of process as from the math.
The advice is not laughable in context- trust no one. And, it's not impossible to learn this stuff, you can either choose to or choose not to.
I've spent a big part of the last 20+ years learning it (among other things; I'm not a researcher and crypto is only part of my job), and I work with a bunch of other people who've devoted their whole lives to it. And you know what? If you ask them if anything is good, they'll immediately start looking for research papers to find out... because there is no realistic option but to trust the work that others have done, and which has been peer reviewed and vetted.
Don't trust the researchers - verify it yourself. That's not original research, it's just common sense (for the paranoid).
That's not what the researchers do. But you're smarter and more paranoid than they are. Gotcha.
I stand corrected. That's what I get for jumping in in the middle. However, I'll still assert that all of the actual security in your frankenscheme is coming from the commercial encryption.
If party C can't figure out how a message was encoded, they can't exploit gaps in that encoding to extract your message.
Nonsense.
Many amateur ciphers are easily crackable without any knowledge of the exact technique used. And amateur cipher designers can't tell the difference between those that are and those that aren't.
If you want to use your own cipher, fine. Use it. Then encrypt the result with AES.
Applying the mantra of open source to the underlying mathematics: Learn the mathematics of cryptography yourself to find the bugs within the mathematics. Don't place your trust in any person other than yourself. Especially don't worship some brand-name as a god who, as diviner-intercessor, is your sole information-provider on the subject.
Care to point me to the "mathematics" of AES? How about SHA-2? For that matter, will studying the mathematics of RSA make it clear why a chosen ciphertext attack renders RSA with PKCS#1 v1.5 padding vulnerable, and how using Optimal Asymmetric Encryption Padding instead addresses the issue?
Seriously, the above is laughable advice. Oh, by all means learn crypto if you're interested, it's a fascinating subject -- one which you can easily devote your entire lifetime to, though you'll have to pick a sub-specialty if you really want deep understanding of the sort that will let you meaningfully evaluate the security of some real-world elements.
The reality is that you must rely on someone else. Even serious academic cryptography researchers make no claims to be able to fully understand anything outside their narrow area of focus, and they're also quick to point out that even when the theory is great, implementations may contain subtle defects which are extremely hard to find. The "open source" mantra is indeed exactly what we need, but your average developer -- bright though he or she may be -- simply doesn't have the background needed to contribute very effectively, and it doesn't make sense for everyone to invest the time needed to acquire that much background.
Instead, what we need is what we have: An open security research community. It could be bigger, of course, and I'd encourage anyone who has an interest in this stuff to get involved. And I'd also encourage everyone else to become more informed. But expecting to be able to make a significant contribution to improving security with just a little math is misguided.
So, when Ubuntu Touch is having a seizure, it kindly induces one in the user as well. How clever! The user will never notice that their tablet has become unresponsive when they're spasming uncontrollably on the floor, trying not to bite through their tongue. As long as the user's seizure ends before the tablet's, the user will remain blissfully unaware that there was any problem!
I can't comment about '93, but it ran great on my Toshiba in '94.
Do you really think Brazil or Mexico is running operations hacking President Obama's email account? Do you think Germany is?
Absolutely. Whether or not they're succeeding is a separate question, and perhaps they're not confident enough of success to focus their limited resources on Obama's e-mail, but I have absolutely no doubt that if they thought the likely reward was worth the cost, they'd be trying.
You forgot the carbon released by the burning of the methane gas, and the released carbon monoxide.
You heat the fuel in an oxygen-poor environment (the heat comes from burning a part of the fuel itself using what little oxygen is present) which releases volatile compounds and produces carbon monoxide. This syngas is then fed into an internal combustion engine where it's burned to completion to produce power.
So, not carbon-neutral, just carbon-reduced. And definitely not carbon-negative. Carbon-reduced can still be useful, of course.
Standard Oil developed WITHOUT government involvement, and it was the Supreme Court ruling that broke it up.
Standard Oil is a very poor example for your case. During it's run, Standard Oil dramatically lowered retail consumer prices (from 30 cents per gallon to 6 cents), improved quality control by driving out of business many producers of substandard kerosene (which was prone to exploding) and was generally beneficial to the consumer, not an anti-competitive extractor of monopoly rents. It also wasn't really a monopoly, having many successful competitors at the time it was broken up.
The true legacy of the antitrust action against Standard Oil was to teach the oil industry the important of lobbyists. Where the industry in general and Standard Oil in particular had never much worried about government, and never really bothered to establish a presence in DC, within six years after the breakup all of the companies that previously composed Standard Oil, and most of their competitors, had full-time lobbyists in Washington working hard to tilt public policy in their favor.
If you give government sufficient power to harm corporations, corporations will fight back by suborning that power and using it to their advantage.
One other point about the Standard Oil outcome: Standard Oil was almost certainly about to go down anyway. The 18 companies in the Standard Oil trust were deeply invested in kerosene, and did not see any value in gasoline, since it was too volatile and hard to manage. At that time, refining technology was focused primarily on a single output, and the Standard Oil infrastructure wasn't capable of producing gasoline, and would have required significant re-tooling to produce. Rockefeller was uninterested in making any investments like that; even as practical automobiles started being produced in large numbers he considered it a flash in the pan. I have no doubt that Standard Oil would eventually have gotten the ship turned around, but by then they'd have lost whatever semblance of market domination they had.
In short, Standard Oil was about to be innovated right out of the market just when it was broken up.
So, the antitrust action against Standard Oil did very little at all, other than to make corporations aware that they must obtain and exercise control over the government.
Sure, comment things that aren't expressible as code. Such as *why* you're doing something. If you keep your functions sensible sizes, then a simple 1-line comment should be sufficient to explain what the whole thing does, and you don't need to go into *how* it does that - the how should be precisely described by the code itself, as you say.
Ideally, you should be able to completely capture the "why" in the names. I agree that's not always possible, and there are often usage notes that need to be added at the level of a function, method or class. Information about thread-safety, description of the contract, etc. (though much of the latter can also be expressed as pre- and post-conditions). And I think there's a lot of value in class and method/function-level comments which can be automatically extracted to generate API documentation, like Javadoc or Doxygen -- but they also create a maintenance burden, so balance is important.
I'd be surprised too, as the Tea Baggers tend to think that climate change is some kind of made up science (Yale Climate Change Study).
However, that result is consistent with the other study which showed that people who hold a strong position only get more certain of that position as the get more information, regardless of what the information says. So you'd expect more scientifically-informed climate deniers to deny more strongly than less-informed client deniers.
It's also worth pointing out that the Tea Party movement as such has no position on climate change at all.
All this really says is that your company is in Silicon Valley where you need 100k a year to rent a decent apartment.
Most of these companies have offices that aren't in Silicon Valley, or other really expensive areas.
Huh? At least 7 out of 10 of the companies listed have their main engineering offices in Silicon Valley. Twitter's in San Francisco, where the rents are also ridiculous.
Main, yes, all, no. FWIW, I work for Google, in Colorado.
All this really says is that your company is in Silicon Valley where you need 100k a year to rent a decent apartment.
Most of these companies have offices that aren't in Silicon Valley, or other really expensive areas.
Or, as happens in the real world, they focus on training all of the new recruits your bombs motivated, so they can send 10X as many terrorists out to fight you.
Comment their code
I hate comments. Comments are evil.
Why? Because they're almost inevitably wrong. Many comments are wrong when they're written, and all comments eventually become wrong.
I write comments as I'm writing code, whenever something isn't clear. Then I go back after it all works (and passes a unit test suite with near 100% coverage), and refactor and rename until the comments are no longer required, until the code is clear and readable enough to stand on its own.
Some key techniques:
Yes, the secret to readable, comment-free code is good naming. Of course, there's still the risk that the names may become wrong over time just as the comments do, but I find that to be less of a problem, as long as good refactoring tools are available. Programmers -- at least the ones that care about names -- are pretty sensitive to inaccurate naming, in a way that they're not sensitive to comments, which often go unread.
Depends on what the changes are. Simple refactoring that doesn't change how the code works but makes it clean and readable is well worth doing.
The most annoying and maddening thing I've ever had to do was follow a changing spec list from a manager who thought it was some iterative process, instead of giving me an actual complete task description to work on.
The solution to that is to accept that the spec is a snapshot in time of an iterative and ultimately unknown and unknowable document. In fact, that is the essence of the Agile methodology. Agile isn't appropriate for everything, but your case was exactly what it's for.
In all seriousness, this is why I have become death on comments. I hate comments in code. If your code needs comments, fix the code until it doesn't need them. Because the code is never wrong, and the comments inevitably become wrong, if they're even ever right.
Apparently where I work, it's documentation. It's so hard, we don't have any.
Where I work, we document everything, in exacting detail. We call this documentation "code".
So you mean like unix pipe. Where you have those wonderful transformations like sed, grep, cut, sort, etc ? Youngsters.
Yes, but with strongly-typed (rather than stringly-typed) data.
With a sufficiently smart compiler/reference management engine, you can even go to using copy-on-write-to-shared, so that operations on an unshared value that is about to be replaced can be done inline. That gets the number of copies down even further, to nearly the level that you have with classic shared-writable-state programming, except without any of that mysterious changing-behind-your-back behaviour.
The best way to get the smart compiler/reference management engine, of course, is to use a functional programming language rather than try to emulate functional style in an imperative language.