<div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><blockquote type="cite"><br><br></blockquote></div><div style="word-wrap:break-word">There's another thing to consider:  Even assuming NSA-level resources, it would be impossible to rig every potential source of randomness out there.  And suppose you actually put this out there, and thousands of random hackers adopted it.  Would that be important enough for NSA to go to the trouble of forcing Apple to rig everyone's phones just to get to those?  And - unless they could accomplish that with just a software update - it wouldn't work against any pre-existing phones *anyway*<i>.</i></div></blockquote><div dir="auto">1. you don't need Apple to target people you just need to impersonate the appstore to them (so basically we re back to the PKI as your lifeline. That does *not* make me feel safe). Probably there needs to be some nifty tricks to pass the code signing check but that's their job and the payoff woulf be huge.</div><div dir="auto">2. there is already a ton of software running around your actual hardware camera and i would guess a significant part of this software has a direct impact on what you would get as the entropy of you raw image. </div><div dir="auto">3. monitoring the output to try to detect suspicious variations of "entropy" is extremely hard here because you have 3 non independent distributions : </div><div dir="auto">-the distribution of harware camera, each of them having their own specific patterns</div><div dir="auto">- the distribution of scenary (my office, my desk, la tour eiffel)</div><div dir="auto">- and when the first 2 are fixed you have the pattern distribution of your specific camera.</div><div dir="auto">I could also add the distribution of effect of the software stack and/or the process variations in the production of cameras which makes it that no two of them are actually identical.</div><div dir="auto">Basically from all of those complexed distributions I give you one (or 10 or 1000) data points and I ask you "Is it normal ?". I don't know how you could ever answer yes in a foolproof way.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><i></i><div><i><br></i></div><div>Now, if it were known that someone like the North Korean military liked your design and started to use it ... everything would change.</div><div><br></div><div>Things like that have to go into a reasonable risk analysis.</div><div><br></div><div>We often remark here that you should rely on proven code from experts, not do your own crypto code.  That's true with respect to some kinds of attack scenarios, not so simple with respect to others.  If you're a small target, making sure that attacks against you are significantly distinct from attacks against the big targets is probably not a bad idea.</div><div><br></div><div>For example:  Suppose you are suspicious that the NSA has an attack on AES - and you're a little guy who doesn't need to have high-speed hardware, just software; and you don't need to interoperate with anyone.  Take your AES software implementation, run the half the rounds, insert any keyed, reversible operation on the state (*using a key completely independent from the AES key*), then run the other half of the rounds.  In practical terms, no one will ever break that, even if they have some fancy attack on AES itself - unless you use it for something worth many billions of dollars.</div></div></blockquote><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div></div><div style="word-wrap:break-word"><div></div></div></blockquote><div dir="auto">Sorry but I very much dislike those kind of arguments because I think that it encourages people to actually *use* the half baked crypto they wipped in their garage.</div><div dir="auto">Also even for the people you are talking about it is counter productive. </div><div dir="auto">1. the cases where you know from the get go that you will never have to interoperate with anyone are very seldom.</div><div dir="auto">2. Even if you do, and you ve got your  AESbis, you re still a long way away from a working application level secure communication protocol that could replace say TLS for your secret organization. The issue is with every layer you add, the probability of making a huge mistake grows exponetially. OK you got AESbis but on top of it you need a mode. You use CBC ? Then I bet you re vulnerable to those padding attacks (vaudenay, lucky13). Have you thought about the authenticity ? On the protocol level have you protected about replay, downgrade, cross-protocol attacks ? Do you get PFS from you algorithms ? How do you do key distribution ?</div><div dir="auto">That s a lot of things to get right for a group of guys.</div><div dir="auto">I seriously believe that the reason we think those half baked algo are safe is because nobody in the public sector has any incentive to break those...</div><div dir="auto">3. Finally let s assume for a minute that you got 2. right (BIG assumption). Then how do you communicate over the network ? If you use a custom protocol you are pretty much sure that you are going to stick out like crazy in any traffic analysis. If I worked at the NSA/CIA I wouldn t make sure that I decrypted all the traffic, that s probably too hard. I would make sure that I at least know how to classify traffic. If I see something weird and unknown and clearly made not to interoperate I ll make sure that I ll metadata the hell out lf it to know who is communicating with whom when and so on. If they re not a group of students in Comp.Sec. I ll just use one my many exploits to attack directly the endpoints before the data is encrypted or after it s been decrypted and that whole thing costed me a lot less than finding the outlier in a sea of TLS traffic.</div><div dir="auto"><br></div><div dir="auto">The lesson for me is : If the starting point of your reasonning is "AES is broken" then just go home and do something else anything that comes after that has a 50% chance to be horribly broken and that s already way to high if you want to protect valuable data.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><div>                                           </div></div><div><br></div></div></blockquote></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature">Alexandre Anzala-Yamajako<br><br><br></div>