{"action":"created","issue":{"url":"https://api.github.com/repos/ikizir/HohhaDynamicXOR/issues/9","labels_url":"https://api.github.com/repos/ikizir/HohhaDynamicXOR/issues/9/labels{/name}","comments_url":"https://api.github.com/repos/ikizir/HohhaDynamicXOR/issues/9/comments","events_url":"https://api.github.com/repos/ikizir/HohhaDynamicXOR/issues/9/events","html_url":"https://github.com/ikizir/HohhaDynamicXOR/issues/9","id":118386298,"number":9,"title":"The flaw: or what is an enterprising blackhat/NSA type to do, now?","user":{"login":"cmacq2","id":13215950,"avatar_url":"https://avatars.githubusercontent.com/u/13215950?v=3","gravatar_id":"","url":"https://api.github.com/users/cmacq2","html_url":"https://github.com/cmacq2","followers_url":"https://api.github.com/users/cmacq2/followers","following_url":"https://api.github.com/users/cmacq2/following{/other_user}","gists_url":"https://api.github.com/users/cmacq2/gists{/gist_id}","starred_url":"https://api.github.com/users/cmacq2/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cmacq2/subscriptions","organizations_url":"https://api.github.com/users/cmacq2/orgs","repos_url":"https://api.github.com/users/cmacq2/repos","events_url":"https://api.github.com/users/cmacq2/events{/privacy}","received_events_url":"https://api.github.com/users/cmacq2/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-11-23T14:07:26Z","updated_at":"2015-11-23T15:41:14Z","closed_at":null,"body":"Hi. I just read about your algorithm and since I have some time to kill I thought I'd try and give it some thought. I am not exactly a cryptographer, more of a noob with an outside fascination for the Maths wizardry (as in: any sufficiently advanced Math is like abracadabra to me) and related interests.\r\n\r\nI base my understanding not on your source code (there's a lot of it to digest, and with crypto details tend to matter and warrant close scrutiny), but on your high level algorithm design/overview as posted on your blog.\r\n\r\nSince you claimed a breakthrough in paradigm, my curiosity peaked. Curiosity led to my mind picking up, and I think I might just have spotted a bit of a flaw in your algorithm. Again, note I'm no expert so please: gently and graciously correct me where I am wrong.\r\n\r\nWith that aside, let me paint you a scene. Imagine you are Bob. Imagine you want to store photographs (of cats, naturally) confidentially on a server hosted by Alice. Imagine Bob and Alice use your crypto in a scheme like this: Bob encrypts his cat picture, and submits it to Alice.\r\n\r\nImagine Eve. Eve runs a malicious scheme to subvert the crypto: she managed to redirect traffic from Bob to her servers before passing it on to Alice, and vice versa: a classic Man In the Middle.\r\n\r\nNow, nothing to worry yet: Bob's pictures are encrypted so if they aren't cats, Eve still doesn't know she's hit paydirt. Still, Eve is crafty. She notices something about your algorithm:\r\n\r\n> Given the key body length(L) is a power of 2, and M is an integer to tell us where we are in the \"key > body\":\r\n> \r\n> We just take the byte at position M of the key body, we XOR that byte with the byte to be  encrypted(X).\r\n> We increase the byte at position M and \"jump to\" (M+X)%L\r\n\r\nEve notices this:\r\n * Let key be the array of bytes of length L, M the index into that array, and X an array of bytes which constitutes the message to be encrypted. Let C be the encrypted result (an array of bytes constituting the cypher text)\r\n * The first byte of C, C[0] is just this: C[0] = key[M] XOR X[0].\r\n\r\nEve thinks aha: if I know X[0], then I know key[M]. But, I don't know key[M]. Except... \r\nHang on: files are not random collections of bytes. They have structure. PNG, JPEG, GIF, you name it all files have a clear an marked structure, and in particular most of them have a structure starting at the beginning to tell whatever thing reads those files what's inside.\r\n\r\nSo Eve can recover the first byte by induction: assume that the file format being uploaded is limited to one of three options: JPEG, GIF, PNG and over time collect many copies of encrypted upload to prove/disprove the hypothesis. (Proving it is a matter of validation by checking the assumptions against statistics: how often do the structures 'recovered' match exactly with the hypothesis?)\r\n\r\nIn particular, if Eve can trick someone into uploading a known plaintext she can trivially recover the first byte. In particular, if Eve can craft a scenario in which Bob is forced to upload a **known** file, Eve can simply replay the algorithm to recover his key and then decrypt all Bob's pictures! This scenario is not that outrageous/ludicrous: she is the (wo)man in the middle, so she can 'lie' to Bob about the state of Alice's server.\r\n\r\nYour switching/jumping steps don't matter. They are clever enough, but they are fully predictable if you know how the algorithm works and you have a known plaintext to work with (so the X bytes are all known):\r\n * At that point the key must be updated: key[0] ++, M = (M + X[0]) % L.\r\n * Well, Eve thinks I can cook up my own malicious implementation which takes a known plaintext and its corresponding cyphertext, do this funky dance routine and recover the key and output that.\r\n\r\nKnown plaintext attacks are not just a theoretical concern. They are, in fact one of the most important things to defend against because nearly everything you want to encrypt has a known structure: network protocols, cryptographic signatures for checking message integrity and authentication, file archives, files like ODF documents (just a fancy ZIP file with lots of known XML and CSS).\r\n\r\nBecause your crypto algorithm uses the key directly in this way, essentially by XOR'ing with the key, you 'leak' the key into the cypher text: making it possible for all the evil Eve's of this world to recover them with enough persistence.\r\n\r\nIn particular, to this noob it seems that there are, still, a few easily discerned cardinal rules of good crypto:\r\n\r\n * If you use symmetrical key crypto (like this scheme), you can only use the key once, then you have to throw it away. If you don't, then known plaintext attacks, statistical analysis and WW II era math will crack your key. That is because if you use the same key repeatedly, fundamentally there is an inverse operation that extracts the key from the cypher text (as described above) because the key leaks into it. If you fail to throw away your key, you have no forward secrecy and therefore effectively no cryptographic protection anymore when old messages are decrypted because it means the key is effectively recovered. As a result symmetric key crypto is... not very practical, even if it is the only provably secure (not just cryptographically secure) method. The correct method is known as the [One Time Pad](https://en.wikipedia.org/wiki/One-time_pad).\r\n * If you use asymmetrical crypto (private + public key): do not, ever, share your private key. \r\n * In fact, do not use your private key. Instead: derive a 'session' key pair (private + public) from your private key and present those: that's like throwing away your key afterwards in symmetrical key crypto. If you do this you get forward secrecy: when an old message is broken, they may have your old 'session' key but you stopped using those any more long since, and hence your keys are still safe and so is your crypto. This is, at least to this noob, essentially like an \"One Time Pad for asymmetrical key crypto\"."},"comment":{"url":"https://api.github.com/repos/ikizir/HohhaDynamicXOR/issues/comments/158972467","html_url":"https://github.com/ikizir/HohhaDynamicXOR/issues/9#issuecomment-158972467","issue_url":"https://api.github.com/repos/ikizir/HohhaDynamicXOR/issues/9","id":158972467,"user":{"login":"ikizir","id":15926111,"avatar_url":"https://avatars.githubusercontent.com/u/15926111?v=3","gravatar_id":"","url":"https://api.github.com/users/ikizir","html_url":"https://github.com/ikizir","followers_url":"https://api.github.com/users/ikizir/followers","following_url":"https://api.github.com/users/ikizir/following{/other_user}","gists_url":"https://api.github.com/users/ikizir/gists{/gist_id}","starred_url":"https://api.github.com/users/ikizir/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ikizir/subscriptions","organizations_url":"https://api.github.com/users/ikizir/orgs","repos_url":"https://api.github.com/users/ikizir/repos","events_url":"https://api.github.com/users/ikizir/events{/privacy}","received_events_url":"https://api.github.com/users/ikizir/received_events","type":"User","site_admin":false},"created_at":"2015-11-23T15:41:14Z","updated_at":"2015-11-23T15:41:14Z","body":">Anyway, I really did not understand. Can you clarify the answer to this question:\r\n>how does Alice communicate the salt to Bob?\r\n\r\nYou see: You have \"issues\".\r\nI wrote you twice!\r\nTwice!\r\nIn readme too!\r\nThree times!\r\nYou just don't read what I wrote above. In this page."}}