Yeah and in US too, can't recall the details but 5-7 years (or so) ago there was a big stink where CIA had spied on Airbus to provide Boeing with data that gave them unfair advantage in a bidding for some major contract.
I really don't think any goverment that has this kind of industries to protect is above a little industrial espionage, they do the traditional kind anyways...
Rubberhose has been mentioned many times, it has support for N keys and has all the same basic requirements, ie: they cannot prove you have additional keys and you cannot prove that you don't have.
>ie it possible in 60 second to crack all the gsm phone keys regardless of the encrption >
This is because the GSM encryption is crap, which is due to design constraints from the time way back when the standard was written. The main reason to have encryption there at all is to keep honest people honest (the call routers have wiretap capability anyway) and to appease peoples privacy concerns (remember those unencrypted & analog cordless phones...)
The real joke is that in many places the LOS microwave links between the basestations are not encrypted...
Anyways proper cryptosystems are for all practical purposes uncrackable if the keys are lost. They will also often use multiple "session" of "file" keys encrypted with the master key, so cracking for example via a known plaintext (probably easy to find these on computer systems) the key for single file does not yield the master key for all files.
The master key is of course encrypted with your passphrase (since the key is just random bits it's a lot of work to verify if an attempt at the passphrase was correct or not [need to try to decrypt some files too])
Now the best approach is to have a way to destroy the master key (as outlined in the magic usb-fob) so there is not passphrase to attack and successfull attack against a single file will not help with the other files.
1. F-Secures Orion engine is fully heuristics based (file analysis), it uses signatures only fix false positives, consistently getting great scores from VB. 2. They also now have an engine (called ExploitShield) that uses heuristics (and signatures) to prevent programs (that in themselves might be good) from doing bad things, see for example http://www.f-secure.com/weblog/archives/00001727.html (using heuristics to block the FF 3.5 JS exploit)
Full disclosure: I used to work for F-Secure (partner, ie 3rd tier, support for AV and crypto; we escalated to R&D) until 2001.
And control the satellite descrambler how (yes there are ways but they just suck in more way than one) ? How to get program info out of the box in case some broadcast time changes ?
Also the analog signal quality you get out is likely to be way below broadcast.
There is no need to outlaw breaking the encryption to make snooping illegal, AFAIK it's invasion of privacy even in the US to use a telescope or binoculars to spy on your neighbour. OTOH it's more than a bit stupid using weak crypto for private data: I treat my wireless network as untrusted and it's firewalled accordingly even though it has encryption to keep bandwidth leeches out.
Netflix example is breaking and entering with copyright infringiment, it should have nothing to do with DMCA but breaking the DVD "encryption" of course has...
Any default install that is, you can of course install services yourself and open yourself up to all kinds of surprises.
That said I used to run OpenBSD on firewalls before I decided minimal Linux install is good enough and I don't have to remind me of the BSD:isms when I need to adjust the rules.
It's not to say that the BSD way is somehow inferior but I have enough flavours of *nix to remember as it is.
A simple PWM circuit (http://www.solorb.com/elect/solarcirc/pwm1/) can handle the dimming, right now too tired to think of a better way to change the duty cycle than use digitally controlled potentiometers (I made a circuit for my bikes handlebar heaters that has toggle switch for up/down, which drives the input on the digital pot).
Maybe I used the wrong word, not my native language...
The cell phone likely has some places where air can get in and out, earpiece and mic at the very least. I meant that the whole circuit and all the ICs would be completely inside the plastic (though I had totally forgotten about them fancy comformal coatings), same idea as dipping the whole thing in expoxy.
It does become a problem if the heat can't get away, at the very least component lifetime would significantly shortened (though who cares whether the thingamagick dies in 10 vs 3 years if expected usable lifetime is 3 years anyways because the field moves so fast).
How will they achieve this without encasing all the components in the plastic, even if the board conductors were all encased (it's not like the anti-solder screen [green stuff on the board] could not be made waterproof and I think it already is) at least some of the components simply cannot be (due to heat dissipation problems). I have made completely waterproof circuit boards (simple PWM stuff, they don't generate enough heat for it to be an issue), the only connectors are rated for underwater and the board encased with epoxy, not really repairable though...
So anyways, since some of the components must be exposed they will have exposed connectors ergo water getting in will short-circuit it.
I don't know if it would work to use only such active components that have connector-bar on the underside and then just encase it up to the sides but this would add significant cost (connectors themselves, size of components -> board size...) and repair would still be out of the question.
Oh yes, Okami is great, I also liked GC Zelda (wind waker) cell-shaded graphics a lot (and couldn't understand why they drew so much flack from some circles [except maybe them being immature but that would be ad hominem])
Sorry, can't find the reference anymore (maybe the reg does not keep old archives on-line).
Anyways a few years back there was an article about a (botched) migration to all-Microsoft on Australian bank, sure enough project management was also to blame but converting mainframe software to run on windows servers is not the best of ideas if you plan to keep your availability and performance.
So the high-level manager responsible for dictating this "strategy" got sacked.
Thus this classic paraphrase of an even older classic quote hasn't held water for a long time now. Of course one could just say the "the exception confirms the rule", since these cases are rare.
To clarify the birthday problem is fundamental and it basically means that even in good algorithms one *on average* needs to check half of the possible key space to brute force the key.
In not-so-good algorithms (for example uneven distribution of keys) one can tune the search space and get away with checking much smaller amount of keys than half of the theoretical space.
And as stated earlier, cryptographers will consider an algo broken if there exist an attack that is better than pure brute force (need to check less than half of the keys), practical attacks are a wholly different matter.
And what comes to the MD5 debacle, it was known to be broken for ages and still was used for new certificates, that's just stupid. Granted SHA-1 is also broken, but for it there are no practical attacks, RIPEMD160 has no breaks yet but it seems it's not officially supported in SSL.
I'd guess the server only allows static delay or they simply don't know how to configure exponential backoff.
Either way it's not exactly smart to have it so high; what is the estimated cost of hacked account on the FTP ? Anyone who undestands security understands that it cannot be made perfect, thus the goals should be
1. Cost of security measures (direct and non-direct like loss of productivity) must not exceed cost (again direct and non-direct) of break (exact balance of these costs is fuzzy) 2. Make breaking more expensive than what can by gained by exploiting the break.
>>[citation desperately needed] > >If Stephen Hawking says something about physics, do you require a citation from him? Nielson is recognized as one of the leading experts in his field. >
But the "no increase in security" is statement in security and mr Nielsen is expert in *usability*.
The point being that those who provide the encrypted data must encrypt it in a special way to allow the homomorphic properties to be taken advantage of.
Can't remember offhand but check out "The Code Book" by Simon Singh it has a lot of really interesting crypto history.
Anyways back when it was invented (twice actually, first time by british military intelligence and kept secret so Rivest, Shamir and Adleman could invent it later) it required way too much resources to be usable for field agents/general use.
The downside to quantum encryption is that you have to have an uninterrupted fiber optic line from one point to the other. If, at any point, that line has to go through a switch of some sort, you now have a weak point in the encryption where someone can be listening in without you knowing.
It's not just a weak point in the "encryption" (we're talking about key-exchange, the encryption itself is done with traditional algorithms), but AFAIUnderstand this the switch by definition needs to observe the photons and thus mess with their state triggering exact same detectable issues as an eavesdropper would.
Now a point about traditional crypto algos: If your data is sufficiently small or your key-exchange can work fast enough you can always use OTP for encryption which means your weak point is in the random source used to generate the OTP (granted: good truly random source is likely to be included with any quantum key-exchange device since both ends need to choose their filter orientations randomly).
OTOH Rubberhose has interesting approach to the hidden volumes.
Short version: you cannot ever prove that you have provided passwords to *all* volumes, and of course they can never prove that you haven't. Which means that after giving up a few "throwaway" volume keys you can start screaming "there is no more" while they beat you with the proverbial rubber hose.
The problem is getting away with the money, electronics transfers are easy to track and if $x/2 is large enough the red tape of tracking across borders is not wide enough (and if they say that this is used to fund terrorism even less so).
Getting large sums of cash out of just about any bank will flag you so transferring to an account in another country, going there to get cash and then depositing elsewhere is going to get you or someone working for you identified as the last known link in the chain and taken for questioning.
Getting cash in the first place is even more sure-fire way to eiher get caught or not get the money.
As you say, you don't get to choose the collision, that's why it's not time to panic.
Actually there was a demonstrated attack (can't remember the URL now) on signing a PostScript document, attacker would make two documents with different content and add non-printing crap to the "innocent" file untill collision then have the innocent document signed and move the signature to the other document, granted this is very different from forging a log line
Such a scheme would make it impossible for you to tamper with the logs unless you had either subverted sha1
Of course one should choose some other hash function, SHA-1 has been broken and while there is no reason to panic yet, using SHA-1 for new applications would not be wise.
Slashdot Mirror
Yeah and in US too, can't recall the details but 5-7 years (or so) ago there was a big stink where CIA had spied on Airbus to provide Boeing with data that gave them unfair advantage in a bidding for some major contract.
I really don't think any goverment that has this kind of industries to protect is above a little industrial espionage, they do the traditional kind anyways...
Rubberhose has been mentioned many times, it has support for N keys and has all the same basic requirements, ie: they cannot prove you have additional keys and you cannot prove that you don't have.
>ie it possible in 60 second to crack all the gsm phone keys regardless of the encrption
>
This is because the GSM encryption is crap, which is due to design constraints from the time way back when the standard was written. The main reason to have encryption there at all is to keep honest people honest (the call routers have wiretap capability anyway) and to appease peoples privacy concerns (remember those unencrypted & analog cordless phones...)
The real joke is that in many places the LOS microwave links between the basestations are not encrypted...
Anyways proper cryptosystems are for all practical purposes uncrackable if the keys are lost. They will also often use multiple "session" of "file" keys encrypted with the master key, so cracking for example via a known plaintext (probably easy to find these on computer systems) the key for single file does not yield the master key for all files.
The master key is of course encrypted with your passphrase (since the key is just random bits it's a lot of work to verify if an attempt at the passphrase was correct or not [need to try to decrypt some files too])
Now the best approach is to have a way to destroy the master key (as outlined in the magic usb-fob) so there is not passphrase to attack and successfull attack against a single file will not help with the other files.
Just a few notes:
1. F-Secures Orion engine is fully heuristics based (file analysis), it uses signatures only fix false positives, consistently getting great scores from VB.
2. They also now have an engine (called ExploitShield) that uses heuristics (and signatures) to prevent programs (that in themselves might be good) from doing bad things, see for example http://www.f-secure.com/weblog/archives/00001727.html (using heuristics to block the FF 3.5 JS exploit)
Full disclosure: I used to work for F-Secure (partner, ie 3rd tier, support for AV and crypto; we escalated to R&D) until 2001.
And control the satellite descrambler how (yes there are ways but they just suck in more way than one) ? How to get program info out of the box in case some broadcast time changes ?
Also the analog signal quality you get out is likely to be way below broadcast.
There is no need to outlaw breaking the encryption to make snooping illegal, AFAIK it's invasion of privacy even in the US to use a telescope or binoculars to spy on your neighbour. OTOH it's more than a bit stupid using weak crypto for private data: I treat my wireless network as untrusted and it's firewalled accordingly even though it has encryption to keep bandwidth leeches out.
Netflix example is breaking and entering with copyright infringiment, it should have nothing to do with DMCA but breaking the DVD "encryption" of course has...
Any default install that is, you can of course install services yourself and open yourself up to all kinds of surprises.
That said I used to run OpenBSD on firewalls before I decided minimal Linux install is good enough and I don't have to remind me of the BSD:isms when I need to adjust the rules.
It's not to say that the BSD way is somehow inferior but I have enough flavours of *nix to remember as it is.
A simple PWM circuit (http://www.solorb.com/elect/solarcirc/pwm1/) can handle the dimming, right now too tired to think of a better way to change the duty cycle than use digitally controlled potentiometers (I made a circuit for my bikes handlebar heaters that has toggle switch for up/down, which drives the input on the digital pot).
Maybe I used the wrong word, not my native language...
The cell phone likely has some places where air can get in and out, earpiece and mic at the very least. I meant that the whole circuit and all the ICs would be completely inside the plastic (though I had totally forgotten about them fancy comformal coatings), same idea as dipping the whole thing in expoxy.
It does become a problem if the heat can't get away, at the very least component lifetime would significantly shortened (though who cares whether the thingamagick dies in 10 vs 3 years if expected usable lifetime is 3 years anyways because the field moves so fast).
See my point above about heat dissipation, encasing everything in plastic that is very poor conductor of heat is not an option.
How will they achieve this without encasing all the components in the plastic, even if the board conductors were all encased (it's not like the anti-solder screen [green stuff on the board] could not be made waterproof and I think it already is) at least some of the components simply cannot be (due to heat dissipation problems). I have made completely waterproof circuit boards (simple PWM stuff, they don't generate enough heat for it to be an issue), the only connectors are rated for underwater and the board encased with epoxy, not really repairable though...
So anyways, since some of the components must be exposed they will have exposed connectors ergo water getting in will short-circuit it.
I don't know if it would work to use only such active components that have connector-bar on the underside and then just encase it up to the sides but this would add significant cost (connectors themselves, size of components -> board size...) and repair would still be out of the question.
Oh yes, Okami is great, I also liked GC Zelda (wind waker) cell-shaded graphics a lot (and couldn't understand why they drew so much flack from some circles [except maybe them being immature but that would be ad hominem])
Sorry, can't find the reference anymore (maybe the reg does not keep old archives on-line).
Anyways a few years back there was an article about a (botched) migration to all-Microsoft on Australian bank, sure enough project management was also to blame but converting mainframe software to run on windows servers is not the best of ideas if you plan to keep your availability and performance.
So the high-level manager responsible for dictating this "strategy" got sacked.
Thus this classic paraphrase of an even older classic quote hasn't held water for a long time now. Of course one could just say the "the exception confirms the rule", since these cases are rare.
To clarify the birthday problem is fundamental and it basically means that even in good algorithms one *on average* needs to check half of the possible key space to brute force the key.
In not-so-good algorithms (for example uneven distribution of keys) one can tune the search space and get away with checking much smaller amount of keys than half of the theoretical space.
And as stated earlier, cryptographers will consider an algo broken if there exist an attack that is better than pure brute force (need to check less than half of the keys), practical attacks are a wholly different matter.
And what comes to the MD5 debacle, it was known to be broken for ages and still was used for new certificates, that's just stupid. Granted SHA-1 is also broken, but for it there are no practical attacks, RIPEMD160 has no breaks yet but it seems it's not officially supported in SSL.
I'd guess the server only allows static delay or they simply don't know how to configure exponential backoff.
Either way it's not exactly smart to have it so high; what is the estimated cost of hacked account on the FTP ? Anyone who undestands security understands that it cannot be made perfect, thus the goals should be
1. Cost of security measures (direct and non-direct like loss of productivity) must not exceed cost (again direct and non-direct) of break
(exact balance of these costs is fuzzy)
2. Make breaking more expensive than what can by gained by exploiting the break.
>>[citation desperately needed]
>
>If Stephen Hawking says something about physics, do you require a citation from him? Nielson is recognized as one of the leading experts in his field.
>
But the "no increase in security" is statement in security and mr Nielsen is expert in *usability*.
(how's that for snarky ?:)
TFA is skimp on this but after bit of Googling around I understand a little more, see also http://en.wikipedia.org/wiki/Homomorphic_encryption.
The point being that those who provide the encrypted data must encrypt it in a special way to allow the homomorphic properties to be taken advantage of.
Can't remember offhand but check out "The Code Book" by Simon Singh it has a lot of really interesting crypto history.
Anyways back when it was invented (twice actually, first time by british military intelligence and kept secret so Rivest, Shamir and Adleman could invent it later) it required way too much resources to be usable for field agents/general use.
The downside to quantum encryption is that you have to have an uninterrupted fiber optic line from one point to the other. If, at any point, that line has to go through a switch of some sort, you now have a weak point in the encryption where someone can be listening in without you knowing.
It's not just a weak point in the "encryption" (we're talking about key-exchange, the encryption itself is done with traditional algorithms), but AFAIUnderstand this the switch by definition needs to observe the photons and thus mess with their state triggering exact same detectable issues as an eavesdropper would.
Now a point about traditional crypto algos: If your data is sufficiently small or your key-exchange can work fast enough you can always use OTP for encryption which means your weak point is in the random source used to generate the OTP (granted: good truly random source is likely to be included with any quantum key-exchange device since both ends need to choose their filter orientations randomly).
OTOH Rubberhose has interesting approach to the hidden volumes.
Short version: you cannot ever prove that you have provided passwords to *all* volumes, and of course they can never prove that you haven't. Which means that after giving up a few "throwaway" volume keys you can start screaming "there is no more" while they beat you with the proverbial rubber hose.
unless the hardware itself is secured and tamper-resistant enough (ie cost of successfull tampering is higher than value of data).
This has always been true.
The problem is getting away with the money, electronics transfers are easy to track and if $x/2 is large enough the red tape of tracking across borders is not wide enough (and if they say that this is used to fund terrorism even less so).
Getting large sums of cash out of just about any bank will flag you so transferring to an account in another country, going there to get cash and then depositing elsewhere is going to get you or someone working for you identified as the last known link in the chain and taken for questioning.
Getting cash in the first place is even more sure-fire way to eiher get caught or not get the money.
Actually there was a demonstrated attack (can't remember the URL now) on signing a PostScript document, attacker would make two documents with different content and add non-printing crap to the "innocent" file untill collision then have the innocent document signed and move the signature to the other document, granted this is very different from forging a log line
Of course one should choose some other hash function, SHA-1 has been broken and while there is no reason to panic yet, using SHA-1 for new applications would not be wise.
OTOH:
i _w ant_this_file.daily
http://user:password@lynx-dump.http-basic.auth/
is legitimate and often used, some warning dialog (that you can turn off if you wish) would be good idea in mainstream clients though.