I can't help but wonder if Microsoft is paying them off... especially since the DoJ case has, more or less, ended. If they win, they will go unpunished, and, if not, what difference does it make whether they make one more robber-baron-ish move?
Why are Get/Set methods bad? They are better than public data, anyway, since get/set functions can validate data before it is assigned, preventing things like negative mass.
Better yet, instead of using get/set functions, simply use:
class MyClass { public: void Variable(int x); int Variable();
Still, the 1st key would be as valid as the 2nd. If the 1st was used to dynamically install compoents that no longer recognized the 1st key, it woudln't matter until those components were opirational.
Providing the means to copy the software, or source code of the software, isn't the same as copying it. I could dcc Netscape secure version to a friend in England. Does that make AOL liable?
I suppose we should all be legally obligated to install video cameras about our houses that we can't remove, disable, or reverse-engineer under penalty of death, inform the NSA of all our movments, etc? If you let one freedom slip, the rest do too.
What do you mean, "erase the keys througout the sysetm in one felt[sic] swoop"? rm -rf/? That's always a danger? I'm talking about having this key on multiple systems. Say... bill gate's person supercomputer, his flea's Athlon 650, and, of course, the omnipotent NSA. Creating a different key for each of those systems and hardcoding it into Windows (2k) only serves to reduce the brute-force key difficulty to 1/3 below nominal. That's like creating a version of *n?x that had two roots, "Bob" and "root", both without passwords. If you know one, what difference does it make whether you know the other? If you know both (as M$ does), what difference does it make whether a user hacks out one of them? A user is twice as likely to guess either "Bob" or "root" at the login prompt that he is to guess "root" alone, anyway. Say, for the sake of argument, M$ only does store two keys, one in Seattle, one in Redmond. Say Redmond is hit by an ICBM which happens to be targetted at the Microsoft building. M$ has now lost key #1. If they have key #2, they can continue to produce CryptoAPI modules. However, if they still have another copy of key #1, there is no difference!
Of course, it would be asinine to store only one copy of each key.
So, in short, having two keys allows: 1. No increase in security or reliability 2. An increased likelyhood of the key being cracked by brute force.
No, you fool. This allows anyone (or, prior to the discover of this Hole, the NSA, to replace your security and encryption module with a dummy one that could do anything... even transmitting your password and keys back to the NSA in a transparent form of Key Escrow. It's hole. Oh, and bwt, if pkunzip allowed anyone to unzip any password-protected zip file by using "bob" as the password, THAT would be a hole.
I wonder what the NSA would be if a company began designing a product solely, from the beginning, for US-onyl distribution with Five megabyte (Yes, byte) keys... Has the NSA done anything for purely domestic software producters?
It doesn't matter. When one key is equally as effective as annother, for all intents and purposes, it's the same key! It doesn't matter if grabs one key or the other... they are equivalent. Plus, having two keys HALVES the time needed to crack it by brute force.
Perhaps this was implimented by such an agent without the knowledge of his or her superior.
Yes another reason why OSS is better.... peer review. This could never happen without an extroadinary amount of effort on the part of distributors of tained binaries.
The "we had to create a backup" approach works with a physical, tangible object, but with something as easily copies as a set of bytes, there is no excuse to create a second key. The first key could have been copied as many times as the first and second keys combined.
P.S. It's draconian for the NSA to limit what you could insert into an existing cryptogroaphy framework... even if that module is developed outside of the US! Pathetic.
P.S.S. I would have named such a key "Checkkey", "BackupKey", or something similar. NSAKey is simply too suggestive to even risk putting into a piece of code.
It is true that it would be compressed twice, but no quality would be lost! The quality was already lost on the MP3 side. Lossy compression works by taking sequences of numbers, e.g. 2-3-2-2-6-7-8, and compressing them into similar sequences with fewer numbers (by spotting the smaller differences and eliminating them), e.g. 2-2-2-2-6-6-8. The threshhold is the "quality" setting you see in JPEG problems. One you have a similar string of numbers (2-2-2-2-6-6-8), normal RLE algorithms and other compessional methods are highly effective. Since the SDMI program would have the sequence into 2-2-2-2-6-6-8, when a MP3 programmer recompressed it, it wouldn't spot any new thresholds and compress as-is, assuming that the MP3 quality is >= the SDMI quality.
Slashdot Mirror
An AMD k6-2/350 is *not* inferior to a P/100 or a PII/300
This has already been done. See GPG.
I can't help but wonder if Microsoft is paying them off... especially since the DoJ case has, more or less, ended. If they win, they will go unpunished, and, if not, what difference does it make whether they make one more robber-baron-ish move?
Sorry, I really should have read that article. I won't do it again.
Why are Get/Set methods bad? They are better than public data, anyway, since get/set functions can validate data before it is assigned, preventing things like negative mass.
Better yet, instead of using get/set functions,
simply use:
class MyClass
{
public:
void Variable(int x);
int Variable();
private:
int x;
};
Those weren't *mandatory* in C++. If you don't like a feature of the language, just don't use it.
Still, the 1st key would be as valid as the 2nd. If the 1st was used to dynamically install compoents that no longer recognized the 1st key, it woudln't matter until those components were opirational.
Providing the means to copy the software, or source code of the software, isn't the same as copying it. I could dcc Netscape secure version to a friend in England. Does that make AOL liable?
512-bit RSA was cracked, and you claim 128-bit encryption is secure?
I suppose we should all be legally obligated to install video cameras about our houses that we can't remove, disable, or reverse-engineer under penalty of death, inform the NSA of all our movments, etc? If you let one freedom slip, the rest do too.
Err, subpoena
Because this is proof - or as close we'll get to it without a suppeona:)
What do you mean, "erase the keys througout the sysetm in one felt[sic] swoop"? rm -rf /? That's always a danger? I'm talking about having this key on multiple systems. Say... bill gate's person supercomputer, his flea's Athlon 650, and, of course, the omnipotent NSA. Creating a different key for each of those systems and hardcoding it into Windows (2k) only serves to reduce the brute-force key difficulty to 1/3 below nominal. That's like creating a version of *n?x that had two roots, "Bob" and "root", both without passwords. If you know one, what difference does it make whether you know the other? If you know both (as M$ does), what difference does it make whether a user hacks out one of them? A user is twice as likely to guess either "Bob" or "root" at the login prompt that he is to guess "root" alone, anyway. Say, for the sake of argument, M$ only does store two keys, one in Seattle, one in Redmond. Say Redmond is hit by an ICBM which happens to be targetted at the Microsoft building. M$ has now lost key #1. If they have key #2, they can continue to produce CryptoAPI modules. However, if they still have another copy of key #1, there is no difference!
Of course, it would be asinine to store only one copy of each key.
So, in short, having two keys allows:
1. No increase in security or reliability
2. An increased likelyhood of the key being cracked by brute force.
-----
err, "/"
Oops, forgot a "\" there.
No, you fool. This allows anyone (or, prior to the discover of this Hole, the NSA, to replace your security and encryption module with a dummy one that could do anything... even transmitting your password and keys back to the NSA in a transparent form of Key Escrow. It's hole. Oh, and bwt, if pkunzip allowed anyone to unzip any password-protected zip file by using "bob" as the password, THAT would be a hole.
I wonder what the NSA would be if a company began designing a product solely, from the beginning, for US-onyl distribution with Five megabyte (Yes, byte) keys... Has the NSA done anything for purely domestic software producters?
It doesn't matter. When one key is equally as effective as annother, for all intents and purposes, it's the same key! It doesn't matter if grabs one key or the other... they are equivalent. Plus, having two keys HALVES the time needed to crack it by brute force.
Why doesn't M$ simply compile a custom version with the NSAKEY for the NSA, then? Why include the NSAKEY is *every* copy of Windows?
Perhaps this was implimented by such an agent without the knowledge of his or her superior.
Yes another reason why OSS is better.... peer review. This could never happen without an extroadinary amount of effort on the part of distributors of tained binaries.
Yes. M$'s explanation is BS.
The "we had to create a backup" approach works with a physical, tangible object, but with something as easily copies as a set of bytes, there is no excuse to create a second key. The first key could have been copied as many times as the first and second keys combined.
P.S. It's draconian for the NSA to limit what you could insert into an existing cryptogroaphy framework... even if that module is developed outside of the US! Pathetic.
P.S.S. I would have named such a key "Checkkey", "BackupKey", or something similar. NSAKey is simply too suggestive to even risk putting into a piece of code.
It is true that it would be compressed twice, but no quality would be lost! The quality was already lost on the MP3 side. Lossy compression works by taking sequences of numbers, e.g. 2-3-2-2-6-7-8,
and compressing them into similar sequences with fewer numbers (by spotting the smaller differences and eliminating them), e.g. 2-2-2-2-6-6-8. The threshhold is the "quality" setting you see in JPEG problems. One you have a similar string of numbers (2-2-2-2-6-6-8), normal RLE algorithms and other compessional methods are highly effective. Since the SDMI program would have the sequence into 2-2-2-2-6-6-8, when a MP3 programmer recompressed it, it wouldn't spot any new thresholds and compress as-is, assuming that the MP3 quality is >= the SDMI quality.
Templates are instantiated once, not once for each use, like macros are.
Why should be trust someone who uses "your" instead of "you're"? That makes everything else you write look less reliable and professional.