JRuby

Initialization vector length handled differently than in MRI

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: JRuby-OpenSSL 0.6
  • Fix Version/s: JRuby-OpenSSL 0.7
  • Component/s: OpenSSL
  • Labels:
    None
  • Environment:
    Windows Vista,
    ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32],
    jruby 1.3.0 (ruby 1.8.6p287) (2009-06-03 5dc2e22) (Java HotSpot(TM) Client VM 1.6.0-oem) [x86-java]
  • Number of attachments :
    2

Description

The following works in MRI but not in JRuby:
-------------------------------------------------------------
des = OpenSSL::Cipher::Cipher.new("des-ede3-cbc")
des.encrypt
des.key = '0123456789abcdef01234567890'

des.iv = iv = "ed87acdcca419954edccb736f7dc77a74f5ac8dfe3861c3d5f77248e21592131a5423d63ff91f07956ce1aa386f8359931b5" # 100 characters
data = iv + data
puts data
-------------------------------------------------------------

JRuby expects the IV to be the correct length (8 characters in my example). If provided with an IV that is too short JRuby gives back an appropriate 'iv length to short (OpenSSL::Cipher::CipherError)' error, but when the IV is too long a cryptic 'No message available (OpenSSL::Cipher::CipherError)' error is given.

I don't know whether this should be considered a bug in JRuby or MRI, but a more descriptive error on the JRuby side would be appreciated.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dylan McClung added a comment -

What version of the jruby-openssl gem is being used?

I was unable to reproduce the error with jruby 1.5.0dev and jruby-openssl 0.5.2.

Show
Dylan McClung added a comment - What version of the jruby-openssl gem is being used? I was unable to reproduce the error with jruby 1.5.0dev and jruby-openssl 0.5.2.
Hide
Permalink
Heath Anderson added a comment -

I am using jruby-openssl 0.5.2

Show
Heath Anderson added a comment - I am using jruby-openssl 0.5.2
Hide
Permalink
Hiro Asari added a comment -

This appears to be fixed on trunk. With empty "data", we get:

surfboard:sandbox$ ruby -v -r openssl  JRUBY-4012.rb 
ruby 1.8.7 (2008-08-11 patchlevel 72) [universal-darwin10.0]
ed87acdcca419954edccb736f7dc77a74f5ac8dfe3861c3d5f77248e21592131a5423d63ff91f07956ce1aa386f8359931b5
surfboard:sandbox$ ruby19 -v -r openssl  JRUBY-4012.rb 
ruby 1.9.2dev (2009-10-11 trunk 25291) [x86_64-darwin10.0.0]
ed87acdcca419954edccb736f7dc77a74f5ac8dfe3861c3d5f77248e21592131a5423d63ff91f07956ce1aa386f8359931b5
surfboard:sandbox$ jruby -v -r openssl JRUBY-4012.rb
jruby 1.5.0dev (ruby 1.8.7 patchlevel 174) (2009-10-11 24ea053) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_15) [x86_64-java]
ed87acdcca419954edccb736f7dc77a74f5ac8dfe3861c3d5f77248e21592131a5423d63ff91f07956ce1aa386f8359931b5
Show
Hiro Asari added a comment - This appears to be fixed on trunk. With empty "data", we get: 
surfboard:sandbox$ ruby -v -r openssl  JRUBY-4012.rb 
ruby 1.8.7 (2008-08-11 patchlevel 72) [universal-darwin10.0]
ed87acdcca419954edccb736f7dc77a74f5ac8dfe3861c3d5f77248e21592131a5423d63ff91f07956ce1aa386f8359931b5
surfboard:sandbox$ ruby19 -v -r openssl  JRUBY-4012.rb 
ruby 1.9.2dev (2009-10-11 trunk 25291) [x86_64-darwin10.0.0]
ed87acdcca419954edccb736f7dc77a74f5ac8dfe3861c3d5f77248e21592131a5423d63ff91f07956ce1aa386f8359931b5
surfboard:sandbox$ jruby -v -r openssl JRUBY-4012.rb
jruby 1.5.0dev (ruby 1.8.7 patchlevel 174) (2009-10-11 24ea053) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_15) [x86_64-java]
ed87acdcca419954edccb736f7dc77a74f5ac8dfe3861c3d5f77248e21592131a5423d63ff91f07956ce1aa386f8359931b5
Hide
Permalink
Heath Anderson added a comment -

