Slashdot Mirror
Crack the Code and Win a Million Bucks
JS_RIDDLER noted a Toronto Star article about a sort of contest to
crack some encryption and win a million bucks. The article is a bit fluffy, but it getst the point across... we wasted all those RC5 keys ;)
... they should have left an option open for people finding holes in the ACTUAL implementation... Now only mathematicians stand a chance - go, go, go, you few good number theoretisists not employed by the NSA! =-= insert favorite conspiricy theory here =-=
They are using keys that sound big 168 bits, 256 bits, etc. But those aren't really that big, only 21 bytes and 32 bytes respectively. These sentences are longer than those keys.
Then I note that UNIX limits passwords to 8 bytes. A measly 64 bits.
I don't think I can sleep well knowing that all that stands between my data and some hacker is such a small string.
I have been pwned because my
...is that it uses much smaller keys with the same level of encryption. This makes it useful for handhelds and phones, and network devices. If you've never heard of this before, chances are you're already using it, too, as this is prevalent already in many of the aforementioned devices.
libertarianswag.com
I think the company who came up (or rather markets) ECC [eliptic curce cryptography] should be careful about saying that ECC is more secure than RSA. RSA has stood up to A LOT of cryptanalysis, simply because of it's age. ECC might have bad keys or something else we don't know about simply because we have not have time to try all attacks yet. Who knows, tomorrow someone may find a trivial algorithm for taking the discrete logarithm on an EC (rendering ECC useless). Then again, someone may find a way of doing a simple discrete logarithm (rendering RSA useless). Both are highly unlikely, but hey -- stranger things have happened.
Basically, take a company's claim with a grain of salt. Right now I'll keep my data encrypted with something more tested (3DES anyone?).
My other car is first.
...to crack it, but as of how long it will take them. Information that is worth a lot today may be worthless tomorrow, and by next week it'll be history. So the question isn't about making a perfect encoding (we allready have one, namely 'one time pads'), but finding the best encoding for the application. Also bear in mind the rule of thumb that states that the thoughter the code, the more difficult (think CPU-cycles and batterydrain) it is to encode it in the first place. Off course, just how strong thats strong enought will change as the tools for encryption, decryption and codebreeaking gets stronger.
Remember folks, an encrypted message don't have to be unbreakable, it just has to be hard enought to break. One rule of thumb is that it should cost more to break than the one breaking it will earn on doing so.
Besides, one can learn a lot about whats going on even if you can break the code. Where does the signal originates? Where is it heading. Does it occour on a frequent basis? What is the matter of transmitting? The more you learn about the message, the more you learn about the reason it's beeing sendt - even if you don't know what it says. THEN you can often start using social enginering to gain access to the key, or better yet, to the unencrypted message.
Everything in the world is controlled by a small, evil group to which, unfortunately, no one you know belongs.
I went over to their website and parused around... Seems they did the security to XM Radio, http://www.certicom.com/download/aid-78/success_XM Radio.pdf) which humors me because XM Radio was hacked about 2 months after it went live.. All you need is a part from an old Dish Network reciever and a soldier iron.