FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 05-15-2008, 02:09 PM
"Douglas A. Tutty"
 
Default files encrypted with openssl enc?

Hello,

Does anyone know if files encrypted with openssl's enc would be affected
by the openssl fiasco?

What a pain in the but this is...

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 05-15-2008, 10:52 PM
Kevin Buhr
 
Default files encrypted with openssl enc?

"Douglas A. Tutty" <dtutty@porchlight.ca> writes:
>
> Does anyone know if files encrypted with openssl's enc would be affected
> by the openssl fiasco?

Yes, there is an effect, though it may be of limited practical
significance. If you used a strong passphrase and the CBC mode of
encryption (e.g., "-aes-128-cbc" or "-aes128", which defaults to CBC),
then your file should be safe. If you encrypted multiple files with
the same passphrase, an attacker may be able to tell when the
beginnings of two files match but should not be able to decrypt the
files.


The bug only affected random number generation, so for symmetric
encryption, this should only affect the random salt used.

The man page says that, by default, no salt is used, but that's wrong.
By default, OpenSSL *does* use random salt. The bad OpenSSL would
presumably have used salt from a limited set of possible values. This
is still much better than using no salt at all, but not as good as
using salt from the full set of intended values.

The passphrase and salt are used together to produce the actual key
and initial value (IV) for encryption. The main implications of using
salt from a limited set are that:

1. It's more feasible for an attacker to perform precomputed attacks
from a dictionary of passphrases.

2. It increases the chance that two files encrypted with the same
passphrase will use the exact same key and IV.

For point #1, it's not an issue for a targetted attack on a specific
file. It might be worth some people's time to perform this type of
precomputation if they're in the business of examining many OpenSSL
encrypted files every day, but if you aren't presently worried about a
visit from the NSA, I think there's little reason to worry about this.

For point #2, *if* this happens (two different files encrypted with
same key and IV), the impact depends on the block cipher mode used.
If you used OFB mode (e.g., -aes-128-ofb), security is destroyed. If
you used CFB, information about the first encrypted block (128-bits
for "-aes-128-cfb") of the files may be leaked. Neither ECB nor CBC
modes leak information in this manner.

However, for any mode (including ECB or CBC), an attacker can tell if
two encrypted files (using same key and IV) have the same beginning or
not. And for ECB, the attacker can tell whether or not any two blocks
are the same. This is a big problem if the attacker gets the
plaintext of one of the files, because he can use it as a "dictionary"
to decode blocks of the other file, regardless of where they appear.
For CBC, the attacker is limited to determining if the beginnings of
two files match. After the first difference in the files, he can't
mount a useful attack.

I hope that helps. You should probably double-check on an appropriate
OpenSSL list or something if you're really concerned, though.

--
Kevin Buhr <buhr+debian@asaurus.net>


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 08:49 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org