New answers tagged

0

If you are using Java, shouldn't you be using the Java KeyStore? https://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html This class represents a storage facility for cryptographic keys and certificates. A KeyStore manages different types of entries. Each type of entry implements the KeyStore.Entry interface. Three basic KeyStore.Entry ...


1

I'm assuming that your threat model is an attacker gaining access to read files on your webserver via some type of web exploit. If not, you should question what exactly you are mitigating with your proposed encryption strategy. If it is, an option similar to 2 is probably the most simple. I would use AES128-CBC as the algorithm for a Key Encrypting Key. ...


1

Although in your case the IV should be okay in plaintext in the DB, there is a severe vulnerability if you allow the user to control the IV. The IV in decryption is used (and only used) to XOR the first block into the final plaintext - so if an attacker can control the IV they can arbitrarily control the first block of data, and the rest of the plaintext ...


1

Don't upload the private key to the server. Instead, send the encrypted shared key to the user. The user can then decrypt with the private key, which stays on the user's system. Then, the user sends the decrypted shared key to the server.


1

For part two, you can do sensibly better: (The session between User and System is encrypted) User starts a task that requires an encrypted file System sends tne encrypted shared key User locally decrypts the shared key User sends the decrypted shared key (stays only in memory) System decrypts the file into memory System deletes the decrypted shared key ...



Top 50 recent answers are included