Indeed that would be the case. The data is not actually encrypted as claimed by the group, but rather just encoded. In other words there is no secret password required for recovering the data. Instead all you need is to know the scheme used to encode/decode the data.

By the same token ASCII would be an "encryption" of Roman alphabet (amoungst other symbols). Clearly that's just BS.

Indeed the post is one of the few big news sites i could find that even mentions the story. And as pointed out in the parent post they quote all kinds of denials.

Reuters and BBC for example do not even mention the embargo one way or another.

Does anyone involved have any evidence one way or another? some one working for a japanese company expecting deliveries for example? It would be nice to get some clarity on this...

I guess the idea is to run adobe PDF in it's own VM that has minimal permissions. Then when it is infected the virus can't access anything the VM isn't allowd to. (grsec let's you do something like that with the ACLs, roles and users.) For example if you do updates manually then you can restrict the VM of adobe Reader to not have net access. so the virus couldn't contact the outside world either. it's all a question of how much you're willing to compartmentalize your system. the more hassel you are willing to deal with the more secure you can get it (up to a point). This also addresses another comment in this discussion that claims that shoddy coding is not addressed by this fix. the idea of this and similar OSs is to limit the damage after said shoddy coding has been exploited. Not to fix the actual exploitation of that coding.

What i don't get is how this systems is really different from the ACL system of other secure OSs such as grsec... i mean on a high level it seems to be about the same thing. each is a different solution to the same problem of how to compartmentalize your system. in this light what advantage does the new VM based system have over grsec? compartmentalization at a lower level maybe? i.e. even internal to the kernel etc. I don't know enough about how grsec is implemented to know if that is really a difference...

i think you're mixing up key length for symmetric ciphers (like AES, 3DES, Blowfish, etc.) which are generally quite short like 128 or 256 bits and key lengths for _asymetric_ cryptosystems which vary much more in length and in the case of RSA are somewhere closer to 2048 and 4096.

The reason is that for symmetric ciphers we _believe_ to be secure the best an attacker can do is brute force the key space. so that means brute forcing 2^128 or 2^256 possible keys. That's a hell of a lot of work. with current technology probably infeasible.

but for asymmetric schemes it's not as straightforward. To get a glimpse of why this is think about RSA keys. The public key is an exponent e and an integer n which is the product of two large primes. Now not every string of 4096 is actually represents such a pair number of numbers. (in particular not every bit-string is the product of two primes). so not every string of that length is a valid key. so brute forcing the key space doesn't mean trying every possible string of that length. just the ones which are the product of two primes which is a fair bit less.

Another reason for comparatively longer keys is this. In generally, for many asymmetric cryptosystems there are various attacks known which are still super-polynomial (i.e. inefficient) but are never the less sub-exponential which is what a brute force key search would be. so you have to adjust your key length to reflect these faster attacks even if brute forcing wouldn't be feasible even for shorter keys. (i think some examples of such attacks for factoring (which would break RSA) are the Pollard-Rho method, varients of Quadratic Sieve algorithm, and the Eleptic Curve method.)

Improvments to Craig's original work are already starting to come out. Smart and Vercauteren use integer arithmetic to obtain a more efficient scheme (though still not widly practical yet). Dijk, Gentry, Halevi and Vaikuntanathan show an even simpler (though not more efficient) scheme using integer arithmetics. In fact it's probably a good first paper to read for cryptographers interested in the area.

In light of these developments hardly a year since craig first released his results i see reason to hope for more improvments also towards efficiency (and basing the security on different and more common assumptions).

never the less for cloud computing applications where resource usage is carefully counted out and billed its hard to imagen such encryption technology being for a long time to come. neiche markets and applications could be another matter. for example something like a freenets/cloud where you can securely (privatly and correctly) farm out computation to be accessed from any client device with your key (for a comparable hit to performance). still, like freenet today the extent of the performance hit will most likely force it to remain generally unused for quite a while still.

That's a pretty common myth.

It might hold for most symmetric key cryptography algorithms (such as AES, SHA, MD5, DES, etc) however there is a whole other branch of (admitidely mainly theoretical) cryptography which relies on provable security. I.e. formal reductions showing that breaking security of the scheme is at least as hard as solving some difficult underlying problem. For such schemes it's a lot more plausable that there may simply not be a poly-time algorithm which solves them. (Take the short vector problem of lattice based crypto for example. To date we don't even have a _quantum_ algorithm that solves it efficiently let alone a classical one. Yet there are schemes that are at least as hard to break as that problem is difficult to solve.)

And of course then there is another branch of cryptography which considers information theoretic security. These are provably _unconditionally_ secure. (The most common example being the "one time pad".) For these algorithms, protocols, and applications as long as the under lying model is a good model of the real world there is simply no way to break security regardless of computing technology and future developments in algorithms.

So no. Crypto is not just broken. Quite a lot of modern crypto is actually pretty secure. (Now whether it's practically efficient is a whole other new ball game of course, but then that wasn't the claim...)

At least as far as the crypto is concerned the original arxiv file is basically a fake.

Choice example quote:

Little information needed to be communicated through a secure channel (only the keys). The key size is proportional to the size of the plaintext with a small ratio.

If key size is already proportional to ciphertext size then why not simply do OTP. That already gives provable information theoretic security. Then you don't need any extra privacy provided by the "DNA Encryption". All you need to do is transmit the ciphertext. The proposed scheme is at best a steganographic technique. Calling it in encryption is down right false.

The author basically proposes the following code. Write down your message as a bit string. Translate the bit string from binary to base 4. (interpret it as DNA). Remove random chunks at random positions from it (i.e. the introns), and express the remaining DNA it as a protein. The encryption "key" are the introns and the position of the introns.

Sounds pretty much like BS to me.