Crypt::CipherSaber replacement... Crypt::CBC?

skazat has asked for the wisdom of the Perl Monks concerning the following question:

Sorry for what may be a very simple question - encryption is not my forté:

I have an old script that currently uses chromatic's Crypt::CipherSaber v0.61. For some semblance of security, when saving pass phrases in a database (this could be a Dir-based or SQL database), for later re-fetching, pass phrases are encrypted and the key saved elsewhere.

I recently made this App very UTF-8 aware and I'm seeing problems with the encrypted passwords being created by this module - it seems that some of the characters are high-bit and sometimes do not get encoded/decoded correctly - the information basically gets corrupted.

This may be because the information should be handled in *binary*, instead of text form - which means its my program doing the corruption - the backend may not have the flexibility to handle some fields (like, the encrypted password) as binary - and the rest as text.

Is there a similar module I can use as a replacement for this aging module? Is looking at Crypt::CBC looking in the right direction?

I think what I'm most interested is that the encrypted password is comprised of a string of text, rather than a binary glob.

The other parameter is Pure-Perl implementation of whatever solution seems to be the most plausible.

Help a monk out?

-skazat

Comment on Crypt::CipherSaber replacement... Crypt::CBC?

Replies are listed 'Best First'.
Re: Crypt::CipherSaber replacement... Crypt::CBC? by Marshall (Canon) on Apr 30, 2010 at 07:58 UTC
I am also not an encryption guru. I looked at specs for the module that you are using based on RC4 and it appears that this provides pretty good security. There are a lot of encryption methods and I can't recommend one over another. I personally would not assume that a few years old means "bad". I think all of these robust algorithms are going to generate binary bits (including non-printable characters). You say "what I'm most interested is that the encrypted password is comprised of a string of text, rather than a binary glob". One simple idea would be to just uuencode this binary bunch of bits so that you can store it as printable ASCII in the DB and then uudecode it back to the binary in order to run through the decrypt process which will also result in ASCII. It just seems to me that you can continue to use something that you are familiar with, the new thing being storing the encrypted binary text as a uuencoded string (printable ASCII) instead of raw binary. Just a thought from a non-security guy. I am quite sure that this discussion can get into literally mind-numbing detail. How much work you put into this has a lot to do with how important the information is and how determined the "bad guys" are at getting it. I would suspect that the pass phrase encryption algorithm is not the weakest link in the security chain.	[reply]
Re: Crypt::CipherSaber replacement... Crypt::CBC? by rowdog (Curate) on Apr 30, 2010 at 09:43 UTC
As Marshall++ said, RC4 isn't completely busted yet so it's probably fine to stick with it. If you're looking to change your cipher you might want to move to Crypt::CBC and the Advanced Encryption Standard aka Crypt::Rijndael. As far as plain text goes, MIME::Base64 might be what you're reaching for.	[reply]
Re^2: Crypt::CipherSaber replacement... Crypt::CBC? by Marshall (Canon) on Apr 30, 2010 at 11:14 UTC
I think base64 is a great way to go! Mime-Base64-3.09 looks good and is available on ActiveState also. The wikipedia has a good explanation of base64. Convert-UU-0.5201 is an older technology. See wiki at uuencoding. The main point is to get this 8 bit binary stuff into printable ASCII stuff that won't get "mangled" I found this wiki article interesting: Cipher-block_chaining.	[reply]
Re^3: Crypt::CipherSaber replacement... Crypt::CBC? by rowdog (Curate) on Apr 30, 2010 at 21:31 UTC
uuencoding looks good but Crypt::CBC provides encrypt_hex() and decrypt_hex() so I guess I'd go with hex if I was moving to Crypt::CBC anyhow.	[reply]
Re^2: Crypt::CipherSaber replacement... Crypt::CBC? by rowdog (Curate) on Apr 30, 2010 at 21:14 UTC
The other parameter is Pure-Perl implementation of whatever solution seems to be the most plausible. Oops, I missed that requirement the first time. Pure Perl implementations of ciphers will be much slower and will limit your choices. That said, Crypt::CBC + Crypt::Rijndael_PP or Crypt::Twofish_PP might work for you. I agree with hardburn that RC4 is tricky to implement correctly and should generally be avoided unless you really know what you're doing and you have a real reason to use that particular cipher.	[reply]
Re: Crypt::CipherSaber replacement... Crypt::CBC? by hardburn (Abbot) on Apr 30, 2010 at 16:02 UTC
I'm going to have to disagree with the above posters--stay away from RC4. Although it's technically not busted straight out, it's very fragile to use in practice. Microsoft has a whole list of bugs regarding RC4 going back to NT3 and up through at least the first XBox. WEP's insecurity also stems from poor use of RC4. I'd suggest going with Crypt::CBC using AES (Rijndael). "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply]
Re^2: Crypt::CipherSaber replacement... Crypt::CBC? by hardburn (Abbot) on Apr 30, 2010 at 16:46 UTC
After thinking about it some more, I can almost guarantee your system is insecure. The way stream ciphers like RC4 work is to take a key as a seed value to a pseudo-random number generation function. Each bit of output in the PRNG is XOR'd with the data (much like an OTP). The problem with this is that if you use the same encryption key twice (which I assume your password database would be, and is also where Microsoft screwed up with NT3), an attacker can easily recover the key by comparing the two encrypted values. This can also be a problem when encrypting large amounts of data with the same key (which is where WEP screwed up). The solution is to stick with block ciphers like AES. "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply]
Re^3: Crypt::CipherSaber replacement... Crypt::CBC? by Anonymous Monk on Jan 17, 2013 at 04:03 UTC
I can actually nearly guarantee his system is secure... You are correct that using the same key twice with the RC4 algorithm alone would indeed create two streams that could be used to derive the keystream. However, this is what the initialization vector is for. It's appended to the key before encryption and sent in the clear to be used for decryption. It's not part of the key (it's no secret), but it ensures that two identical messages sent with identical keys will always result in different keystreams (and ciphertext). Two examples of ciphersaber-created ciphertext cannot simply be XOR'd together to glean anything useful. The way these IV's are chosen and they way they express themselves in the ciphertext can be determined looking at a rather large number of messages with the same key. THIS is why WEP is screwed up. If you create the key array more than once (ciphersaber-2 does this), or don't use the key many times, it's secure. I know this is very old, but I can't leave a page that's relatively prevalent on Google searches with significant errors on it. RC4 with properly chosen keys is not broken by any means.	[reply]