One reason music doesn't seem as dated may just be because music hasn't changed as much as graphics have. While music reproduction and quality are orders of magnitude better than they once were, it seems to me that the difference is less drastic than the advances in graphics (or, seen another way, the nature of older graphics is more primitive than the nature of older music).
It seems to me that Perforce's requiring you to offer public access implies that you're essentially in compliance with the GPL re: source release at all times (the only thing I can think of that might be wrong is that you may do a binary release which doesn't specify exactly where the source code can be retrieved, but you're 99% in compliance since it's always available to anyone).
This seems to obviate your 3rd problem. No matter who releases your code, you'll always be in compliance, because your code is always available.
The problem you are describing is the problem of how to recognize plaintext; when we stumble across the correct decryption key, how can we recognize it?
The first part of the answer is that, for security analysis purposes, we generally assume that the attacker knows what system we're using, starting with what the encryption algorithm is, but including the type & format of the messages. If the attacker knows you're sending a rot128 jpeg image, she can just reverse the process to recover the message (or test a key for correctness).
If you believe that an attacker will not know these details of the system, you will add to security, but watch out: the secret of the system can be pretty easily divulged, and even if the attacker doesn't know the secret of the system, it's pretty hard to estimate how hard it will be to guess it. (For example, every rot-128'd JPEG file will begin with the bytes 0x7F 0x68; sooner or later, someone is going to notice and figure it out.)
Glad to see all the comments on the ECC challenge, and congratulations to the ECDL project team.
To be clear, what has been broken is a single key on an elliptic curve which has a 108 bit order. The smallest key size which Certicom commercially recommends is a 160 bit key, which is on the order of 2^26 times as hard to break (a factor of approximately 67 million).
The papers available at www.cryptosavvy.com are a good, independent, and recent reference for key size comparisons.
Actually, Bayer lost the trademark on Aspirin after World War I as a part of war reperations to France, England, Russia and the US; it's still a trademark in other countries, such as Canada, where generic brands of acetylsalicylic acid are sold as ASA. Useless fact: another trademark Bayer lost at the same time was Heroin, which was invented by the same chemist who perfected ASA and marketed by Bayer as a cough suppressant. See this ad.
Actually, most signature schemes aren't just encryption in reverse. It's true that this is a rough analogue to how RSA signatures work, but DSA doesn't work this way at all, and since it's patent free, that's what would be used in such a scheme for Linux, most likely.
Also, Linus *is* involved since this policy prohibits the introduction of strong encryption routines into the kernel itself. That means we all lose:
- strong filesystem encryption (at the kernel level)
- strong filesystem authentication (e.g., having a file system which checks the checksums of files before allowing 'execute' access)
Actually, strong authentication is fully exportable, so there wouldn't be anything to keep strong execute authentication from being rolled into the kernel.
But IIRC, there is no provision in US code concerning export that prohibits me from leaving US territory and working as a consultant, even if the project I work on is crypto software that I could not export of I'd worked on it locally. ... However, outside of such obviously foolish and provocative activities (i.e. anything that could justify a treason charge), I don't believe there's any restriction on the export of cryptographic expertise contained in one's brain. If a US citizen travels to Brazil and works for a company producing a 1024-bit pgp-based email client, there's no US law broken. ... If it is clear that the codebase resides outside of the US, and the US citizen contributes, then in principle the expertise is the only export from the country. Remember, it's not illegal for a US citizen to print out the code to a crypto program, take the resulting ream of paper on an airplane to Australia, and rekey it into a system upon arrival. Only exporting code in compilable or executable format is a violation of silly US law.
Like it or not, sensible or not, what you describe is illegal technical assistance. The only exportable information is that which is clearly public: it has to be printed and it has to be publicly available. Also acceptable is public technical discussion at conferences, etc. Furthermore, some of the other commentors are right: in this area, following what you believe to be the letter of the law in hopes of finding loopholes is not a good idea. Big parts of the law are generally enough written to end with the situation that they mean what their enforcers want them to mean.
Slashdot Mirror
One reason music doesn't seem as dated may just be because music hasn't changed as much as graphics have. While music reproduction and quality are orders of magnitude better than they once were, it seems to me that the difference is less drastic than the advances in graphics (or, seen another way, the nature of older graphics is more primitive than the nature of older music).
It seems to me that Perforce's requiring you to offer public access implies that you're essentially in compliance with the GPL re: source release at all times (the only thing I can think of that might be wrong is that you may do a binary release which doesn't specify exactly where the source code can be retrieved, but you're 99% in compliance since it's always available to anyone).
This seems to obviate your 3rd problem. No matter who releases your code, you'll always be in compliance, because your code is always available.
The problem you are describing is the problem of how to recognize plaintext; when we stumble across the correct decryption key, how can we recognize it?
The first part of the answer is that, for security analysis purposes, we generally assume that the attacker knows what system we're using, starting with what the encryption algorithm is, but including the type & format of the messages. If the attacker knows you're sending a rot128 jpeg image, she can just reverse the process to recover the message (or test a key for correctness).
If you believe that an attacker will not know these details of the system, you will add to security, but watch out: the secret of the system can be pretty easily divulged, and even if the attacker doesn't know the secret of the system, it's pretty hard to estimate how hard it will be to guess it. (For example, every rot-128'd JPEG file will begin with the bytes 0x7F 0x68; sooner or later, someone is going to notice and figure it out.)
To be clear, what has been broken is a single key on an elliptic curve which has a 108 bit order. The smallest key size which Certicom commercially recommends is a 160 bit key, which is on the order of 2^26 times as hard to break (a factor of approximately 67 million).
The papers available at www.cryptosavvy.com are a good, independent, and recent reference for key size comparisons.
Tim Dierks
Chief Technical Officer, Certicom
tdierks@certicom.com
Actually, Bayer lost the trademark on Aspirin after World War I as a part of war reperations to France, England, Russia and the US; it's still a trademark in other countries, such as Canada, where generic brands of acetylsalicylic acid are sold as ASA. Useless fact: another trademark Bayer lost at the same time was Heroin, which was invented by the same chemist who perfected ASA and marketed by Bayer as a cough suppressant. See this ad.
Actually, most signature schemes aren't just encryption in reverse. It's true that this is a rough analogue to how RSA signatures work, but DSA doesn't work this way at all, and since it's patent free, that's what would be used in such a scheme for Linux, most likely.
Also, Linus *is* involved since this policy prohibits the introduction of strong encryption routines into the kernel itself. That means we all lose:
- strong filesystem encryption (at the kernel level)
- strong filesystem authentication (e.g., having a file system which checks the checksums of files before allowing 'execute' access)
Actually, strong authentication is fully exportable, so there wouldn't be anything to keep strong execute authentication from being rolled into the kernel.
But IIRC, there is no provision in US code concerning export that prohibits me from leaving US territory and working as a consultant, even if the project I work on is crypto software that I could not export of I'd worked on it locally.
...
...
However, outside of such obviously foolish and provocative activities (i.e. anything that could justify a treason charge), I don't believe there's any restriction on the export of cryptographic expertise contained in one's brain. If a US citizen travels to Brazil and works for a company producing a 1024-bit pgp-based email client, there's no US law broken.
If it is clear that the codebase resides outside of the US, and the US citizen contributes, then in principle the expertise is the only export from the country. Remember, it's not illegal for a US citizen to print out the code to a crypto program, take the resulting ream of paper on an airplane to Australia, and rekey it into a system upon arrival. Only exporting code in compilable or executable format is a violation of silly US law.
Like it or not, sensible or not, what you describe is illegal technical assistance. The only exportable information is that which is clearly public: it has to be printed and it has to be publicly available. Also acceptable is public technical discussion at conferences, etc. Furthermore, some of the other commentors are right: in this area, following what you believe to be the letter of the law in hopes of finding loopholes is not a good idea. Big parts of the law are generally enough written to end with the situation that they mean what their enforcers want them to mean.