Now somebody wants to install an auto-destruct on every computer so that if (when) an exploit is discovered, someone could take down the entire electronic infrastructure of the country and parts of the rest of the world without even putting in the work to write an email virus?
Why are we worrying about an Omniscience Protocol when some machines still lack a working calendar? Priorities people!
Re:Does fair use widely exist anymore?
on
Free Culture
·
· Score: 1
We will have to start demanding fair use rights more as consumers to win them back.
Unfortunately few consumers even know what fair use is, much less how to demand it. Voting with wallets won't work in this instance. You stand a better chance by giving your money to the ACLU instead. They know how to pick and choose their battles well. $1000 contributed to the ACLU will do a lot more than a $10,000 blip that never shows up in Disney's pocketbook.
I would like to see a language that preserves as many features of C++ as possible while adding garbage collection, memory safety, language-based security and guaranteed binary compatibility between platforms/OSes. I don't think managed C++ is "it". Why can't a VM support multiple inheritence? Any pointers?
It's been a while since I looked at it, but the D language seems to address many of your gripes (other than multiple inheritance).
The last time I checked Yahoo's account creation challenge-response system was vulnerable to a trivial attack. From my experiments, the challenge field suffers from these problems:
No association with the http page request which generated it
No usage frequency limits
No expiration time (at least, not shorter than 1 month)
This allows one to build a dictionary of valid challenge/response pairs which can be reused indefinitely. I did this successfully with a perl script two years ago (I study security). I haven't tested the script since then but the system doesn't appear to have changed.
Granted this is an implementation flaw which can be corrected. But how many challenge-response systems out there suffer from similar problems? I'd wager quite a few.
At first I was pleased to see ROTK do so well. Then when it won best picture they equated it with Titanic and I remembered what a sham the oscars have become. I'd almost prefer ROTK didn't win.
Note that quantum cryptography is a misnomer for the BB84 and BB92 protocols. These should be called quantum key distribution because that's all they do. You can't encrypt information with them, just exchange keys. You still need conventional crypto to use the keys with.
Also keep in mind you need a dedicated fiber link between the communicating parties. Quantum crypto is only useful in ultra-paranoid, damn-the-expense applications (military, govt). For the majority of uses, it's not a practical improvement over public-key cryptography (or even private-key for that matter).
If you don't mind, I'd like to ask you a somewhat stupid question. Would quantum computers be able to do anything with things like elliptic curve cryptography? There are various crypto schemes coming from algebraic geometry---hyperelliptic curves and so on. I'm not an expert, but it's my understanding that they don't rely on difficulty of factoring integers.
Not a stupid question at all. You're right, there are asymmetric cryptosystems not based on integer factorization. The major one is discrete logarithms, over integer fields or elliptic curves. I've been told that these problems are reducible to each other -- i.e. any discrete log problem can be converted to an equivalent integer factorization problem in polynomial time and vice versa. If so, Shor's algorithm can be used to break any cryptosystem based on discrete logs too.
There are a few other asymmetric primitives that aren't as widely used (quadratic residues for one). I don't know if the same applies to them.
I'm currently taking a grad class on quantum computing at UC Davis. The technology is unbelievably fragile right now. There are huge hurdles to overcome before a non-trivial quantum computer is built. The security ramifications are blown way out of proportion. Consider:
Current architectures don't scale past about 7 qubits, which is barely enough to factor the number 15. Part of the problem is letting all the qubits in the system interact with each other. It's not even certain that a scaleable architecture can be developed.
The quantum state of the machines decays very quickly, requiring a lot of error corrections for sustainable calculations. It's not a given yet whether such architectures are possible.
Shor's algorithm is algorithmically faster than classical sieve methods for factoring numbers. However the constants involved are huge. No one knows where the curves cross yet (mainly because no one's built a large enough quantum computer to extrapolate from yet). It may require impossibly large numbers to benefit from Shor's speed advantage. I.e if Shor's is only faster than sieves on composites of 50,000+ bits, asymmetric crypto is safe.
Symmetric crypto will barely notice when/if quantum computers appear. Grover's may be able to effectively halve the key size for brute-force searches, but it's gonna be much, much slower than a classical computer on that reduced size. A 256-bit key would be at least as immune to brute-force from quantum computers as a 128-bit key is to conventional machines.
Quantum cryptography is a misnomer for the BB84 and BB92 protocols. These should be called quantum key distribution because that's all they do. You can't encrypt information with them, just exchange keys. You still need conventional crypto to use the keys with.
There are indications that the quantum world might provide equivalents to digital signatures and possibly other asymmetric crypto primitives. However like quantum key distribution it requires a dedicated quantum channel (e.g. a single fiber optic cable) between the two parties. It's gonna be expensive to setup.
Basically, quantum computers and quantum cryptography will have little effect on the security world. Quantum crypto is only useful in ultra-paranoid, damn-the-expense applications (military, govt). Worse case scenario, the rest of the world has to give up asymmetric crypto and fall back on symmetric methods. Some infrastructure gets replaced and life goes on.
I don't expect to see non-trivial quantum computers in the research lab for a minimum of 3 decades, though the professor sees them in 1.
In the security community, 'by design' has nothing to do with intentions. If you read it that way then you are misinterpreting the term as commonly understood by professionals.
As someone who works in security, "insecure by design" has a precise meaning to me, which I've not seen mentioned here yet. The developer's intentions have nothing to do with it. "Insecure by design" means every implementation of a given system will share a common set of security vulnerabilities. In other words, the design (think API or protocol) itself is flawed. No implementation is safe.
Example: The design of the http protocol does not provide any method of running arbitrary code from the client on the server. A perfectly implemented web server will contain no remote vulnerabilities of this type. Flaws in particular web servers like IIS are caused by mistakes in the implementation, not the http protocol itself. The protocol is secure by design with regard to this attack.
Contrast this with a protocol whose design is insecure. Nothing in the SMTP spec addresses the issue of spam. High-volume anonymous message injection is allowed by the protocol. Solutions to spam have to be implemented externally with things like blacklists and filters (which are considered external even when run during the SMTP transaction as they aren't part of the SMTP protocol itself). No SMTP server, no matter how perfectly implemented, can both completely follow the SMTP spec and reject all spam. Thus SMTP is insecure by design with regard to spam.
Nebulous terms like "windows" and "secure" mean next to nothing by themselves. What is "windows"? The NT kernel? The win32 API? The set of programs and services enabled by a default install? Secure against what types of attacks?
For reasonable definitions of the above, the statement "Windows is insecure by design" certainly makes sense. Take "windows" to mean the win32 API and "secure" to mean enforcement of access control. Remember the shatter attacks discovered last year? That's a flaw in the design of the win32 API. No implementation is safe. It fits the definition of "insecure by design" perfectly. And Microsoft has alluded to more such vulnerabilities lurking in the win32 API (remember when they said they couldn't reveal all the APIs for security reasons?).
A big reason given for this policy is the storage fees. It's expensive for them to store everyone's character server-side.
Frankly I'm surprised no MMORPG's have attempted client-side storage yet. The security problems are relatively trivial. MAC (keyed hash) the data before it leaves the server and verify it when it comes back. The client transmits the MACed data when he starts a session, the server modifies it locally during play, and the client gets back the updated and reMACed data when he logs off. If the client tries to modify his char data, the server detects the change and refuses to load the char. If the client gets disconnected before receiving their updated char file, then have the server store it so the data isn't lost.
With an onboard secure coprocessor card, the MACs can be computed and verified quickly and cheaply with little risk of key compromise. The player will have to wait a little longer to load up the game, but if the alternative is one char per acount I'd certainly do it.
This should significantly reduce the storage costs, but with a corresponding (but probably not equal) rise in bandwidth costs. It all hinges on the cost per byte of bandwidth versus storage. If there's ever a point when bandwidth is cheaper, this model should be viable.
It would be cool to have an 'anything goes' kind of area on the net.
You mean like international waters? Where cowboys wage shootouts and sea captains marry cows? Those poor saps back on land will never know the simple pleasures of a monkey knife fight. <sigh>
As Authenticode has demonstrated oh so well, no code signing system is perfect. Trojans will still occasionally make their way into pre-signed binaries that get distributed before the problem is discovered. So you'll still need a centralized external database, one that holds signature revocations. Without this, signature schemes aren't very useful.
Granted, the database would presumably be much smaller than an MD5 checksum since only those binaries incorrectly signed need to be stored. However the need for an external database remains.
Slashdot Mirror
No, no, yes, and none. Next!
Gator has "users" in the same sense herpes does.
You're a helper monkey! This isn't helping!
An X-15 Cruise Basselope of course.
Apparently not
Why are we worrying about an Omniscience Protocol when some machines still lack a working calendar? Priorities people!
Unfortunately few consumers even know what fair use is, much less how to demand it. Voting with wallets won't work in this instance. You stand a better chance by giving your money to the ACLU instead. They know how to pick and choose their battles well. $1000 contributed to the ACLU will do a lot more than a $10,000 blip that never shows up in Disney's pocketbook.
It's been a while since I looked at it, but the D language seems to address many of your gripes (other than multiple inheritance).
C is dead! Long live C++!
Where's the proof?
The last time I checked Yahoo's account creation challenge-response system was vulnerable to a trivial attack. From my experiments, the challenge field suffers from these problems:
This allows one to build a dictionary of valid challenge/response pairs which can be reused indefinitely. I did this successfully with a perl script two years ago (I study security). I haven't tested the script since then but the system doesn't appear to have changed.
Granted this is an implementation flaw which can be corrected. But how many challenge-response systems out there suffer from similar problems? I'd wager quite a few.
At first I was pleased to see ROTK do so well. Then when it won best picture they equated it with Titanic and I remembered what a sham the oscars have become. I'd almost prefer ROTK didn't win.
Note that quantum cryptography is a misnomer for the BB84 and BB92 protocols. These should be called quantum key distribution because that's all they do. You can't encrypt information with them, just exchange keys. You still need conventional crypto to use the keys with.
Also keep in mind you need a dedicated fiber link between the communicating parties. Quantum crypto is only useful in ultra-paranoid, damn-the-expense applications (military, govt). For the majority of uses, it's not a practical improvement over public-key cryptography (or even private-key for that matter).
Not a stupid question at all. You're right, there are asymmetric cryptosystems not based on integer factorization. The major one is discrete logarithms, over integer fields or elliptic curves. I've been told that these problems are reducible to each other -- i.e. any discrete log problem can be converted to an equivalent integer factorization problem in polynomial time and vice versa. If so, Shor's algorithm can be used to break any cryptosystem based on discrete logs too.
There are a few other asymmetric primitives that aren't as widely used (quadratic residues for one). I don't know if the same applies to them.
- Current architectures don't scale past about 7 qubits, which is barely enough to factor the number 15. Part of the problem is letting all the qubits in the system interact with each other. It's not even certain that a scaleable architecture can be developed.
- The quantum state of the machines decays very quickly, requiring a lot of error corrections for sustainable calculations. It's not a given yet whether such architectures are possible.
- Shor's algorithm is algorithmically faster than classical sieve methods for factoring numbers. However the constants involved are huge. No one knows where the curves cross yet (mainly because no one's built a large enough quantum computer to extrapolate from yet). It may require impossibly large numbers to benefit from Shor's speed advantage. I.e if Shor's is only faster than sieves on composites of 50,000+ bits, asymmetric crypto is safe.
- Symmetric crypto will barely notice when/if quantum computers appear. Grover's may be able to effectively halve the key size for brute-force searches, but it's gonna be much, much slower than a classical computer on that reduced size. A 256-bit key would be at least as immune to brute-force from quantum computers as a 128-bit key is to conventional machines.
- Quantum cryptography is a misnomer for the BB84 and BB92 protocols. These should be called quantum key distribution because that's all they do. You can't encrypt information with them, just exchange keys. You still need conventional crypto to use the keys with.
- There are indications that the quantum world might provide equivalents to digital signatures and possibly other asymmetric crypto primitives. However like quantum key distribution it requires a dedicated quantum channel (e.g. a single fiber optic cable) between the two parties. It's gonna be expensive to setup.
Basically, quantum computers and quantum cryptography will have little effect on the security world. Quantum crypto is only useful in ultra-paranoid, damn-the-expense applications (military, govt). Worse case scenario, the rest of the world has to give up asymmetric crypto and fall back on symmetric methods. Some infrastructure gets replaced and life goes on.I don't expect to see non-trivial quantum computers in the research lab for a minimum of 3 decades, though the professor sees them in 1.
In the security community, 'by design' has nothing to do with intentions. If you read it that way then you are misinterpreting the term as commonly understood by professionals.
As someone who works in security, "insecure by design" has a precise meaning to me, which I've not seen mentioned here yet. The developer's intentions have nothing to do with it. "Insecure by design" means every implementation of a given system will share a common set of security vulnerabilities. In other words, the design (think API or protocol) itself is flawed. No implementation is safe.
Example: The design of the http protocol does not provide any method of running arbitrary code from the client on the server. A perfectly implemented web server will contain no remote vulnerabilities of this type. Flaws in particular web servers like IIS are caused by mistakes in the implementation, not the http protocol itself. The protocol is secure by design with regard to this attack.
Contrast this with a protocol whose design is insecure. Nothing in the SMTP spec addresses the issue of spam. High-volume anonymous message injection is allowed by the protocol. Solutions to spam have to be implemented externally with things like blacklists and filters (which are considered external even when run during the SMTP transaction as they aren't part of the SMTP protocol itself). No SMTP server, no matter how perfectly implemented, can both completely follow the SMTP spec and reject all spam. Thus SMTP is insecure by design with regard to spam.
Nebulous terms like "windows" and "secure" mean next to nothing by themselves. What is "windows"? The NT kernel? The win32 API? The set of programs and services enabled by a default install? Secure against what types of attacks?
For reasonable definitions of the above, the statement "Windows is insecure by design" certainly makes sense. Take "windows" to mean the win32 API and "secure" to mean enforcement of access control. Remember the shatter attacks discovered last year? That's a flaw in the design of the win32 API. No implementation is safe. It fits the definition of "insecure by design" perfectly. And Microsoft has alluded to more such vulnerabilities lurking in the win32 API (remember when they said they couldn't reveal all the APIs for security reasons?).
Because of how the human brain works, you can show the same pictures to different people and almost always come up with different passwords.
I don't know about that. Everyone I talked who followed the inkblot link saw the same thing: "Too many users".
"Today, more U.S. citizens use file-sharing software than voted for President Bush,"
So millions of people doing the wrong thing somehow makes it right. I don't think so.
It doesn't make it right, but at least they'll have a chance to correct their mistake in 2004.
If he's like the GNU fileutils, the 50 is octal. Which makes him only 40 decimal years old.
It could be worse. If he used hex, he'd be 80 decimal.
A big reason given for this policy is the storage fees. It's expensive for them to store everyone's character server-side.
Frankly I'm surprised no MMORPG's have attempted client-side storage yet. The security problems are relatively trivial. MAC (keyed hash) the data before it leaves the server and verify it when it comes back. The client transmits the MACed data when he starts a session, the server modifies it locally during play, and the client gets back the updated and reMACed data when he logs off. If the client tries to modify his char data, the server detects the change and refuses to load the char. If the client gets disconnected before receiving their updated char file, then have the server store it so the data isn't lost.
With an onboard secure coprocessor card, the MACs can be computed and verified quickly and cheaply with little risk of key compromise. The player will have to wait a little longer to load up the game, but if the alternative is one char per acount I'd certainly do it.
This should significantly reduce the storage costs, but with a corresponding (but probably not equal) rise in bandwidth costs. It all hinges on the cost per byte of bandwidth versus storage. If there's ever a point when bandwidth is cheaper, this model should be viable.
You mean like international waters? Where cowboys wage shootouts and sea captains marry cows? Those poor saps back on land will never know the simple pleasures of a monkey knife fight. <sigh>
As Authenticode has demonstrated oh so well, no code signing system is perfect. Trojans will still occasionally make their way into pre-signed binaries that get distributed before the problem is discovered. So you'll still need a centralized external database, one that holds signature revocations. Without this, signature schemes aren't very useful.
Granted, the database would presumably be much smaller than an MD5 checksum since only those binaries incorrectly signed need to be stored. However the need for an external database remains.
Which would run in a direct parallel to the Space Program.
Or Slashdot.
Before you pay for a 'slashvertisement', you might wanna make sure your web server can handle the load...