I left out a crucial piece of code in the snippet I provided: the line that actually encrypts the string. My bad. I have attached file to this ticket that actually demonstrates the problem. The code is also pasted below. I updated to JRuby 1.4.0RC1, and I still get the same error.

-------------------------------------------------
require 'openssl'

unencrypted_data = "test"

des = OpenSSL::Cipher::Cipher.new("des-ede3-cbc")
des.encrypt
des.key = '0123456789abcdef01234567890'

des.iv = "ed87acdcca419954edccb736f7dc77a74f5ac8dfe3861c3d5f77248e21592131a5423d63ff91f07956ce1aa386f8359931b5" # 100 characters
encrypted_data = des.update(unencrypted_data) + des.final

puts encrypted_data
-------------------------------------------------

Show
Heath Anderson added a comment - I left out a crucial piece of code in the snippet I provided: the line that actually encrypts the string. My bad. I have attached file to this ticket that actually demonstrates the problem. The code is also pasted below. I updated to JRuby 1.4.0RC1, and I still get the same error. ------------------------------------------------- require 'openssl' unencrypted_data = "test" des = OpenSSL::Cipher::Cipher.new("des-ede3-cbc") des.encrypt des.key = '0123456789abcdef01234567890' des.iv = "ed87acdcca419954edccb736f7dc77a74f5ac8dfe3861c3d5f77248e21592131a5423d63ff91f07956ce1aa386f8359931b5" # 100 characters encrypted_data = des.update(unencrypted_data) + des.final puts encrypted_data -------------------------------------------------
Hide
Permalink
Charles Oliver Nutter added a comment -

What's the correct behavior? Crop the IV?

Show
Charles Oliver Nutter added a comment - What's the correct behavior? Crop the IV?
Hide
Permalink
Dylan McClung added a comment -

Yes, the openssl c libraries have a max length constant for IVs. If the IV is longer than that, it
copies only what it can handle. The same should be done for the iv= method in jruby. The max length
might be different than MRI though, we'll have to check.

Show
Dylan McClung added a comment - Yes, the openssl c libraries have a max length constant for IVs. If the IV is longer than that, it copies only what it can handle. The same should be done for the iv= method in jruby. The max length might be different than MRI though, we'll have to check.
Hide
Permalink
Dylan McClung added a comment -

Patch changes iv= to use the first ivLen bytes as MRI does.

Show
Dylan McClung added a comment - Patch changes iv= to use the first ivLen bytes as MRI does.
Hide
Permalink
Charles Oliver Nutter added a comment -

Dylan: The patch seems ok, but I'm confused why we output something different for the encoded text than MRI. We produce "c\362\003\244\370\261\253q" where MRI produces "hhH\235\240kqO". Does this seem ok?

Show
Charles Oliver Nutter added a comment - Dylan: The patch seems ok, but I'm confused why we output something different for the encoded text than MRI. We produce "c\362\003\244\370\261\253q" where MRI produces "hhH\235\240kqO". Does this seem ok?
Hide
Permalink
Dylan McClung added a comment -

Thanks for catching that, I reversed the order of the arraycopy arguments, the updated patch corrects this.

Show
Dylan McClung added a comment - Thanks for catching that, I reversed the order of the arraycopy arguments, the updated patch corrects this.
Hide
Permalink
Hiroshi Nakamura added a comment -

Merged a commit from Dylan McClung at 3182ea3a.

Show
Hiroshi Nakamura added a comment - Merged a commit from Dylan McClung at 3182ea3a.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.