Friends were boating in a southern state a month ago, not far from an active nuclear power plant. The weather turned nasty. Then the boat hit a rock. They had to beach the boat... on unfenced power plant property. Not a soul was around. No one came to greet them. They could have stayed longer and had a hot snack (microwaving not required).
Homeland Insecurity is doing a good job of keeping nail clippers off of airplanes, but the agency doesn't seem at all concerned about unauthorized access to nuclear power plants. I guess this is not too surprising, considering that Ridge is in charge. Well, maybe 'in charge' is the wrong term.
It's important to recognize that Trusted Computing (TC) is made up of both software and hardware components. To realize the software features of TC, significant hardware support is necessary: e.g. MS's NGSCB is completely dependent on Intel's TC hardware (called LaGrande Technology). (There are many other TC hardware and software vendors, but NGSCB and LaGrande tend to attract the most attention for obvious reasons.)
Intel's goal has been to design a set of neutral TC primitives that satisfy influential partners and customers, but avoid the pickle that the PIII Processor ID fiasco got them into. With LaGrande Technology, they have succeeded in achieving both goals (as far as I can tell from publicly available information). With a 'neutral' set of hardware primitives, the question then becomes whether TC software (OS and application) will be built for good or evil.
Let's assume that NGSCB is utterly evil. If this is true, it won't be good for MS or its customers in the long run. Why not let MS and its customers stew in their own juices? Why would the anti-MS community care? (They're not using MS products or services are they?)
Most of my TC fears come from what OS and application vendors *may* do under the covers. Open source solutions would put my concerns to rest. (MS has promised to make their TC software available, but something tells me the public won't get to see all of it.) The open source community should see this as another opportunity to provide consumers with better alternatives. We should focus our energies on constructing alternatives to NGSCB that maximize the TC positives and minimize the TC negatives, instead of wasting our time on tedious anti-MS ranting.
[...] 10GHz, that means they can do 2^64 operations in a bit over 68 years.
Sorry to nit and please don't be offended, but since you were trying to set things straight, I have to point out what I assume was a typo.
At 10GHz, 2^64 operations would take ~ 58.45 years.
I agree though (unless swillden is an ancient redwood tree) that this is a bit more than a 'little time'.
Re:Encryption, only for protecting privacy?
on
Javascrypt
·
· Score: 1
In 1995, Hans Dobbertin published an attack that effectively broke MD5. The partial attack shed light on MD5 weaknesses, causing some to suggest to not use it. Especially since alternatives (e.g. SHA1) exist.
Re:Encryption, only for protecting privacy?
on
Javascrypt
·
· Score: 1
I'm confused by your reply. I think you're referring to my comment about MD5 being cracked. My comment was caused by my cumulative skepticism about javascrypt, and their choice of MD5 for hashing.
MD5 was effectively broken in 1995 by Hans Dobbertin. Several cryptographers whom I respect claim that MD5's weaknesses are significant enough that people should not use it --- for digital signatures. I don't know enough to say that the crack makes MD5 good for nothing --- not even general hashes.
I looked at the RC5-64 challenge, and it didn't seem to focus on MD5. So, I'm not sure where you were going with that.
Encryption, only for protecting privacy?
on
Javascrypt
·
· Score: 2, Insightful
'The sole reason for encryption is to protect privacy.'
Statements like this from developers of a 'high-security data encryption solution' make me worried.
And assertions that transparency will make software secure always presume that someone with the 'required expertise to pass judgment' will actually do so.
For historic reasons [3], GnuPG permits creating ElGamal keys which are usable for both encryption and signing. It is even possible to have one key (the primary one) used for both operations. This is not considered good cryptographic practice, but is permitted by the OpenPGP standard.
I don't understand why it is 'not considered good cryptographic practice' to use the same key to sign and encrypt. Is Werner saying that this an ElGamal weakness or is it a general public-key encryption weakness?
If it is not considered good cryptographic practice, then why is (was?) it in the OpenPGP standard?
I don't agree with the analogy that 'It's an addiction, like taking drugs'. This feeds the myth of sick, pastey people in dark rooms out to destroy suburban life.
Just because you like to do something, and do it a lot, doesn't mean it's an addiction, like taking drugs. (Is breathing an addiction? Is drinking water an addiction? Is playing tennis an addiction?)
Not that I have anything against taking drugs. It's just a poor analogy.
Slashdot Mirror
Friends were boating in a southern state a month ago, not far from an active nuclear power plant. The weather turned nasty. Then the boat hit a rock. They had to beach the boat... on unfenced power plant property. Not a soul was around. No one came to greet them. They could have stayed longer and had a hot snack (microwaving not required).
Homeland Insecurity is doing a good job of keeping nail clippers off of airplanes, but the agency doesn't seem at all concerned about unauthorized access to nuclear power plants. I guess this is not too surprising, considering that Ridge is in charge. Well, maybe 'in charge' is the wrong term.
It's important to recognize that Trusted Computing (TC) is made up of both software and hardware components. To realize the software features of TC, significant hardware support is necessary: e.g. MS's NGSCB is completely dependent on Intel's TC hardware (called LaGrande Technology). (There are many other TC hardware and software vendors, but NGSCB and LaGrande tend to attract the most attention for obvious reasons.)
Intel's goal has been to design a set of neutral TC primitives that satisfy influential partners and customers, but avoid the pickle that the PIII Processor ID fiasco got them into. With LaGrande Technology, they have succeeded in achieving both goals (as far as I can tell from publicly available information). With a 'neutral' set of hardware primitives, the question then becomes whether TC software (OS and application) will be built for good or evil.
Let's assume that NGSCB is utterly evil. If this is true, it won't be good for MS or its customers in the long run. Why not let MS and its customers stew in their own juices? Why would the anti-MS community care? (They're not using MS products or services are they?)
Most of my TC fears come from what OS and application vendors *may* do under the covers. Open source solutions would put my concerns to rest. (MS has promised to make their TC software available, but something tells me the public won't get to see all of it.) The open source community should see this as another opportunity to provide consumers with better alternatives. We should focus our energies on constructing alternatives to NGSCB that maximize the TC positives and minimize the TC negatives, instead of wasting our time on tedious anti-MS ranting.
Sorry to nit and please don't be offended, but since you were trying to set things straight, I have to point out what I assume was a typo.
At 10GHz, 2^64 operations would take ~ 58.45 years.
I agree though (unless swillden is an ancient redwood tree) that this is a bit more than a 'little time'.
In 1995, Hans Dobbertin published an attack that effectively broke MD5. The partial attack shed light on MD5 weaknesses, causing some to suggest to not use it. Especially since alternatives (e.g. SHA1) exist.
MD5 was effectively broken in 1995 by Hans Dobbertin. Several cryptographers whom I respect claim that MD5's weaknesses are significant enough that people should not use it --- for digital signatures. I don't know enough to say that the crack makes MD5 good for nothing --- not even general hashes.
I looked at the RC5-64 challenge, and it didn't seem to focus on MD5. So, I'm not sure where you were going with that.
Statements like this from developers of a 'high-security data encryption solution' make me worried.
And assertions that transparency will make software secure always presume that someone with the 'required expertise to pass judgment' will actually do so.
I thought MD5 was cracked?
I don't understand why it is 'not considered good cryptographic practice' to use the same key to sign and encrypt. Is Werner saying that this an ElGamal weakness or is it a general public-key encryption weakness? If it is not considered good cryptographic practice, then why is (was?) it in the OpenPGP standard?
I don't agree with the analogy that 'It's an addiction, like taking drugs'. This feeds the myth of sick, pastey people in dark rooms out to destroy suburban life. Just because you like to do something, and do it a lot, doesn't mean it's an addiction, like taking drugs. (Is breathing an addiction? Is drinking water an addiction? Is playing tennis an addiction?) Not that I have anything against taking drugs. It's just a poor analogy.