- Winzip's 256bit-AES encryption & self-extracting files
- Posted by Bakko on December 29th, 2007
I am thinking of using Winzip 11 to send some files securely and will
use Winzip's 256bit-AES encryption.
My recipients may not have Winzip, so I will use Winzip to make a self-
extracting archive.
Would a 256bit-AES self-extracting archive with be more crackable than a
256bit-AES ordinary zip archive?
- Posted by Sebastian G. on December 30th, 2007
Bakko wrote:
Yes, trivially, under the assumption of a modifying attacker. He could
modify the SFX part to transmit the password the user entered, then either
rewrite itself to the original SFX module or rootkitting the target system
to present itself as the original SFX. With the transmitted password, he can
decrypt the content.
- Posted by VanguardLH on December 30th, 2007
"Bakko" <duff@nomail.invalid> wrote in message
news:Xns9A15D34F3C0AB64A18E@127.0.0.1...
So how are you going to transmit the password for the recipient to
decrypt the file that would be just as secure as the encrypted file?
Since it sounds like you will be sending the file via e-mail to the
"recipients", have them get an e-mail cert, they send you their public
key, you use it to encrypt your file, and only they can decrypt it
using their private key. Otherwise, are you going to send them the
password in the clear in the same e-mail as has the attached encrypted
email? Are you going to send the password in a different email
despite the same malcontent that is sniffing your traffic to get the
encrypted attachment would also be sniffing it for another email with
the password? Call them over an unencrypted phone call? If you
password encrypt the file, just how are you going to get the password
to the recipient?
- Posted by Bakko on December 30th, 2007
On Sun 30 Dec 2007 09:41:20, VanguardLH wrote:
Hello VanguardLH, I wrote "recipients" (in the plural) because this
requirement comes up time and again with different people. But I'm
NOT sending the same file to a group of recipients. There is just
one recipient at a time.
The reason for securing the archive contents is that the data will be
sent on a CD and put into normal snail mail.
Although the data is sensitive it has no real value. The data is a
bit like someone's medical data. No one else has any use for it.
But if gets lost in the post then it will be very embarassing for the
person concerned!
I will phone the recipient with the password because the chance seems
vanishingly small of someone eavesdropping on my phone line for the
password to that sort of data.
My concern is that if the CD gets lost then maybe someone could crack
open the data if they were inquisitive?
That's why I want a very high level of data encryption. My question
to the group is if a high level of encryption is used (like AES-256)
as part of a SELF-EXTRACTING file then does the encryption provided
by AES-256 get compromised?
Do you have any info on this?
- Posted by Sebastian G. on December 30th, 2007
Bakko wrote:
As I already said: You should worry much more about the CD being replaced
with a modified CD by the attacker.
- Posted by VanguardLH on December 31st, 2007
"Bakko" <bakko@nomail.invalid> wrote in message
news:Xns9A16B548F71F064A18E@0.0.0.0...
Unless the NSA has you targeted, it is near impossible for any normal
user, even a hacker, to get at the contents of your encrypted .zip
file. For NSA, you'll probably expire when they crack it. I'm sure
there is a site somewhere that gives estimates of how long to crack
every possible combination for the different seeds and their lengths
that you could specify based on computer equipment that could handle
so many attempts per second but it's nothing of interest to me so I
can't give you one which means you'll have to Google for it. Remember
that when estimates are given as to how long it takes to crack an
encrypted file that it is an average, not for exercising all possible
combinations, and could even be cracked on the first combination.
A lot has to do with how strong you make the password used for the
seed in the encryption. Obviously if you used the recipient's name
that is listed on the envelope containing the shipped CD then it would
be pretty easy to crack that CD. Using their patient record, driver's
license, home street address, phone number, social security number,
and any other personal info that was associated to that recipient
would also be poor choices since someone else could obtain that info
and use it to decrypt the file. You really should use a random series
of alphanumeric characters (along with some non-alphanumeric
characters if the program permits them). If an attacker is getting in
within a time frame where the data still has some value to the
attacker then they are going to go with using all the personal info as
the password as they can dig up on the recipient or owner of that
file.
- Posted by nemo_outis on December 31st, 2007
"VanguardLH" <VanguardLH@mail.invalid> wrote in
news:BqidneS_YYnfqeXanZ2dnUVZ_gadnZ2d@comcast.com:
Truer words were never spoken! The password is almost always weaker than
the algorithm.
For example, to match the strength of a 256-bit encryption algorithm,
assuming truely random sequences of characters, you would require a
password at least 55 characters long if only lower-case was used, 45
characters long if upper-case and lower-case was used, 43 characters long
if upper-case, lower-case and numbers was used, and 39 characters long if
all 95 printable ASCII characters were used.
If the password consists of sequences of English words (Shannon entropy of
1.3 bits/character or so) then a passphrase 197 characters long would be
needed (to match the strength of a 256-bit encryption algorithm)
Very few real-world passwords/passphrases are anywhere close to this.
Regards,
- Posted by Sebastian G. on December 31st, 2007
VanguardLH wrote:
WTF? It's a triviality.
Within milliseconds?
Who cares? You get the right combination on the first hit.
Not in this case.
- Posted by Chris Cheney on December 31st, 2007
On Sun, 30 Dec 2007 17:49:15 GMT, Bakko wrote:
WTF?
--
621 NW 53RD ST - STE 240; Boca Raton, FL. 33487
www.QualifyMe123.com We finance *anyone* 110%
"The trick is in tricking the Lender; we're the best !! "
{C} 954-242-5638; {P} 561-995-1469 x 322; {F} 561-995-1489
- Posted by Bakko on January 3rd, 2008
On Dec 2007 , Bakko <duff@nomail.invalid> wrote:
On Mon 31 Dec 2007 00:13:53, VanguardLH <VanguardLH@mail.invalid>
wrote:
Vanguard, I may not be making my question clear enough.
I accept that AES 256 is plenty secure enough and that Winzip's
implementation of it is good for .ZIP files.
The QUESTION I am asking is this:
Is the security of an AES 256 self-extracting
zip .EXE as good as an AES 256 .ZIP file?
I would like to know if a self extracting EXE has any weaknesses
compared to a ZIP (when both are encrypted).
- Posted by Bakko on January 3rd, 2008
On Sun 30 Dec 2007 00:08:54, Sebastian G. <seppi@seppig.de> wrote:
Could this problem be overcome by having the PC disconnected from the
Internet?
- Posted by Sebastian G. on January 3rd, 2008
Bakko wrote:
Most likely not, due to covert channels. Video display, audio noise, varying
power consumption, ...
- Posted by VanguardLH on January 3rd, 2008
"Bakko" <nope@nomail.invalid> wrote in message
news:Xns9A1ACF8D8224864A18E@0.0.0.0...
The contents (payload) first get zipped using the encryption. Then a
wrapper is used which is the .exe file. There isn't any protection on
the wrapper. Anyone can run it. However, they will still get queried
for the password to decrypt the payload - the same password that must
be used if all that got delivered was the .zip payload. Whether you
use a separate unzip utility, like Winzip, 7-Zip, UltimateZip, or you
use a wrapper .exe that was included in the delivery, the payload is
just as encrypted.
The .exe wrapper isn't what gets protected. It's the .zip payload
that is encrypted. The wrapper is literally just tacked on with the
payload as a huge data section of the program.
- Posted by Bakko on January 13th, 2008
On Thu 03 Jan 2008 23:11:32, VanguardLH <VanguardLH@mail.invalid>
wrote:
Vanguard, that's a very useful reply. Thanks.
I understand there is (1) a wrapper and (2) a payload.
Where does it keep the routine for testing the user-entered key?
Is the key-test actually a part of the payload or is the key-test a
third component (which is accessed by the dialog/prompts of the
wrapper)?
- Posted by Sebastian G. on January 13th, 2008
Bakko wrote:
The routine is in the wrapper, the value to check against is considered as
payload. Typically a salted hash to check for key pretty fast, and then a
keyed MAC for integrity of the rest of the payload.