Scripts send encrypted email to Spamcop

Jesse Norell wrote:

>   What I've found is that if you have literal_key
enabled when you
> encode the data, it can't be decoded by perl (or I
haven't figured out
> how to, at least).  If you disable literal_key then
perl can decode it,
> but the php interface breaks.

After some experimentation, I'm increasingly convinced that
Crypt::CBC
2.17 and later are simply broken, specifically with regard
to the way
the random initialization vector is handled by the decrypt()
method when
a literal key is supplied.  As you say, specifying
literal_key and
randomiv works fine for encrypt(), but not for decrypt().

There /is/ a workaround, but it involves foregoing the
random
initialization vector in favour of a static one, and not
prepending it
to the encrypted data.  In other words, doing something
like:

  $cipher = Crypt::CBC->new( { 'key' => $key,
                               'cipher' => 'Blowfish',
                               'literal_key' => 1,
                               'padding' => 'null',
                               'header' => 'none',
                               'iv' => substr($key, 0, 8)
                             } );

This requires that the IV be known at both the encrypting
and decrypting
ends, of course, so it effectively becomes just another sort
of key.
Rather than store it as a secondary key, it could as easily
be
interpreted to be the first 8 characters of $key, without
any loss of
security (the alternative of prepending a random IV is no
more secure,
since the fixed-length IV in that case is prepended anyway).

The only problem that remains with this solution is that
without the
'RandomIV' header there's no convenient way for the
decrypting side to
tell whether an item is encrypted or not.  The routines in
process-quarantine-sub.pl and encrypt.php look for the
'RandomIV' string
at the beginning of the data to determine whether the
contents need to
be decrypted, but without that marker it's harder to
determine.  To fix
this, we may need to insert our own replacement marker
prefix, e.g.
'ENCRYPTED:' or somesuch, and be sure to ignore that prefix
when
submitting the data to be decrypted.

I'll do some more testing this weekend to ensure this
solution works,
and that a backward-compatible decryption routine is
provided to handle
items that have already been encrypted with 'RandomIV'
prefixes.  The
result should hopefully be a "universal" solution
that works both with
older Crypt::CBC versions and the newer, broken ones.

-- 
Robert LeBlanc <rjlrenaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamail
guard.com/>

_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users