Cryptography Perfect forward secrecy "blind" file encryption. |
- Perfect forward secrecy "blind" file encryption.
- Approaches for pen and paper ciphers
- Authentication bypass in Oracle Access Manager SSO solution via padding oracle attack
- Is it possible to encrypt with ElGamal and Diffie Hellman in a single file?
- hardware-accelerated True Random Number Generator that exploits electronic noise to provide random bytes - better than any software-based random number generation
Perfect forward secrecy "blind" file encryption. Posted: 02 May 2018 06:38 PM PDT Suppose you have a device that encrypts files every unit of time and broadcasts them somewhere for safe keeping. The assumption of this scenario is that the device can get compromised at any moment and you do not want intercepted files up to that point to be decrypted - they no longer exist on the device. Assume that a secure communication channel cannot exist or the files in safe keeping cannot be guaranteed to be private. A way to do this comes to mind with public-private key cryptography. You derive a master key which will be the master private key, the device contains the public key associated with that private key. For very file the device encrypts it generates a random private key and computes the shared secret between it and the master public key. Uses the shared secret to derive a symmetric cipher key and encrypts the file with it, appends the ephemeral public key to the file - which allows you as the possessor of the master private key to compute the shared secret of every file. Surely such a protocol already exists and perhaps has a name, can anyone point me to it? PS: The term "Perfect forward secrecy" is probably abused here because the master key can peer back in time. [link] [comments] |
Approaches for pen and paper ciphers Posted: 02 May 2018 05:23 PM PDT I have tried designing block ciphers that could be used for pen and paper ciphers, but the trouble is that with block ciphers (even perfectly designed ones, the best example of which is probably AES) require a lot of rounds for security, and AES for 8 rounds for example is broken (while not practically, quite significant speed improvements). My cipher (which uses 8 rounds) has no hope of being anywhere near as sound as AES, especially with 8 rounds, and already it takes 16 minutes for a block encryption on a piece of paper (which is fast but 48 minutes for 3x80-bit blocks (5bits per character = for 48 characters), so obviously block ciphers are not the right approach when you need low operation count. However, requirements for a pen and paper cipher are also relaxed. There are no chosen plaintext attacks (and hence differential cryptoanalysis is stumped quite a bit), there are very few messages exchanged and those are short, usually there is no situation where a lot of plaintext-ciphertext pairs are known (contrary to computers where you have protocols and headers and formats, e.t.c.) So is there a construction (not a block cipher) which is perhaps weaker in a theoretical sense but which can stand its ground with a smaller number of operations? Would data dependent operations be part of this? [link] [comments] |
Authentication bypass in Oracle Access Manager SSO solution via padding oracle attack Posted: 03 May 2018 01:42 AM PDT |
Is it possible to encrypt with ElGamal and Diffie Hellman in a single file? Posted: 02 May 2018 10:13 AM PDT I want to encrypt a message with ElGamal and in order to transfer it I want to use Diffie-Hellman. The reason I want that is because I want just the ElGamal ciphertext to be signed and not the message before it's encrypted, but in my mind transferring an encrypted message with an unencrypted sign isn't safe, thus why I want to use Diffie-Hellman. I know it's common practice to sign and then encrypt but in my use the sign needs to be unencrypted. [link] [comments] |
Posted: 02 May 2018 09:21 AM PDT This TRNG accelerator is compliant with NIST FIPS SP-800 90B and BSI AIS 31 industrial standards. It is developed by Secure-IC and implemented using FPGA devices. FPGAs are devices to accelerate specific workloads by offloading CPUs and they are making their ways in Cloud Infrastructures. This hardware accelerator can generate 1.3 GB/s of true random numbers in Cloud infrastructures to boost your cryptography and encryption applications. Go ahead and create a free account on https://accelstore.accelize.com (no credit card needed) and try it (free of charge). [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