Spike Ilacqua

In what sense? The decryption doesn't require the Internet access, just a database connection. It is possible to decrypt in a rake task, the console, or even a standalone app.

What do you get back? Is the private key loaded? Are you passing in it's password?

I see how this would be valuable. How do you envision storing the signature? If an attacker can manipulate the data isn't the signature vulnerable as well?

So roughly along the lines of: ``` ruby # Encrypt and Sign ciphertext = public_key.public_encrypt(plaintext,@padding) digest = OpenSSL::HMAC.hexdigest(OpenSSL::Digest.const_get(@digest).new, @hmac_secret, plaintext) ciphertext += "--#{digest}" # Unsafe assumption # Decrypt and verify...

Got it, identical plaintext generates identical MACs and badness ensues. So (again roughly): ``` ruby # Encrypt and Sign ciphertext = public_key.public_encrypt(plaintext,@padding) digest = OpenSSL::HMAC.hexdigest(OpenSSL::Digest.const_get(@digest).new, @hmac_secret, ciphertext) ciphertext += "--#{digest}"...

Got a link to some best practices?

The issue is how Ruby itself handles the decrypted field. "ASCII-8BIT" is an alias for "BINARY" and means "raw-bytes". Ruby chooses this because it doesn't know what the encoding of...

I don't have any more details to add yet, but I can confirm we're seeing this same thing on two different projects. Both are Rails apps running on EC2 instances,...

One additional data point. On our other project, I migrated the client from Serverless to Servered (Serverful? Severicious?) and the problem when away.

I ran into this as well and figured out **part** of it. `_doc` is the default document type for the *elasticsearch-model* gem. You can override the default where *Elasticsearch::Model* gets...