Cryptography Crikey! Key recovery attack on SIMON- 32/64 |
- Crikey! Key recovery attack on SIMON- 32/64
- I created dissononce, an easy to read and understand reference implementation for Noise Protocol Framework
- Cryptology ePrint Archive Report 2019/459: From Collisions to Chosen-Prefix Collisions —Application to Full SHA-1
- AES-CTR: 64-bit vs 128-bit counter
- ATECC508A: it all boils down to a simple boolean output in the clear?
- #ROC2ico Phase 1 of Rasputin Party Mansion launches already
- Sending an S/MIME encrypted email without my own cert?
| Crikey! Key recovery attack on SIMON- 32/64 Posted: 10 May 2019 04:39 PM PDT |
| Posted: 11 May 2019 01:08 AM PDT |
| Posted: 10 May 2019 06:37 PM PDT |
| AES-CTR: 64-bit vs 128-bit counter Posted: 10 May 2019 07:25 AM PDT Intel in this document uses 64-bit counters in its implementation of AES-CTR (meaning half of IV is left immutable), this allows to keep counter in XMM register without transferring it to general-use registers via memory, thus noticeably improving performance. But IIUC such approach is not strictly speaking compatible with OpenSSL, as it uses full 128-bit counter. Yes, assuming random IV probability of encountering consequences of such difference is really small for typical applications (4.4e-16 for 1 MB payload), but it's still there. So my question is: how widely are used 64-bit counters in practice? What other modifications of CTR mode can be encountered (e.g. LE counter instead of BE)? [link] [comments]  |
| ATECC508A: it all boils down to a simple boolean output in the clear? Posted: 10 May 2019 03:42 AM PDT [Edit] See comment for answer. TL;DR: Verifying an ECDSA, on the ATECC508A, consists of just returning a boolean that can be sent by a man-in-the-middle. I have a shared secret with this chip (32 bytes). Almost everything in the chip can be hashed with this shared secret and a radom-nonce to make sure data really comes from the chip. So the chip does: SHA256(Message, SharedSecret, RandomNonce), I do the same on the Microcontroller, I verify we both came to the same result, if yes: all good. No one can: produce this hash without the SharedSecret, find the secret with the hash, replay the message due to the random nonce. Now, there are no flags anywhere in the chip that says: last key used, last verifying result. We could both have hashed it (as described above) to make the whole thing secured. BUT NO! It just all boils down to a boolean sent on the bus, in the clear?! Then, just do:
What am I missing? [link] [comments]  |
| #ROC2ico Phase 1 of Rasputin Party Mansion launches already Posted: 10 May 2019 09:02 PM PDT hey guys did you know this ? #ROC2ico Phase 1 of Rasputin Party Mansion launches,its the daily lives of 30 models living in one party mansion broadcast live in HD by 35 cameras 24/7. well if you have not joined already .i suggest you all to join this huge and amazing project . to learn more about this project click here : #ROC2ico https://www.rasputinmansion.com/ [link] [comments]  |
| Sending an S/MIME encrypted email without my own cert? Posted: 10 May 2019 01:20 PM PDT So I have a working knowledge of public key crypto, I understand the basic principles and use GPG and S/MIME on some inboxes. However, I need to send some sensitive data from one inbox to a recipient, who signed their previous messages and attached their public key. I would like to use S/MIME to encrypt this data using their public key, however my web-based email client doesnt offer S/MIME functionality. Can I manually encrypt an S/MIME protected message using their public key and send it via a cloud based mail provider? [link] [comments]  |
| You are subscribed to email updates from Cryptography news and discussions. To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States | |
No comments:
Post a Comment