Cryptography Dragonblood - weaknesses in WiFi WPA3 key exchange |
- Dragonblood - weaknesses in WiFi WPA3 key exchange
- [Question] - Protecting a Program's Private Keys
- Differential Cryptanalysis of Mirrored Drives?
- Storing encryption keys client side - best practice
| Dragonblood - weaknesses in WiFi WPA3 key exchange Posted: 11 Apr 2019 09:38 AM PDT |
| [Question] - Protecting a Program's Private Keys Posted: 11 Apr 2019 08:54 AM PDT |
| Differential Cryptanalysis of Mirrored Drives? Posted: 11 Apr 2019 02:03 PM PDT Hi, everybody. Does anyone here know of a resource that looks at potential avenues for differential cryptanalysis of mirrored hard drives? In this case I'm looking at linux systems using LUKS in AES-XTR mode. They'll be using 128 or 256 bit keys each for IV and data, typically. One approach is to set up encrypted block devices and then mirror them. This is preferred by some distros, ZFS admins, etc. The other approach is to mirror some block devices and then encrypt the mirror. Some distros enforce this method. So in the first case four keys are in play, in the second only two. I've heard some people say that the higher entropy with four keys is better for security overall. Others point to the extra power consumption and claim that both mirror devices are just as secure. What I'm wondering is whether in the 4-key case a known-plaintext attack becomes a risk by encrypting the same data with two sets of keys. If the writes could be intercepted (perhaps easier in an iSCSI case than local, but still plausible through various vectors) would the writes of a known-plaintext assist in the eventual decryption of both drives? They could come from targeted communications (e.g. email) or even just the known structure of the filesystem block headers. I'd hate to be adding redundancy and encryption only to foil any efforts at security. I'd appreciate any thoughts on either approach alone or in comparison or pointers to extant discussion of possible attacks. Thanks in advance. [link] [comments]  |
| Storing encryption keys client side - best practice Posted: 11 Apr 2019 06:13 AM PDT Looking for the wisdom of Reddit on securing encryption keys client side. If we have a web app, shared by many users and want to move the encryption from server to client , this means sharing and managing the encryption key (it uses AES on the server side) on each of the clients and each client could have multiple devices. There would also be multiple encryption keys to manage. Any suggestions on the best way to do this? Needs to be highly secure but also user friendly. thanks [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