57982973
submission
IamTheRealMike writes:
In recent months fake PGP keys have been found for at least two developers on well known crypto projects: Erinn Clark, a Tor developer and Gavin Andresen, the maintainer of Bitcoin. In both cases these PGP keys are used to sign the downloads for popular pieces of crypto software. PGP keys are supposed to be verified through the web of trust, but in practice it's very hard to find a trust path between two strangers on the internet: one reply to Erinn's mail stated that despite there being 30 signatures her key, he couldn't find any trust paths to her. It's also very unclear whether anyone would notice a key substitution attack like this. This leaves three questions: who is doing this, why, and what can be done about it? An obvious candidate would be intelligence agencies, who may be trying to serve certain people with backdoored binaries via their QUANTUMTHEORY man-in-the-middle system. As to what can be done about it, switching from PGP to X.509 code signing would be an obvious candidate. Both Mac and Windows support it, obtaining a forged certificate is much harder than simply uploading a fake PGP key, and whilst X.509 certs can be issued in secret until Google's Certificate Transparency system is fully deployed, finding one would be strong evidence that an issuing CA had been compromised: something that seems plausible but for which we currently lack any evidence. Additionally, bad certificates can be revoked when found whereas beyond making blog posts, not much can be done about the fake PGP keys.
50522659
submission
IamTheRealMike writes:
In the wake of Bruce Schneier's statements that he no longer trusts the constants selected for elliptic curve cryptography, people have started trying to reproduce the process that led to those constants being selected ... and found it cannot be done. As background, the most basic standard elliptic curves used for digital signatures and other cryptography are called the SEC random curves (SEC is "Standards for Efficient Cryptography"), a good example being secp256r1. The random numbers in these curve parameters were supposed to be selected via a "verifiably random" process (output of SHA1 on some seed), which is a reasonable way to obtain a nothing up my sleeve number if the input to the hash function is trustworthy, like a small counter or the digits of PI. Unfortunately it turns out the actual inputs used were opaque 256 bit numbers, chosen ad-hoc with no justifications provided. Worse, the curve parameters for SEC were generated by head of elliptic curve research at the NSA — opening the possibility that they were found via a brute force search for a publicly unknown class of weak curves. Although no attack against the selected values are currently known, it's common practice to never use unexplainable magic numbers in cryptography standards, especially when those numbers are being chosen by intelligence agencies. Now that the world received strong confirmation that the much more obscure and less widely used standard Dual_EC_DRBG was in fact an NSA undercover operation, NIST re-opened the confirmed-bad standards for public comment. Unless NIST/the NSA can explain why the random curve seed values are trustworthy, it might be time to re-evaluate all NIST based elliptic curve crypto in general.
19143054
submission
IamTheRealMike writes:
The BitCoin peer to peer currency briefly reached exchange parity with the US dollar today after a spike in demand for the coins pushed prices slightly above 1 USD:1 BTC. BitCoin was launched in early 2009, so in only two years this open source currency has gone from having no value at all to one with not only an open market of competing exchanges, but the ability to buy real goods and services like web hosting, gadgets, organic beauty products and even alpaca socks.
17852204
submission
5050955
submission
IamTheRealMike writes:
It's been a few months since we last checked in on how the BluRay group were doing in their fight against piracy, so it's time to see how it's going. At the time, a new generation of BD+ programs had stopped both SlySoft AnyDVD HD and the open source effort at Doom9. That was December 13th 2008. At the start of January, SlySoft released an update that could handle the new BD+ programs, meaning that BluRay discs were undecryptable for a period of about three months in total — the same length as SlySofts worst case scenario. The BD+ retaliation was swift but largely ineffective, consisting of a unique program for every BluRay master. Users had to upload log files for every new movie/region to SlySoft, who would then support that unique variant in their next update, usually released a few days later. Despite that, the open source effort never did manage to progress beyond the Winter 2008 programs and is currently stalled completely, thus SlySoft are the only group remaining. This situation remained for several months, but starting around the same time as Paramount joined Fox in licensing BD+ a new set of programs came out which have once again made BluRay discs unrippable. There are currently 19 movies that cannot be decrypted. It appears neither side is unable to decisively gain the upper hand, but one thing seems clear — only full time, for profit professionals are able to consistently beat BD+. Unless SlySoft or a licensed vendor release a BluRay player for Linux it appears the only way to watch BluRay movies on this platform will be to wait for them to become pirateable.
2229509
submission
IamTheRealMike writes:
A month on from the story that BD+ had been completely broken, it appears a new generation of BD+ programs has re-secured the system. A SlySoft developer now estimates February 2009 until support is available. There's a list of unrippable movies on the SlySoft forums, currently there are 16. Meanwhile, one of the open source VM developers seems to have given up on direct emulation attacks, and is now attempting to break the RSA algorithm itself. Back in March SlySoft confidently proclaimed BD+ was finished and said the worst case scenario was 3 months work: apparently they underestimated the BD+ developers.
