Recent events raised never ending question of "could the government place a backdoor in DES/AES/SHA/etc.?"<p>My personal perception (based on available evidence) is that government crypto is as strong as possible, but is weakened where needed via policies. A decade ago during crypto export limitation, there were no backdoors, but a <i>policy</i>: you may export only keys <i>that long</i> [so we can bruteforce them cheaper].<p>Another example: SSL is technically secure, but its biggest weakness is trust in a limited list of certificate authorities (CAs) like VeriSign. Then, there is <i>policy</i> that certificate authorities should give up their private keys when FBI/CIA asks for them.<p>Another example: you may encrypt your files, but must give away your password to a court.<p>Also, it makes sense economically. Government people need strong crypto like everyone else and the best way to test and verify it is by opening it up and deploying as widely as possible. So mistakes are noticed sooner than later. Then, people with guns will make sure you give up your secrets when they need you to.<p>I believe crypto systems are alright. It is policies and violent coercion we should be afraid of.
For a more accessible introduction to SIMON and SPECK take a look at this IETF mailing list message[1] especially the video with introduction by the NSA developers:<p><i>"Today at the MIT Media Lab Legal Hack-a-thon on Identity we had a great
presentation from a couple of designers from the NSA regarding their new
lightweight ciphers called SIMON and SPECK. These ciphers are designed
for low-power limited gate devices (such as RFID and similar devices).<p>The MIT Media Lab Hack-a-thon page is here: <a href="http://iauth.org" rel="nofollow">http://iauth.org</a><p>The NSA presentation is here (You Tube): <a href="https://www.youtube.com/watch?v=vtyo4nWGBwk" rel="nofollow">https://www.youtube.com/watch?v=vtyo4nWGBwk</a><p>Their paper (PDF) is here: <a href="http://iauth.org/legal-hack-a-thon/simonspeckperformance-2/" rel="nofollow">http://iauth.org/legal-hack-a-thon/simonspeckperformance-2/</a> "</i><p>Note: I changed the youtube video from a tinyurl link to the actual link. If you want to tell tinyurl that you visited the youtube video click here: <a href="http://tinyurl.com/bf6fbju" rel="nofollow">http://tinyurl.com/bf6fbju</a><p>[1] <a href="https://www.ietf.org/mail-archive/web/cfrg/current/msg03274.html" rel="nofollow">https://www.ietf.org/mail-archive/web/cfrg/current/msg03274....</a>
is it unusual to use "bitwise and" inside the feistel function? i thought that normally xor or modular addition or shifts or permutations (nx1 s-boxes) were used, which keep all the information (in some sense). "bitwise and" isn't like that (i don't have the right word for this distinction, sorry. maybe "invertible" is the word?) but is used here. anyone know why? or is this a distinction i've invented that has no basis in fact?<p>obviously it doesn't matter (decryption still works) as long as it's inside the feistel function itself. so i guess maybe i am just muddling that with how things must be outside that?