| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Use case:
I'm writing a wrapper around MessageEncryptor to make things easier
to rotate a secret in our app.
It works something like
```ruby
crypt = RotatableSecret.new(['old_secret', 'new_secret'])
crypt.decrypt_and_verify(message)
```
I'd like the caller to not have to care about passing the
`on_rotation` option and have the wrapper deal with it when
instantiating the MessageEncryptor object.
Also, almost all of the time the on_rotation should be the same when
rotating a secret (logging something or StatsD event) so I think
it's not worth having to repeat ourselves each time we decrypt a message.
|
| |
|
|
|
|
|
|
|
|
| |
Noticed that verifiers and encryptors never once mentioned key generators
and salts but only concerned themselves with generated secrets.
Clears up the confusing naming around raw_key and secret as well. And
makes the rotation API follow the constructor signature to the letter.
|
|
|
|
|
|
| |
Spares users from passing in non-changing values explicitly.
[ Michael Coyne & Kasper Timm Hansen ]
|
|
|
|
|
|
| |
Both classes now have a rotate method where new instances are added for
each call. When decryption or verification fails the next rotation
instance is tried.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
When MessageEncryptor tries to +decrypt_and_verify+ ciphertexts
generated in a different mode (such CBC-HMAC), the +auth_tag+ may be
+nil+ and must explicitly check for it.
See the discussion here:
https://github.com/rails/rails/pull/28132#discussion_r116388462
|
| |
|
|
|
|
| |
key length
|
|
|
|
|
|
|
|
|
| |
Since keys are truncated, ruby 2.4 doesn't accept keys greater than their lenghts.
keys of same value but different lenght and greater than key size of cipher, produce the same results
as reproduced at https://gist.github.com/rhenium/b81355fe816dcfae459cc5eadfc4f6f9
Since our default cipher is 'aes-256-cbc', key length for which is 32 bytes, limit the length of key being passed to Encryptor to 32 bytes.
This continues to support backwards compat with any existing signed data, already encrupted and signed with 32+ byte keys.
Also fixes the passing of this value in multiple tests.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
| |
AEAD modes like `aes-256-gcm` provide both confidentiality and data authenticity, eliminating the need to use MessageVerifier to check if the encrypted data has been tampered with.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
accept key lengths of 128, 192 or 256-bit, whereas currently we were providing twice the acceptable value.
ruby < 2.4 allowed accepting these values, as extra key bits were ignored. Since https://github.com/ruby/ruby/commit/ce635262f53b760284d56bb1027baebaaec175d1 this now has a strict checking on key length.
Default to key length 32 bytes, to match the compatible length for aes-256-cbc
Fixes #25185
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some `require 'openssl'` statements were surrounded by `rescue` blocks to deal with Ruby versions that did not support `OpenSSL::Digest::SHA1` or `OpenSSL::PKCS5`.
[As @jeremy explains](https://github.com/rails/rails/commit/a6a0904fcb12b876469c48b1c885aadafe9188cf#commitcomment-8826666) in the original commit:
> If jruby didn't have jruby-openssl gem, the require wouldn't work. Not sure whether either of these are still relevant today.
According to the [release notes for JRuby 1.7.13](http://www.jruby.org/2014/06/24/jruby-1-7-13.html):
> jruby-openssl 0.9.5 bundled
which means the above `rescue` block is not needed anymore.
All the Ruby versions supported by the current version of Rails provide those OpenSSL libraries, so Travis CI should also be happy by removing the `rescue` blocks.
---
Just to confirm, with JRuby:
$ ruby --version #=> jruby 1.7.16.1 (1.9.3p392) 2014-10-28 4e93f31 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_20-b26 +jit [darwin-x86_64]
$ irb
irb(main):001:0> require 'openssl' #=> true
irb(main):002:0> OpenSSL::Digest::SHA1 #=> OpenSSL::Digest::SHA1
irb(main):003:0> OpenSSL::PKCS5 # => OpenSSL::PKCS5
And with Ruby 2.1:
$ ruby --version #=> ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-darwin13.0]
$ irb
irb(main):001:0> require 'openssl' #=> true
irb(main):002:0> OpenSSL::Digest::SHA1 #=> OpenSSL::Digest::SHA1
irb(main):003:0> OpenSSL::PKCS5 #=> OpenSSL::PKCS5
|
|\
| |
| | |
Use `Base.strict_decode64` instead of `Base.decode64`
|
| |
| |
| |
| | |
Also reduce extra object allocation by creating string directly instead of join on Array
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
How to use it?
cookies.encrypted[:discount] = 45
=> Set-Cookie: discount=ZS9ZZ1R4cG1pcUJ1bm80anhQang3dz09LS1mbDZDSU5scGdOT3ltQ2dTdlhSdWpRPT0%3D--ab54663c9f4e3bc340c790d6d2b71e92f5b60315; path=/
cookies.encrypted[:discount]
=> 45
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
MessageVerifier and MessageEncryptor.
|
| |
|
| |
|
|
|
|
|
| |
By default, these classes use Marshal for serializing and deserializing messages. Unfortunately, the Marshal format is closely associated with Ruby internals and even changes between different interpreters. This makes the resulting message very hard to impossible to unserialize messages generated by these classes in other environments like node.js.
This patch solves this by allowing you to set your own custom serializer and deserializer lambda functions. By default, it still uses Marshal to be backwards compatible.
|
|
|
|
| |
and require 'securerandom' from the stdlib when active support is required.
|
|
|
|
| |
's/[ \t]*$//' -i {} \;)
|
|
|
|
|
|
|
|
| |
way as jeremy did with message verifier
[#4517 state:committed]
Signed-off-by: Jeremy Kemper <jeremy@bitsweat.net>
|
| |
|
| |
|
|
|
|
| |
[#1617 state:resolved]
|
|
encryption.
The use of encryption prevents people from seeing any potentially secret values you've used. It also supports and encrypt_and_sign model to prevent people from tampering with the bits and creating random junk that gets fed to
A motivated coder could use this to add an :encrypt=>true option to the cookie store.
|