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.
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.
Most people who do anything are mediocre. Otherwise, mediocre would be redefined. It's like saying, half the people in the class scored below average. The fact that half the people scored below some value determines what the value of average is.
you are mixing up "average" with "median". say there is a class of ten students taking a test. one gets a 100 and the other 9 get a 0%. the average is 10%. but 90% of the students got less then the average.
actually thats not completely true. in the security world he might be highly regarded but in the crypto world things are... different. look at a list of his publications. Most all are at security conferences. For that matter since 2005 he has published one paper. He has only ever published 2 papers at Crypto, 1 at Eurocrypt and none at TCC. (These being the most selective conferences in the crypto community.) Nor does he have any papers at PKC, CHES, RSA, SCC, Asiacrypt, CSN, and only one paper at Fincial Cryptography which are some second and third tier conferences.
The main exception are his FSE (fast software encryption) papers but here too it's since 2000 he's only produced 1 paper and that had 6 authors. However before that (in the 90s) he did have a string of relatively interesting papers related to cryptanalysis mainly together with John Kelsey who is a much more prolific cryptanalyst even in recent years. For example he has 5 papers in Eurocrypt and Crypto. As a measure of FSE vs. Crypto also for the field of cryptanalysis, the major MD4, MD5, SHA-0 and SHA-1 breaks were all published at Crypto.
Basically what i'm saying is that he is great in security and even respectable in the most practical corner of crypto. But there are many many people out there who have a much more impressive track record as far as pure crypto is concerned.
I guess the best testament to how seriously some people out there take him would be this collection of useful facts.
The original paper has a comment that upon activation the keys will be automatically burnt permanently into the chip in an Electronic Fuse Unit to avoid multiple activations.
However there is another problem with this. The whole scheme relies heavily on a good supply of randomness. But obviously one can not rely on the actual fabricator to supply this randomness since they are they adversary in this setting. Thus the only solution seems to be to supply each and every chip with it's own true random number generator. (Again a PRNG is not good enough for this application since even these need to get a truly random seed from somewhere.) I see two problems with this assumption. First adding a TRNG to each and every chip will increase there costs directly proportional to it's relative security. A second more significant problem is that this provides a much easier avenue of attack then removing the entire security mechanism from the blueprint. Namely all that is requires is to "break" the TRNG. For example it could be shorted to always produce the same sequence. I am sure that this would be significantly easier then removing the entire EPIC circuitry.
There are also problems with how the cryptographic tools are used. The paper states that the common key (CK) which unlocks _all_ chips for a given blueprint _regardless of their randomness_ is the be signed by the IP holder and then encrypted with the public key of each chip instance. But then nothing stops a rouge manufacturer from generating their own key pair, sending the public key to the IP holder, and decrypting the response with the private key. This would give the the CK signed under the IP holders public key which they could use to activate any new chip from that blueprint!!
Luckily this bug has an easy fix. Reverse the order of signature and encryption. That is the IP holder should sign the cipher text not the plain text.
This is not the first use of multi-party computation. MPC is probably the most advanced cryptographic tool theoretical crypto has produced in the last 35 years. (The strongest flavour being Universally Composable MPC). Also, though the intuitive concept of secure MPC was introduced by Yao the later results of Goldreich, Micali and Wigderson in their 1986 paper How to Play Any Mental Game is the one upon which modern MPC is based and the result which is usually cited in cryptographic literature. (My guess is the wired article author got the bit about Yao from wikipedia.) It is in this paper that the security requirements of such a protocol are first formally described using what is now called the ideal/real paradigm. Essentially a secure protocol computing some joint functionality of all players inputs should be as secure as if there where a totally honest trusted third party who would gather their input, compute the function and privately hand the outputs back to all players. (This paradigm is probably at least as important a contribution to modern crypto as the actual MPC protocol they presented in the paper.)
The problem with MPC protocols is that since they are so very general and powerful they tend to also be horribly inefficient (though polynomially bounded (i.e. in P). Never the less the constant are often horrible and could require on the order of n^2 rounds of communication. Another hurdle in their wider adoption in the field of security is that they represent a significantly more complicated concept then say encryption or a hash function and so tend to be a difficult sell to non-cryptographers.
However at least one company, Cryptomathics of Aarhus, Denmark are working on an implementation of MPC. The main client being the danish government which wants to use the product to setup an online market through which local farmers can to sell there goods. The idea being that by using an MPC protocol to do this rather then some central (government run) server no body needs to trust anyone else, not even the government; just their own implementation of the software on their computers. As long as that is correct and uncorrputed they are guarenteed all the security they could hope for.
Of course there is always the argument that you might well be better off trusting the government to host the entire show then your own computer, but on the other hand even IF the government runs some online auction server, you still need to connect to that remote system from your own computer. So a secure server is still not going to help you protect yourself from local corruptions. At least now that is the ONLY thing left to worry about.
Using AES alone is definitely no guarantee of having established a secure communication channel. An at least equally important question is how key's are established and distributed. You did not mention any public key cryptography. AES is a symmetric key algorithm so how do two clients who've never talked with each other set up there first secure connection? Further AES is an encryption algorithm so it proves secrecy, but not automatically provide authentication. Especially with a known protocol this can lead to surprising attacks. Thus the mode of operation in which AES is employed is also quite important. Even how IV's are chosen are important.
Skype might have solved some or even all of these problems. But the point is that simply stating that AES (and RC4) are used (even perfect implementations there-of) does not guarantee any kind of security at all. these things are far more subtle then that.
besides the moment an attacker (in this case the bavarian police) gets access to and end point (i.e. the actual machine which skype is running on) the whole thing is just B.S. anyway. i mean NO system in the world is secure under such an adversarial model... not unless you have some crypto chip installed with secret keys on it or something like that. (think TCPM).
Here are the results of Transparency International's survey.
Globally, yes the US does seem to be doing quite well. Compared to other developed/western nations the pictures not quite so rosy. They seem to be closer to the mean then the min...
Of course this is but one survey and only of "perceived" corruption. But at least it's better then no references...
AT&T has this data already. But apple doesn't have to. Apple getting this data would be like Nokia or Ericsson rather the t-mobile keeping track of when, how, or where ur phone is being used.
This also refutes some claims made in previous posts that this is a non-issue since our phone providers keep track of this stuff anyway. The analogy that land line companies having this data is a bad one. Apple is to your land line phone MAKER not PROVIDER.
So yes, assuming that the IMEI really IS sent to Apple (which wasn't exactly verified by the TFA's author) this can be considered a privacy issue beyond the usual. (Releasing ANY data is a privacy issue to whomever. Just sometimes they are unavoidable or useful enough to out weigh the potential problems. Not this case though.)
Personally I don't see it as being as trivial as some posters have made it out to be either. Even assuming the IMEI is encrypted when sent out (with reasonable authentication and privacy unlike say GSM or WEP) it is always a bad idea to be releasing such critical information to a third party. In particular a third party which happens to be a large coorporation which is (understandably) motivated by profit and self interest.
What can be tracked with your IMEI? Your IMEI is a unique identifier for your phone. Thus if it can be correlated with location, time or any other data this is essentially YOUR private information. I think no one needs a picture drawn for them of what's wrong with Apple correlating IMEI with sock data queries or (to a lesser degree) weather queries. But even just allowing Apple to correlate with time (i.e. when your phone was on and when not) is already more then Apple should know. The point is the moment we're talking about _unique_ numbers being reported somewhere bell's should be ringing.
Since announcing your IMEI to Apple is not vital to intended functionality of the iPhone I think the "feature" was a... mistake, and should be disabled (by Apple in an ideal world).
Open source alone is not enough. In fact these algorithms ARE open source. There even public domain standards!
Crypto is a special case. While it's true that "open source" cryptographic algorithms/protocols tend to be far safer choices then proprietary/secret/home-brew algorithm the problem is that correctness of a cryptographic algorithm is a far stronger notion to achieve and verify then for a normal program. For a normal program "correct" implies producing the right out put. In a cryptographic setting we want the the "correct" output which must be "secure". Precisely understanding the meaning of "secure" for a given app. and context is a central concern of cryptographers.
What is needed for crypto is the next step beyond open source, namely open process. That is along with an algorithm the NSA (or NIST or IBM or whoever) should be publishing a complete security definition, analysis and reasoning behind the design choices. (See The Making of Rijndael for example.)
If the NSA had provided ANSI, NIST and the public with such documentation then the problems pointed out by Shumow and Ferguson would not exist. The reasoning behind the choice of all constants would be clear to all.
On a realistic note it's not exactly likely that the an organisation like the NSA would ever do such a thing. Take the case of the DES algorithm developed by IBM with help from the NSA. Only a decade later later when Eli Biham and Adi Shamir published their work on Differential Cryptanalysis did the reasons for the choices of constants in DES become clearer. However at the time of DES's creation this (very powerful) cryptanalytic method was not known to the public. Thus by demanding open process the NSA would effectively have been required to release what was probably one of their most guarded technological advancements.
Thus since it can not be expected that the NSA adhere to open process development I think our best bet is to simply go with another algorithm which does. Like rijndael for example...
Demanding that a country live up to the agreements it signed is not "overriding its sovereignity".
not when those laws cause the "sovereign" country to violate (trade) agreements they have signed with other countries. Logically in this case either the trade agreement or the law must change (or go defunct by default). Notice BOTH sets of rules were agreed upon by the "sovereign" nation. It is the WTO's job (to which the sovereign nation has agreed and submitted it's self) to make sure that it is either the internal laws that are in violation which are changed or that the country on the other end of the violated trade deal(s) is equably reinstituted for what it has lost due to this contradiction.
and by the way, the US never had a problem with this when it was the one filing the complaint trying to get some other country to change it's "domestic laws". (See the case concerning Chinese monitory valuation for example or the case concerning the EU's moratorium on GMO foods...)
There seems to me some (a lot?) of FUD mixed up in this article. (surprise surprise...)
It starts out with the fact that public key encryption relies on the existence of one trapdoor one-way functions. Now in practice we mainly instantiate these functions with the RSA function (f_e(x):=x^e mod n with trapdoor p,q such that pq=n). But there is no reason to believe this is the only possible example of trapdoor OWF! Admitedly in the 80s when this concept was first being explored there were quite a few failures when trying to base implementations on NP-Complete and/or NP-Hard problems (think knapsack for example). But since we already had RSA with all it's nice properties (efficiency, elegance and simplicity) the research community was not overly motivated to find others.
There have been and to this day still are other lines of research. Take Ajtai and Dwork's work in the direction of basing PKE on worst-case hardness of the shortest vector problem (SVP) or Micciancio's work on generalizing the knapsack problem such that average-case hardness of approximating the answer can be reduced to worst-case hardness of certain lattice based problems.
Another general direction has been to come up with groups and fields over which solving the DLP is difficult. (For example torus-based crypto and generalized Jacobian groups). AFAIK for most of these candidates there are no (known efficient) reductions from the DLP problem over Z_p or elliptic curves to the DLP in these new groups. Thus it is not immediately clear how or if Schorr's algorithm would break such systems.
In any case there is reason to believe that there can not be (or that we can't find) good candidates for trapdoor OWFs in the quantum computational model. After all there is such a thing as Quantum P and Quantum NP. Though the inequality of these set's of problems doesn't directly imply the existence of quantum trapdoor OWFs it is a good indication there of.
So basically the message is : Relax! The PKE world is by no means on the brink of an apocalypse. At most (and best in my opinion) we're in for a bout of some serious foundations research. to me that just sounds like more funding for applied mathematicians and complexity theorists from various corners and a WHOLE bunch of new candidates and interesting results.:-) i'm down with that.
a random number generator (i.e. the random variable describing the output of the generator) does not have to be distributed with a uniform distribution in order to be random. It just implies that it is not deterministic. that is the entropy of the random variable is greater then 0. further randomness is really only well defined in relation to a view (information set). what appears random to you may not be random to me. (technically the entropy of a random variable may be non-zero on it's own however conditioned on some other information it may be 0).
take a (probabilistic) turing machine which has an extra input tape with a sequence of uniformly and independently distributed bits on it (i.e. it's "random tape"). if the machine outputs this tape and you don't see the tape then the turing machine outputs a random sequence from your point of view. that is the random variable describing the next bit of output condition on all previously observered output has (min-)entropy 1. however if your are privy to the random tape of the machine then you can suddenly predict the output of the machine with probability 1. i.e. the entropy of the output is 0 and so the output of the machine is no longer random in any sense.
another definition of randomness put forward by kolmogorov is that a random random string is one that can not be compressed. this relates closely to the algorithmic definition of randomness which states that a string is random iff it is shorter then any program which has the string as output.
I think that's over simplifying things a bit. It's about changing the balance of power (at least in theory). If both you and your enemy have the capability to attack each other there is a balance; a detent. However if then your enemy develops and puts in place means to block your attack, even if the development is purely "defensive" the balance has now been scewed and the next step in the arms race has begun. This is an extreme example but imagen this on a level of "can block us more then we can block him" and you get to what Putin is talking about.
Note i'm talking theory here and not making any argument about weather this really applies to the current situation. After all, the US claims the shield is against single rogue missiles not huge swarms like Russia commands. But my honest opinion is that all of this are political, economic and strategic games and what the public gets to see and read is just the very tip of the iceberg, making the judgment of a meaning and intent behind a leaders statement a very tricky thing at best.
This seems to be a deffinition problem. What is not possible (as the wiki article points out) is a man in the middle _where A and B end up with the same key_. However if we assume that Mallory is also between A and B for all conventional communication (i.e. not the quantum chanel) then things are different. A and M agree on a key, and M and B agree on a different key. then when A and B use normal channels to acertain if they can understand each other (implying they have agreed on the same key.) now Mallory can act as a go between decrypting A's messages and rencrypting them to B. So A and B believe they can understand each other and M is sitting happily in the middle.
this is ofcourse a more general problem though. namely that all one ever can verify in the digital world (quantum or not) is that one is communicating with a key (be it a OTP, pk/sk pair, symetric key or whatever) but NOT with an entity. i.e. you are not sending a message to Alice but to alice's key. who knows who actually owns alice's key. maybe not alice at all. as it so happens, solving this problem was the main motivation behind the invention of PKI and Certifactes. These attempt to establish a chain of trust linking a key to an entity. pure quantum key exchange algorithms do nothing to deal with this problem though and thus suffer from the same type of man in the middle as an anonymous deffie hellman does.
If i'm not mistaken then that is exactly how one uses entangled particles (photons in your example). the idea is that when two particles are entangled then if alice reads the spin of her particle she will get the same reading as bob (provided they use the same base to messure the spin). The problem with transmitting information (and the reason why this doesnt break the "nothing goes faster then the speed of light" rule) is that the entangled pair can not be created to read to a predefined spin (= bit value). Thus the result is a correlated but random result. ideal for setting up a OTP but no good for actual information exchange.
on the other hand i'm no quantum computer scientist nor a physicist so all the usual disclaimers apply here.
Nor is the CIA really into cryptography. Yes they need a few cryptographers here and there but when I went to them, looking for a job (in the field of cryptography research) i was politly asked to go see their colegues over at the (very non-discript and unmarked) NSA booth over in the corner.
The first time round when approaching the NSA booth I stupidly enough kept my (normal) british accent and was almost imediatly told to go see the GCHQ. (i.e. "get lost kid") So I walked off again and only came back when there was a new representative sitting behind the desk. This time I didnt bother mentioning my nationality and put on a nice generic american accent letting them assume my orginis were more... kosher.:-)
Of course that interview went quite differently... "Oh yes! Well you've come to the right place then. We have a great program for you begining with several years of training where we rotate you through the variouse subfields teaching you all the newest techniques and methods you'll never hear about in academic circles... blablabla.... Just please sign here."
somehow i just couldnt help but thinking of Faust... i wonder why...
i got what i wanted though. a cool business card from the NSA math highering department and some email address printed on an old dotmatrix, cutout and stuck on the back. cloack n dagger n all that...
Anyway if you really want do crypto work for the US gov. (or DOD in particular) then never mind the CIA. The NSA or the SigInt guys are who you really want to talk to.
AFAIK of course. I mean how would a mere civilian and a FORIEGNER at that have any clue about whats going on over there...:-)
no current political influence? did u know that north korea has on several ocasions already requested a TLD for it's self just like almost any other country in this world but has been repeatedly denied? sounds a bit fishy to me u.
thing is, it's not quite like a more "user friendly" car. the conversation started by talking about wether TFA was good for Linux's public image or not although it didnt mention GNU. we're talking about if the acronyme GNU is important when trying to win the masses over.
the problem with the analogy is that there are far FAR more people in the world who can drive without transmition (and even may choose the cheapest most bearbone version of a car) then there are "average people" who can use and want Linux without X.
so the market for Cars without X-friendliness is proportional to the total car market, is way bigger then the proportion of GNU/Linux to the GNU/Linux/X in the market of average people.
thus for cars its fine to have models with no X but the market is to small for Linux without X. I geuss if we dont bother with X then why bother with GNU.
both or neither. thats all i'm saying. (better neither IMHO. Linux is enough)
Slashdot Mirror
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...)
Choice example quote:
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.
you are mixing up "average" with "median". say there is a class of ten students taking a test. one gets a 100 and the other 9 get a 0%. the average is 10%. but 90% of the students got less then the average.
actually thats not completely true. in the security world he might be highly regarded but in the crypto world things are... different. look at a list of his publications. Most all are at security conferences. For that matter since 2005 he has published one paper. He has only ever published 2 papers at Crypto, 1 at Eurocrypt and none at TCC. (These being the most selective conferences in the crypto community.) Nor does he have any papers at PKC, CHES, RSA, SCC, Asiacrypt, CSN, and only one paper at Fincial Cryptography which are some second and third tier conferences.
The main exception are his FSE (fast software encryption) papers but here too it's since 2000 he's only produced 1 paper and that had 6 authors. However before that (in the 90s) he did have a string of relatively interesting papers related to cryptanalysis mainly together with John Kelsey who is a much more prolific cryptanalyst even in recent years. For example he has 5 papers in Eurocrypt and Crypto. As a measure of FSE vs. Crypto also for the field of cryptanalysis, the major MD4, MD5, SHA-0 and SHA-1 breaks were all published at Crypto.
Basically what i'm saying is that he is great in security and even respectable in the most practical corner of crypto. But there are many many people out there who have a much more impressive track record as far as pure crypto is concerned.
I guess the best testament to how seriously some people out there take him would be this collection of useful facts.
The original paper has a comment that upon activation the keys will be automatically burnt permanently into the chip in an Electronic Fuse Unit to avoid multiple activations.
However there is another problem with this. The whole scheme relies heavily on a good supply of randomness. But obviously one can not rely on the actual fabricator to supply this randomness since they are they adversary in this setting. Thus the only solution seems to be to supply each and every chip with it's own true random number generator. (Again a PRNG is not good enough for this application since even these need to get a truly random seed from somewhere.) I see two problems with this assumption. First adding a TRNG to each and every chip will increase there costs directly proportional to it's relative security. A second more significant problem is that this provides a much easier avenue of attack then removing the entire security mechanism from the blueprint. Namely all that is requires is to "break" the TRNG. For example it could be shorted to always produce the same sequence. I am sure that this would be significantly easier then removing the entire EPIC circuitry.
There are also problems with how the cryptographic tools are used. The paper states that the common key (CK) which unlocks _all_ chips for a given blueprint _regardless of their randomness_ is the be signed by the IP holder and then encrypted with the public key of each chip instance. But then nothing stops a rouge manufacturer from generating their own key pair, sending the public key to the IP holder, and decrypting the response with the private key. This would give the the CK signed under the IP holders public key which they could use to activate any new chip from that blueprint!!
Luckily this bug has an easy fix. Reverse the order of signature and encryption. That is the IP holder should sign the cipher text not the plain text.
This is not the first use of multi-party computation. MPC is probably the most advanced cryptographic tool theoretical crypto has produced in the last 35 years. (The strongest flavour being Universally Composable MPC). Also, though the intuitive concept of secure MPC was introduced by Yao the later results of Goldreich, Micali and Wigderson in their 1986 paper How to Play Any Mental Game is the one upon which modern MPC is based and the result which is usually cited in cryptographic literature. (My guess is the wired article author got the bit about Yao from wikipedia.) It is in this paper that the security requirements of such a protocol are first formally described using what is now called the ideal/real paradigm. Essentially a secure protocol computing some joint functionality of all players inputs should be as secure as if there where a totally honest trusted third party who would gather their input, compute the function and privately hand the outputs back to all players. (This paradigm is probably at least as important a contribution to modern crypto as the actual MPC protocol they presented in the paper.)
The problem with MPC protocols is that since they are so very general and powerful they tend to also be horribly inefficient (though polynomially bounded (i.e. in P). Never the less the constant are often horrible and could require on the order of n^2 rounds of communication. Another hurdle in their wider adoption in the field of security is that they represent a significantly more complicated concept then say encryption or a hash function and so tend to be a difficult sell to non-cryptographers.
However at least one company, Cryptomathics of Aarhus, Denmark are working on an implementation of MPC. The main client being the danish government which wants to use the product to setup an online market through which local farmers can to sell there goods. The idea being that by using an MPC protocol to do this rather then some central (government run) server no body needs to trust anyone else, not even the government; just their own implementation of the software on their computers. As long as that is correct and uncorrputed they are guarenteed all the security they could hope for.
Of course there is always the argument that you might well be better off trusting the government to host the entire show then your own computer, but on the other hand even IF the government runs some online auction server, you still need to connect to that remote system from your own computer. So a secure server is still not going to help you protect yourself from local corruptions. At least now that is the ONLY thing left to worry about.
Using AES alone is definitely no guarantee of having established a secure communication channel. An at least equally important question is how key's are established and distributed. You did not mention any public key cryptography. AES is a symmetric key algorithm so how do two clients who've never talked with each other set up there first secure connection? Further AES is an encryption algorithm so it proves secrecy, but not automatically provide authentication. Especially with a known protocol this can lead to surprising attacks. Thus the mode of operation in which AES is employed is also quite important. Even how IV's are chosen are important.
Skype might have solved some or even all of these problems. But the point is that simply stating that AES (and RC4) are used (even perfect implementations there-of) does not guarantee any kind of security at all. these things are far more subtle then that.
besides the moment an attacker (in this case the bavarian police) gets access to and end point (i.e. the actual machine which skype is running on) the whole thing is just B.S. anyway. i mean NO system in the world is secure under such an adversarial model... not unless you have some crypto chip installed with secret keys on it or something like that. (think TCPM).
Here are the results of Transparency International's survey. Globally, yes the US does seem to be doing quite well. Compared to other developed/western nations the pictures not quite so rosy. They seem to be closer to the mean then the min... Of course this is but one survey and only of "perceived" corruption. But at least it's better then no references...
AT&T has this data already. But apple doesn't have to. Apple getting this data would be like Nokia or Ericsson rather the t-mobile keeping track of when, how, or where ur phone is being used.
This also refutes some claims made in previous posts that this is a non-issue since our phone providers keep track of this stuff anyway. The analogy that land line companies having this data is a bad one. Apple is to your land line phone MAKER not PROVIDER.
So yes, assuming that the IMEI really IS sent to Apple (which wasn't exactly verified by the TFA's author) this can be considered a privacy issue beyond the usual. (Releasing ANY data is a privacy issue to whomever. Just sometimes they are unavoidable or useful enough to out weigh the potential problems. Not this case though.)
Personally I don't see it as being as trivial as some posters have made it out to be either. Even assuming the IMEI is encrypted when sent out (with reasonable authentication and privacy unlike say GSM or WEP) it is always a bad idea to be releasing such critical information to a third party. In particular a third party which happens to be a large coorporation which is (understandably) motivated by profit and self interest.
What can be tracked with your IMEI? Your IMEI is a unique identifier for your phone. Thus if it can be correlated with location, time or any other data this is essentially YOUR private information. I think no one needs a picture drawn for them of what's wrong with Apple correlating IMEI with sock data queries or (to a lesser degree) weather queries. But even just allowing Apple to correlate with time (i.e. when your phone was on and when not) is already more then Apple should know. The point is the moment we're talking about _unique_ numbers being reported somewhere bell's should be ringing.
Since announcing your IMEI to Apple is not vital to intended functionality of the iPhone I think the "feature" was a... mistake, and should be disabled (by Apple in an ideal world).
Open source alone is not enough. In fact these algorithms ARE open source. There even public domain standards!
Crypto is a special case. While it's true that "open source" cryptographic algorithms/protocols tend to be far safer choices then proprietary/secret/home-brew algorithm the problem is that correctness of a cryptographic algorithm is a far stronger notion to achieve and verify then for a normal program. For a normal program "correct" implies producing the right out put. In a cryptographic setting we want the the "correct" output which must be "secure". Precisely understanding the meaning of "secure" for a given app. and context is a central concern of cryptographers.
What is needed for crypto is the next step beyond open source, namely open process. That is along with an algorithm the NSA (or NIST or IBM or whoever) should be publishing a complete security definition, analysis and reasoning behind the design choices. (See The Making of Rijndael for example.)
If the NSA had provided ANSI, NIST and the public with such documentation then the problems pointed out by Shumow and Ferguson would not exist. The reasoning behind the choice of all constants would be clear to all.
On a realistic note it's not exactly likely that the an organisation like the NSA would ever do such a thing. Take the case of the DES algorithm developed by IBM with help from the NSA. Only a decade later later when Eli Biham and Adi Shamir published their work on Differential Cryptanalysis did the reasons for the choices of constants in DES become clearer. However at the time of DES's creation this (very powerful) cryptanalytic method was not known to the public. Thus by demanding open process the NSA would effectively have been required to release what was probably one of their most guarded technological advancements.
Thus since it can not be expected that the NSA adhere to open process development I think our best bet is to simply go with another algorithm which does. Like rijndael for example...
neither the DLP nor factoring are NP-complete in fact AFAIK there is no known algorithm for solving NP-complete problems in the QC model.
There seems to me some (a lot?) of FUD mixed up in this article. (surprise surprise...)
:-) i'm down with that.
It starts out with the fact that public key encryption relies on the existence of one trapdoor one-way functions. Now in practice we mainly instantiate these functions with the RSA function (f_e(x):=x^e mod n with trapdoor p,q such that pq=n). But there is no reason to believe this is the only possible example of trapdoor OWF! Admitedly in the 80s when this concept was first being explored there were quite a few failures when trying to base implementations on NP-Complete and/or NP-Hard problems (think knapsack for example). But since we already had RSA with all it's nice properties (efficiency, elegance and simplicity) the research community was not overly motivated to find others.
There have been and to this day still are other lines of research. Take Ajtai and Dwork's work in the direction of basing PKE on worst-case hardness of the shortest vector problem (SVP) or Micciancio's work on generalizing the knapsack problem such that average-case hardness of approximating the answer can be reduced to worst-case hardness of certain lattice based problems.
Another general direction has been to come up with groups and fields over which solving the DLP is difficult. (For example torus-based crypto and generalized Jacobian groups). AFAIK for most of these candidates there are no (known efficient) reductions from the DLP problem over Z_p or elliptic curves to the DLP in these new groups. Thus it is not immediately clear how or if Schorr's algorithm would break such systems.
In any case there is reason to believe that there can not be (or that we can't find) good candidates for trapdoor OWFs in the quantum computational model. After all there is such a thing as Quantum P and Quantum NP. Though the inequality of these set's of problems doesn't directly imply the existence of quantum trapdoor OWFs it is a good indication there of.
So basically the message is : Relax! The PKE world is by no means on the brink of an apocalypse. At most (and best in my opinion) we're in for a bout of some serious foundations research. to me that just sounds like more funding for applied mathematicians and complexity theorists from various corners and a WHOLE bunch of new candidates and interesting results.
a random number generator (i.e. the random variable describing the output of the generator) does not have to be distributed with a uniform distribution in order to be random. It just implies that it is not deterministic. that is the entropy of the random variable is greater then 0. further randomness is really only well defined in relation to a view (information set). what appears random to you may not be random to me. (technically the entropy of a random variable may be non-zero on it's own however conditioned on some other information it may be 0).
take a (probabilistic) turing machine which has an extra input tape with a sequence of uniformly and independently distributed bits on it (i.e. it's "random tape"). if the machine outputs this tape and you don't see the tape then the turing machine outputs a random sequence from your point of view. that is the random variable describing the next bit of output condition on all previously observered output has (min-)entropy 1. however if your are privy to the random tape of the machine then you can suddenly predict the output of the machine with probability 1. i.e. the entropy of the output is 0 and so the output of the machine is no longer random in any sense.
another definition of randomness put forward by kolmogorov is that a random random string is one that can not be compressed. this relates closely to the algorithmic definition of randomness which states that a string is random iff it is shorter then any program which has the string as output.
I think that's over simplifying things a bit. It's about changing the balance of power (at least in theory). If both you and your enemy have the capability to attack each other there is a balance; a detent. However if then your enemy develops and puts in place means to block your attack, even if the development is purely "defensive" the balance has now been scewed and the next step in the arms race has begun. This is an extreme example but imagen this on a level of "can block us more then we can block him" and you get to what Putin is talking about.
Note i'm talking theory here and not making any argument about weather this really applies to the current situation. After all, the US claims the shield is against single rogue missiles not huge swarms like Russia commands. But my honest opinion is that all of this are political, economic and strategic games and what the public gets to see and read is just the very tip of the iceberg, making the judgment of a meaning and intent behind a leaders statement a very tricky thing at best.
AFAIK topologically speaking your cube IS (at least homomorphic to) a sphere => it has no hole.
This seems to be a deffinition problem. What is not possible (as the wiki article points out) is a man in the middle _where A and B end up with the same key_. However if we assume that Mallory is also between A and B for all conventional communication (i.e. not the quantum chanel) then things are different. A and M agree on a key, and M and B agree on a different key. then when A and B use normal channels to acertain if they can understand each other (implying they have agreed on the same key.) now Mallory can act as a go between decrypting A's messages and rencrypting them to B. So A and B believe they can understand each other and M is sitting happily in the middle. this is ofcourse a more general problem though. namely that all one ever can verify in the digital world (quantum or not) is that one is communicating with a key (be it a OTP, pk/sk pair, symetric key or whatever) but NOT with an entity. i.e. you are not sending a message to Alice but to alice's key. who knows who actually owns alice's key. maybe not alice at all. as it so happens, solving this problem was the main motivation behind the invention of PKI and Certifactes. These attempt to establish a chain of trust linking a key to an entity. pure quantum key exchange algorithms do nothing to deal with this problem though and thus suffer from the same type of man in the middle as an anonymous deffie hellman does.
If i'm not mistaken then that is exactly how one uses entangled particles (photons in your example). the idea is that when two particles are entangled then if alice reads the spin of her particle she will get the same reading as bob (provided they use the same base to messure the spin). The problem with transmitting information (and the reason why this doesnt break the "nothing goes faster then the speed of light" rule) is that the entangled pair can not be created to read to a predefined spin (= bit value). Thus the result is a correlated but random result. ideal for setting up a OTP but no good for actual information exchange. on the other hand i'm no quantum computer scientist nor a physicist so all the usual disclaimers apply here.
Nor is the CIA really into cryptography. Yes they need a few cryptographers here and there but when I went to them, looking for a job (in the field of cryptography research) i was politly asked to go see their colegues over at the (very non-discript and unmarked) NSA booth over in the corner.
:-)
:-)
The first time round when approaching the NSA booth I stupidly enough kept my (normal) british accent and was almost imediatly told to go see the GCHQ. (i.e. "get lost kid") So I walked off again and only came back when there was a new representative sitting behind the desk. This time I didnt bother mentioning my nationality and put on a nice generic american accent letting them assume my orginis were more... kosher.
Of course that interview went quite differently... "Oh yes! Well you've come to the right place then. We have a great program for you begining with several years of training where we rotate you through the variouse subfields teaching you all the newest techniques and methods you'll never hear about in academic circles... blablabla.... Just please sign here."
somehow i just couldnt help but thinking of Faust... i wonder why...
i got what i wanted though. a cool business card from the NSA math highering department and some email address printed on an old dotmatrix, cutout and stuck on the back. cloack n dagger n all that...
Anyway if you really want do crypto work for the US gov. (or DOD in particular) then never mind the CIA. The NSA or the SigInt guys are who you really want to talk to.
AFAIK of course. I mean how would a mere civilian and a FORIEGNER at that have any clue about whats going on over there...
no current political influence? did u know that north korea has on several ocasions already requested a TLD for it's self just like almost any other country in this world but has been repeatedly denied? sounds a bit fishy to me u.
thing is, it's not quite like a more "user friendly" car. the conversation started by talking about wether TFA was good for Linux's public image or not although it didnt mention GNU. we're talking about if the acronyme GNU is important when trying to win the masses over.
the problem with the analogy is that there are far FAR more people in the world who can drive without transmition (and even may choose the cheapest most bearbone version of a car) then there are "average people" who can use and want Linux without X.
so the market for Cars without X-friendliness is proportional to the total car market, is way bigger then the proportion of GNU/Linux to the GNU/Linux/X in the market of average people.
thus for cars its fine to have models with no X but the market is to small for Linux without X. I geuss if we dont bother with X then why bother with GNU.
both or neither. thats all i'm saying. (better neither IMHO. Linux is enough)