{"action":"opened","issue":{"url":"https://api.github.com/repos/calvinmetcalf/hmac-stream/issues/5","labels_url":"https://api.github.com/repos/calvinmetcalf/hmac-stream/issues/5/labels{/name}","comments_url":"https://api.github.com/repos/calvinmetcalf/hmac-stream/issues/5/comments","events_url":"https://api.github.com/repos/calvinmetcalf/hmac-stream/issues/5/events","html_url":"https://github.com/calvinmetcalf/hmac-stream/issues/5","id":78080783,"number":5,"title":"chosen application attack","user":{"login":"dominictarr","id":259374,"avatar_url":"https://avatars.githubusercontent.com/u/259374?v=3","gravatar_id":"","url":"https://api.github.com/users/dominictarr","html_url":"https://github.com/dominictarr","followers_url":"https://api.github.com/users/dominictarr/followers","following_url":"https://api.github.com/users/dominictarr/following{/other_user}","gists_url":"https://api.github.com/users/dominictarr/gists{/gist_id}","starred_url":"https://api.github.com/users/dominictarr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dominictarr/subscriptions","organizations_url":"https://api.github.com/users/dominictarr/orgs","repos_url":"https://api.github.com/users/dominictarr/repos","events_url":"https://api.github.com/users/dominictarr/events{/privacy}","received_events_url":"https://api.github.com/users/dominictarr/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-05-19T13:11:42Z","updated_at":"2015-05-19T13:11:42Z","closed_at":null,"body":"I think I can strengthen my argument for #4 \r\nby what I am calling a \"chosen application attack\"\r\n\r\nA \"chosen application attack\" is analogous to a chosen plaintext attack.\r\n\r\nThe attacker can choose an arbitrary application to run over the crypto protocol that is being audited,\r\nthen if they can attack that application through the protocol in question and either leak information, control it in some way, or disrupt service unreasonably then they win and that should be considered a security hole.\r\n\r\nMy chosen application is a realtime system that sends a short message and then waits for a response from the server before continuing - I'll show that an attacker who may flip bits in the ciphertext can force such an application into a deadlock (even when protected by hmac-stream)\r\n\r\nAll you have to do is flip a bit in the length field so that you have made the receiver expect a long packet instead of a short one (will probably be easy to guess where the length field is, because it's quite likely to be aligned with the start of a tcp packet, and even it's value, since probably is the length of the rest of the packet). This will cause the receiver to wait for more data before it can verify the packet (since it's now expecting a long packet), but the client will never send any more because it already sent everything it has to send until it gets a response from the server!\r\n\r\nOne very simple example of an application like this is an HTTP1.0 GET, which will only send 2 lines, then wait for the response. The server is now waiting for 4k (default hmac-stream setting) it will never get enough data, so it will just stall.\r\n\r\nWhere as, with the change I suggested in #4 you would be protected from this attack even if hmac-stream was used without encryption."}}