3 ms·

I'm surprised they didn't just use openssl_seal() with a public key, instead of risking the decryption key being forensically recoverable by the victims. Maybe

• c22 12y ago
  They needed the decryption key to be available to the web application because they had modified it to silently decrypt the data coming back from the db so that no one would catch on to their ruse until they'd encrypted enough data to be damaging.
• BuildTheRobots 12y ago
  Never heard of openssl_seal() until now -from my brief read am I right in thinking it's a similar workflow to PGP?
  • sarciszewski 12y ago
    Yeah, similar in concept. You encrypt a message with a public key and can only decrypt it with the private key. It's great for storing data so that a root/filesystem compromise won't reveal any of the previously encrypted data. I'm hoping that jedisct1 will add a parallel functionality to libsodium soon. :) https://github.com/jedisct1/libsodium/issues/231 https://github.com/jedisct1/libsodium/issues/231
    • BuildTheRobots 12y ago
      Parallelism is always a good thing. The specific similarity with PGP that jumped to mind is that you're not actually using your key (or recipients key) to encrypt the message. You're actually generating a random session key to encrypt the message contents and then you're encrypting the session key against the recipients key and sending them that. I was really taken by surprise the first time I read that, but after playing some more with crypto "obviously" you'd have to -otherwise what happens when your message is longer than your key?