You are making very strong assumptions about your AES256 implementation (or what ever other block cipher).

On a technical note you assume that whoever coded the implementation of AES did not chose to make it so that it only decrypts a ciphertext with a valid password and otherwise returns "fail". This is trivial to implement: to encrypt m as 0000...000|m. To decrypt, first decrypt then check if the result has 0000...000 as a prefix. If not output "fail" otherwise output m. This this could well be considered a "useful" feature of the implementation as it avoids higher level applications using AES from having to deal with bad passwords.

More formally, from a crypto stand point you also make un-realisable assumptions. A block cipher is essentially pseudo-random permutation. You are suggesting that selecting a random PRP p1 from the AES family (i.e. a random password), computing it in the forwards direction to get p1(m)=c, then selecting another (arbitrary!, not random) PRP p2 from the family and then inverting it to get p2^-1(c) = m' would give you a uniformly distributed m' that is independent of m and p1. No way. Formally you are assuming AES is a family of (invertible) random oracles! But it's trivial to see that random oracles can not be implemented by any poly-time algorithm. So regardless of how it is implemented this can not possibly be more then a heuristic.

Conclusion: don't assume decrypting with a bad password gives a random output independent of the message in the ciphertext. This is an extra (and formally a false) assumption on your implementation!

Dude... seriously?

At least they SOMETHING to help the people in egypt. What do you want? a full scale google invasion?

And by the way a google employ (exec) was kidnapped by plain clothed security forces in cairo and is missing since several days. The arrest was caught on video. See around 1:11

Not quite so cushy after all.

Land lines that can call international numbers are not all that common in egypt and cost extra.

I was talking to a guy from telecomix on irc yesterday who was working on a pretty sweet project trying to get net and phones to people in egypt. Generally they seem to be organizing quite a few cool things. In this case the guy was gearing up to buy a bundle of phone lines (enough for about 2000) and hooking it up to a computer with SIP on the egypt side. The end goal was to setup what is essentially a new Dial-in ISP. But I didn't really have time/knowledge to understand the details. Anyway they're doing some pretty rad stuff so it's worth checking out.

Still, there really is only so much you can do given just a couple days notice and a country in the middest of an information lockdown (not to mention a general revolution).

that would make DDOS attacks a whole lot more dangerous now wouldn't it...

Noor is the ISP for the stock exchange as well as for many major banks. That would suggest quite a few reasons as to why they were not shut down with the rest...

Not everything is down. The IP block of the The Ministory of Communication is still up.

I've been following the situation quite closely now on twitter for several days and a surprising number of tweets coming from inside egypt are actually in english. Search for hashtags #jan25 and #feb1 to see what i mean. Even now with all ISPs down people are still finding ways round the blockade and tweeting. (Of course many of those tweets are not actually from inside egypt especially now. But still over the last few days many were.)

Also from the google blog post announcing the new service: "People can listen to the messages by dialing the same phone numbers or going to twitter.com/speak2tweet." So they do seem to provide a way to get information and not just give. Haven't tested it myself though.

NP-hardness tells us something about worst case complexity. for crypto we care about average case complexity. a problem must be hard on average not just in the worst case.

Here's your evidence:

Given a public key for an asymetric cryptosystem (say a modulas n for RSA) it is easy to verify (i.e. in NP) that a candidate secret key (say primes p and q in the RSA case) match the public key. Paraphrasing heavily now: If P == NP then anything that is easy to verify if polytime is also easy to solve in polytime. In our case that means if i give you a public key you can now FIND a matching secret key in polytime. I.e. if i give you n which is an RSA public key you can factor it into primes p and q. But if you can find the secret key for any public key algorithm (including RSA) then no such algorithm can be a "secure" cryptosystem.

Heading off some misunderstanding: We do not know how to base security ONLY on P != NP. In fact that is considered one of the largest open problems in modern theory of crypto. While I just argued that P!=NP is a _necessary_ condition for all asymmetric (and most symmetric) crypto to be secure it is not known to be _sufficient_.

We're getting closer with some of the recent advances in Lattice based crypto but were are definitely not their yet. For the theory people out there: A fundamental problem here is that NP tells us something about worst case hardness but for crypto we need average case hardness (i.e. for a random secret key and random coins for the ciphertext). Bridging this gap is highly non-trivial. Recent work in lattices has shown such connections and how to use it for certain problems. However the choice of parameters we use for the resulting cryptosystems are not known to result in NP-hard underlying problems.

I'm pretty sure factoring and discrete log are not known to be equivalent. This would be a huge result in theory of crypto if it could be shown.

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.)