{"action":"created","issue":{"url":"https://api.github.com/repos/trustcrypto/OnlyKey-Firmware/issues/74","repository_url":"https://api.github.com/repos/trustcrypto/OnlyKey-Firmware","labels_url":"https://api.github.com/repos/trustcrypto/OnlyKey-Firmware/issues/74/labels{/name}","comments_url":"https://api.github.com/repos/trustcrypto/OnlyKey-Firmware/issues/74/comments","events_url":"https://api.github.com/repos/trustcrypto/OnlyKey-Firmware/issues/74/events","html_url":"https://github.com/trustcrypto/OnlyKey-Firmware/issues/74","id":330359529,"node_id":"MDU6SXNzdWUzMzAzNTk1Mjk=","number":74,"title":"OK_DECRYPT has \"cooldown\" period","user":{"login":"M-Pixel","id":4174312,"node_id":"MDQ6VXNlcjQxNzQzMTI=","avatar_url":"https://avatars0.githubusercontent.com/u/4174312?v=4","gravatar_id":"","url":"https://api.github.com/users/M-Pixel","html_url":"https://github.com/M-Pixel","followers_url":"https://api.github.com/users/M-Pixel/followers","following_url":"https://api.github.com/users/M-Pixel/following{/other_user}","gists_url":"https://api.github.com/users/M-Pixel/gists{/gist_id}","starred_url":"https://api.github.com/users/M-Pixel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/M-Pixel/subscriptions","organizations_url":"https://api.github.com/users/M-Pixel/orgs","repos_url":"https://api.github.com/users/M-Pixel/repos","events_url":"https://api.github.com/users/M-Pixel/events{/privacy}","received_events_url":"https://api.github.com/users/M-Pixel/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2018-06-07T17:04:19Z","updated_at":"2018-06-08T16:04:02Z","closed_at":null,"author_association":"NONE","body":"I built a small application using the API, and I've run into a bit of an issue with using `OKDECRYPT`. \r\n\r\nI can send `OKDECRYPT` with slot ID (RSA 4) and a chunked 512 byte RSA4096-encrypted payload, and then successfully read the decrypted key.  I stop reading as soon as `0`s are encountered in a returned chunk.\r\n\r\nThe problem comes when I try to do anything after that. If I try to decrypt a second key too soon after, I get `ERROR DEVICE LOCKED`.  At one point, I also had the code arranged so that the first thing that happened after the first key decryption was `OKGETLABELS`, and I observed that if this happens too soon after `OKDECRYPT`, the first label contains the tail end of the key that was previously decrypted. This leads me to believe that the OnlyKey is taking a long time to zero-out some buffers, and doesn't properly wait until this is done before processing new commands.\r\n\r\nIs there a way for me to check whether or not the key is actually ready to receive the next command, or will resolving this issue require some modification to the firmware? The amount of time needed has been inconsistent - sometimes 10 seconds was enough, sometimes not. Currently, the most reliable way I've found is to wait 30 whole seconds. That's no good from a developer's maintainability perspective, nor from a user's usability perspective."},"comment":{"url":"https://api.github.com/repos/trustcrypto/OnlyKey-Firmware/issues/comments/395808260","html_url":"https://github.com/trustcrypto/OnlyKey-Firmware/issues/74#issuecomment-395808260","issue_url":"https://api.github.com/repos/trustcrypto/OnlyKey-Firmware/issues/74","id":395808260,"node_id":"MDEyOklzc3VlQ29tbWVudDM5NTgwODI2MA==","user":{"login":"onlykey","id":18121756,"node_id":"MDQ6VXNlcjE4MTIxNzU2","avatar_url":"https://avatars1.githubusercontent.com/u/18121756?v=4","gravatar_id":"","url":"https://api.github.com/users/onlykey","html_url":"https://github.com/onlykey","followers_url":"https://api.github.com/users/onlykey/followers","following_url":"https://api.github.com/users/onlykey/following{/other_user}","gists_url":"https://api.github.com/users/onlykey/gists{/gist_id}","starred_url":"https://api.github.com/users/onlykey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/onlykey/subscriptions","organizations_url":"https://api.github.com/users/onlykey/orgs","repos_url":"https://api.github.com/users/onlykey/repos","events_url":"https://api.github.com/users/onlykey/events{/privacy}","received_events_url":"https://api.github.com/users/onlykey/received_events","type":"User","site_admin":false},"created_at":"2018-06-08T16:04:02Z","updated_at":"2018-06-08T16:04:02Z","author_association":"COLLABORATOR","body":"@M-Pixel OK I think I know what you are seeing with the Symptom 1/2. RSA 4096 decryption is not fast for an embedded device like this, it takes about 8 seconds to complete. RSA 2048 is much quicker closer to 2 seconds. While the decryption is in progress the OnlyKey does not respond to anything. Any USB messages you send are stored in your computer's USB buffer and once the OnlyKey finishes the decryption (or an error occurs) OnlyKey then receives and processes the USB messages you sent. Also keep in mind that if OnlyKey sends a USB message to the computer but the app is not listening for a message but then later requests a response from OnlyKey the app might pick up the first message. Keep this in mind as this may explain some of the issues you are seeing.\r\n\r\nIf you want to send over a the C# app I will try to reproduce what you are seeing here.\r\n\r\nFor the key labels this feature is not currently being used by any of the apps but the idea was that when you set a key on OnlyKey you can set the Key ID and/or a descriptive label. Then the app can send a decrypt request with a Key ID or other descriptor instead of a slot, the OnlyKey will search and see if it has a key with that label. This way you can put any key in any slot. \r\n\r\nSee here for info on compiling firmware - https://github.com/trustcrypto/OnlyKey-Firmware/issues/59\r\n\r\n"}}
{"actor":{"display_login":"onlykey"}}