You may think this just means co-operation with the police/FBI/CIA/NSA/etc, but the language is much, much broader.
For instance "in its sole discretion believes" could mean literally anything. Belief means anything and nothing. Do you believe in WMD? Maybe Vonage - without any evidence - believe you look at children "the wrong way". Who knows? The language is so broad that this easily fits. Then the language doesn't mention (although the choice of words implies) that this is about law enforcement. Maybe you offend their code of ethics, perhaps by violating with their newly minted condition about lewdness, harsh language or unpatriotic language. Remember this is about personal phone calls, not a public forum. You may want to whisper sweet nothings to your other half. The nothings, sweet or otherwise, get forwarded to Vonage's opinion of an "appropriate authority" - say the Senate Committee on Public Morals - and you have "consented" to this.
T&Cs like this are an open invitation to abuse by idiological extremists, and there are plenty of those about ATM.
Yoyo tricks and Diablo juggling
on
Extreme Yo-Yoing
·
· Score: 4, Informative
The article mentions a form of yoyo trick where the yoyo leaves the string altogether and the tricks involve balancing the yoyo on the sting.
This reminds me of diablo juggling. Think of a whacking great yoyo, about 8 inches diameter, and a 4 foot long string attached to 2 sticks. Loop the string around the diablo and move the string side to side rapidly to spin it up, then unloop the string and the tricks commence. Experienced performers can use a few diablos at once.
I found some video here.
Take a date file at least 10% larger than the largest message you want to send and fill with entropy - this is your starting pad. Encrypt a message using the first n bytes of the pad - send this. Concatenate the plaintext with the entire pad and pass the result through a secure hash (SHA1, maybe) giving you a mangle key. Encrypt the entire pad with the mangle key to give you the new pad.
Now.. I can't think of any way to begin attacking this, even with a known plaintext/cypher text pair, BUT it isn't as secure as an OPT. No way. OPTs are provably secure. This isn't. It may have some benefits over a conventional shared-secret approach, but I doubt it. Systems such as AES, twofish and the like are probably plenty good enough and more efficient (space and time).
I used to invent crypto systems, until I studied the art. Now I know how useless I was at it.:/ One tip I would add is: begin your message with (say) 256 bits of entropy. If anyone can attack symmetric crypto, it'll throw a handy spanner in their works.
"Double-click's targeted ads are based on a web surfer's use patterns"
Not so fast! When doubleclick introduced their opt-out cookie (I forget how long ago that was), I used it for a while before I blocked their ads. The ads I received during that period were obviously themed according to the site/page content. Page content based ad targetting is old.
All encryption requires secrets. Good algorithms require that only the keys are secret, and everything else (especially the algorithms themselves) can be published without compromising security.
Security Through Obscurity is bad because every (say, MS Media Player) has the same secret. If that secret is discovered, then/everything/ using that secret is compromised.
Asymmetric encryption (e.g. Diffie-Hellman) avoids this problem by having a different secret for each end user. If the secret is discovered then only that user is compromised.
The point is that Security Through Obscurity depends upon widely distributed secrets (e.g. the exact behaviour of binary code), whereas competent encryption doesn't.
This about ownership, identity, certification, trust and validity.
Whoever controls the secret key is in fact the owner of the key.
The user ID is a claim made by the owner and attached to the key. There can be many such claims made; depending upon the wishes, ISP accounts, and intentions of the owner.
Certification is a claim made by a third party that a particuler user ID on a key truly refers to its owner.
Trust is a judgement that you make about the third party who owns the key used to certify a user ID claim. It should be a reflection of how honest, diligent, skeptical and shrewd the third party is. The more serious the consequences of identity fraud (e.g. infiltration of a political protest group), the more miserly you should be with trust.
Validity is the opinion (based on subjective trust and a certification claim) that a particular user ID truly refers to the owner of the key to which it is attached.
That's one fact, two claims, a judgement and an opinion.
Let's take an example:
Suppose I certify some key as belonging to taanderson@metacortex.com. If you knew that I was one of his coworkers, you might trust me and believe the key belongs to Mr Anderson.
If the key also had an ID neo@2600.net, is that second ID valid?
No. The neo ID is a claim, nothing more. Unless someone else that you trust certifies the neo@2600.net ID, then the ID (like all uncertified IDs) is assumed to be invalid.
In fact, if the neo alias were supposed to be covert, then putting it on the same key as a public identity would be extremely stupid - unless it was a forged ID. It's the equivalent of Mr Anderson wearing a button badge saying "I am Neo".
The bug in PGP lies in sometimes treating validity as a property of the key, when it's strictly a property of the user ID claim; allowing validity to "leak" from one ID to another.
My Mustuk V300 with region-code busting loophole menu:) says "Made in China" plain as day on the back of the unit, so it seems the US and Japanese Govs are up to something that they don't want made public.
If you can't trust the NSA, reverse engineer it.
on
NSA Inside?
·
· Score: 3
Personally, I doubt that NSA's SE has a back door in it.
1) They posted under their own name, not anon.
2) They posted tech info on how it works, helping anyone who wants to find a backdoor.
3) They're really not that stupid. Honest.
It's far more likely that this is a cheap trick to help them sneak a back door in later; partly by wasting good paranoid community coders on an obvious red rag, but also by building trust through honest code. You can't stab someone properly unless they trust you first.
If you really don't trust them, do a 2 part project:
1) Read everything about SE, then write a full spec of it's API and operating principles.
2) Write a clean version to the spec and GPL it. Preferably the coders for part 2 should not have seen the NSA version.
You don't have to trust them if you don't want to.
There are two scenarios: with disk reuse and without.
Without disk reuse, you simply destroy the magnetic material by raising it well above the curie temperature for a long time. A conventional gas or electric oven (NOT a microwave) will do the job fine, just remember to pierce or open the casing to avoid an explosion! The weakness of this is that the bad guys can still find the dead drive and get suspicious. You could use thermite or other thorough destruction method, but that can leave evidence that's even more suspicious. A domestic oven is a very innocent degausser.
If you want to keep the use of the disk (you might have a regime of regular data shredding - weekly, maybe) then you have to accept compromise. Although you won't have to explain the molten pool of metal, your disks will still retain the secure deletion software, so that might need explanation. Also, for technical reasons, there is NO WAY to guarantee complete destruction of all data. You can make it difficult to recover. You can make it so difficult that it isn't worth they're making the effort, but they just might get lucky and recover something important. It's a matter of a trade-off. One method is to use encrypted loopback devices to store the data in the first place. Just change your password (which you NEVER wrote down) and they'll have to break AES to recover it. This is quick and easy, just give the device the new password and store something innocent in it and hand the new password to the baddies. Destroying plain text is difficult, destroying encrypted data is not so bad. Just a thought.
The firmware in a new drive will refuse to store data if it contains a "don't store me" message. Actually, it's a single bit, but I want to generalise the technical issue to allow for more sophisticated (e.g. cryptographic or stegged) signalling.
It seems to me that if the HD firmware never sees the no-copy message because cfs (or PGPdisk) has encrypted it, then the firmware can't do anything but assume that it's okay to store. Treating all data as no-copy by default would be the only counter-measure to this, and that would defeat the whole point of a HD. I can't see any manufacturer (or OEM or anyone else) falling for that.
Do tell me if I've misunderstood the technical issues.
Slashdot Mirror
You may think this just means co-operation with the police/FBI/CIA/NSA/etc, but the language is much, much broader.
For instance "in its sole discretion believes" could mean literally anything. Belief means anything and nothing. Do you believe in WMD?
Maybe Vonage - without any evidence - believe you look at children "the wrong way". Who knows? The language is so broad that this easily fits.
Then the language doesn't mention (although the choice of words implies) that this is about law enforcement. Maybe you offend their code of ethics, perhaps by violating with their newly minted condition about lewdness, harsh language or unpatriotic language.
Remember this is about personal phone calls, not a public forum. You may want to whisper sweet nothings to your other half. The nothings, sweet or otherwise, get forwarded to Vonage's opinion of an "appropriate authority" - say the Senate Committee on Public Morals - and you have "consented" to this.
T&Cs like this are an open invitation to abuse by idiological extremists, and there are plenty of those about ATM.
This reminds me of diablo juggling. Think of a whacking great yoyo, about 8 inches diameter, and a 4 foot long string attached to 2 sticks. Loop the string around the diablo and move the string side to side rapidly to spin it up, then unloop the string and the tricks commence. Experienced performers can use a few diablos at once. I found some video here.
Encrypt a message using the first n bytes of the pad - send this.
Concatenate the plaintext with the entire pad and pass the result through a secure hash (SHA1, maybe) giving you a mangle key.
Encrypt the entire pad with the mangle key to give you the new pad.
Now
OPTs are provably secure. This isn't.
It may have some benefits over a conventional shared-secret approach, but I doubt it. Systems such as AES, twofish and the like are probably plenty good enough and more efficient (space and time).
I used to invent crypto systems, until I studied the art. Now I know how useless I was at it.
One tip I would add is: begin your message with (say) 256 bits of entropy. If anyone can attack symmetric crypto, it'll throw a handy spanner in their works.
"Double-click's targeted ads are based on a web surfer's use patterns"
Not so fast! When doubleclick introduced their opt-out cookie (I forget how long ago that was), I used it for a while before I blocked their ads. The ads I received during that period were obviously themed according to the site/page content. Page content based ad targetting is old.
All encryption requires secrets. Good algorithms require that only the keys are secret, and everything else (especially the algorithms themselves) can be published without compromising security.
/everything/ using that secret is compromised.
Security Through Obscurity is bad because every (say, MS Media Player) has the same secret. If that secret is discovered, then
Asymmetric encryption (e.g. Diffie-Hellman) avoids this problem by having a different secret for each end user. If the secret is discovered then only that user is compromised.
The point is that Security Through Obscurity depends upon widely distributed secrets (e.g. the exact behaviour of binary code), whereas competent encryption doesn't.
Whoever controls the secret key is in fact the owner of the key.
The user ID is a claim made by the owner and attached to the key. There can be many such claims made; depending upon the wishes, ISP accounts, and intentions of the owner.
Certification is a claim made by a third party that a particuler user ID on a key truly refers to its owner.
Trust is a judgement that you make about the third party who owns the key used to certify a user ID claim. It should be a reflection of how honest, diligent, skeptical and shrewd the third party is. The more serious the consequences of identity fraud (e.g. infiltration of a political protest group), the more miserly you should be with trust.
Validity is the opinion (based on subjective trust and a certification claim) that a particular user ID truly refers to the owner of the key to which it is attached.
That's one fact, two claims, a judgement and an opinion.
Let's take an example:
Suppose I certify some key as belonging to taanderson@metacortex.com. If you knew that I was one of his coworkers, you might trust me and believe the key belongs to Mr Anderson.
If the key also had an ID neo@2600.net, is that second ID valid?
No. The neo ID is a claim, nothing more. Unless someone else that you trust certifies the neo@2600.net ID, then the ID (like all uncertified IDs) is assumed to be invalid.
In fact, if the neo alias were supposed to be covert, then putting it on the same key as a public identity would be extremely stupid - unless it was a forged ID. It's the equivalent of Mr Anderson wearing a button badge saying "I am Neo".
The bug in PGP lies in sometimes treating validity as a property of the key, when it's strictly a property of the user ID claim; allowing validity to "leak" from one ID to another.
My Mustuk V300 with region-code busting loophole menu :) says "Made in China" plain as day on the back of the unit, so it seems the US and Japanese Govs are up to something that they don't want made public.
1) They posted under their own name, not anon.
2) They posted tech info on how it works, helping anyone who wants to find a backdoor.
3) They're really not that stupid. Honest.
It's far more likely that this is a cheap trick to help them sneak a back door in later; partly by wasting good paranoid community coders on an obvious red rag, but also by building trust through honest code. You can't stab someone properly unless they trust you first.
If you really don't trust them, do a 2 part project:
1) Read everything about SE, then write a full spec of it's API and operating principles.
2) Write a clean version to the spec and GPL it. Preferably the coders for part 2 should not have seen the NSA version.
You don't have to trust them if you don't want to.
There are two scenarios: with disk reuse and without. Without disk reuse, you simply destroy the magnetic material by raising it well above the curie temperature for a long time. A conventional gas or electric oven (NOT a microwave) will do the job fine, just remember to pierce or open the casing to avoid an explosion! The weakness of this is that the bad guys can still find the dead drive and get suspicious. You could use thermite or other thorough destruction method, but that can leave evidence that's even more suspicious. A domestic oven is a very innocent degausser. If you want to keep the use of the disk (you might have a regime of regular data shredding - weekly, maybe) then you have to accept compromise. Although you won't have to explain the molten pool of metal, your disks will still retain the secure deletion software, so that might need explanation. Also, for technical reasons, there is NO WAY to guarantee complete destruction of all data. You can make it difficult to recover. You can make it so difficult that it isn't worth they're making the effort, but they just might get lucky and recover something important. It's a matter of a trade-off. One method is to use encrypted loopback devices to store the data in the first place. Just change your password (which you NEVER wrote down) and they'll have to break AES to recover it. This is quick and easy, just give the device the new password and store something innocent in it and hand the new password to the baddies. Destroying plain text is difficult, destroying encrypted data is not so bad. Just a thought.
The firmware in a new drive will refuse to store data if it contains a "don't store me" message. Actually, it's a single bit, but I want to generalise the technical issue to allow for more sophisticated (e.g. cryptographic or stegged) signalling.
It seems to me that if the HD firmware never sees the no-copy message because cfs (or PGPdisk) has encrypted it, then the firmware can't do anything but assume that it's okay to store. Treating all data as no-copy by default would be the only counter-measure to this, and that would defeat the whole point of a HD. I can't see any manufacturer (or OEM or anyone else) falling for that.
Do tell me if I've misunderstood the technical issues.