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?
Bakko wrote:
> Would a 256bit-AES self-extracting archive with be more crackable than a
> 256bit-AES ordinary zip archive?
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.
"Bakko"
news:Xns9A15D34F3C0AB64A18E@127.0.0.1...
>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?
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?
it does not matter if it is self extracting or normal archive. AES is
strong encryption. However a lot of mail servers/clients will be unhappy
about .exe as an attachment. It is better to send just normal encrypted
zip file and advise your recipients to use freeware like 7-zip or Zipeg
'Zipeg - Got pictures? Zip thru JPEG photo archives'
(http://www.zipeg.com) to unpack them.
Regards
------------------------------------------------------------ ------------
View this thread: http://www.wirelessforums.org/showthread.php?t=35510
http://www.wirelessforums.org
On Sun 30 Dec 2007 09:41:20, VanguardLH wrote:
> "Bakko"
>>
>>
>> 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?
>>
>
> 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?
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?
zipeg wrote:
> it does not matter if it is self extracting or normal archive. AES is
> strong encryption.
Who cares if it's strong? Since nothing authenticates the SFX module, the
attacker can replace it with his own one, which, in addition to decrypting
the archive, sends him the entered password.
Bakko wrote:
> My concern is that if the CD gets lost then maybe someone could crack
> open the data if they were inquisitive?
As I already said: You should worry much more about the CD being replaced
with a modified CD by the attacker.
"Bakko"
news:Xns9A16B548F71F064A18E@0.0.0.0...
> On Sun 30 Dec 2007 09:41:20, VanguardLH wrote:
>> "Bakko"
>>>
>>>
>>> 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?
>>>
>>
>> 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?
>
>
> 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?
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.
"VanguardLH"
news:BqidneS_YYnfqeXanZ2dnUVZ_gadnZ2d@comcast.com:
> A lot has to do with how strong you make the password used for the
> seed in the encryption...
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,
VanguardLH wrote:
> 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.
WTF? It's a triviality.
> For NSA, you'll probably expire when they crack it.
Within milliseconds?
> 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
Who cares? You get the right combination on the first hit.
> A lot has to do with how strong you make the password used for the
> seed in the encryption.
Not in this case.
On Sun, 30 Dec 2007 17:49:15 GMT, Bakko wrote:
> 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.
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
On Dec 2007 , Bakko
>>
>> 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?
On Mon 31 Dec 2007 00:13:53, VanguardLH
wrote:
>
> 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.
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).
On Sun 30 Dec 2007 00:08:54, Sebastian G.
> Bakko wrote:
>
>
>> Would a 256bit-AES self-extracting archive with be more crackable
>> than a 256bit-AES ordinary zip archive?
>
>
> 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.
Could this problem be overcome by having the PC disconnected from the
Internet?
On Sun 30 Dec 2007 17:06:04, zipeg
>
> it does not matter if it is self extracting or normal archive. AES
> is strong encryption. However a lot of mail servers/clients will be
> unhappy about .exe as an attachment. It is better to send just
> normal encrypted zip file and advise your recipients to use
> freeware like 7-zip or Zipeg 'Zipeg - Got pictures? Zip thru JPEG
> photo archives' (http://www.zipeg.com) to unpack them.
AES is strong. But has Winzip incorporated AES into self-extracting
files in a way that does not introduce weaknesses.
ISTR that the early AES 256 Zip files created by Winzip had some sort of
weakness due to the way it was implemented.
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.
>
>
> Could this problem be overcome by having the PC disconnected from the
> Internet?
Most likely not, due to covert channels. Video display, audio noise, varying
power consumption, ...
Bakko wrote:
> AES is strong. But has Winzip incorporated AES into self-extracting
> files in a way that does not introduce weaknesses.
>
> ISTR that the early AES 256 Zip files created by Winzip had some sort of
> weakness due to the way it was implemented.
Your memories are corrupt, but presumably this has been fixed. According to
the latest documentation, analysis tell that there's no weakness lesser than
AES itself.
The big problem still is that the authentication only covers the archive
part, not the SFX part. The SFX part might be changed to do anything,
"Bakko"
news:Xns9A1ACF8D8224864A18E@0.0.0.0...
> I would like to know if a self extracting EXE has any weaknesses
> compared to a ZIP (when both are encrypted).
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.
Bakko
> I accept that AES 256 is plenty secure enough and that Winzip's
> implementation of it is good for .ZIP files.
Why the latter. Do you have the source code?
Yours,
VB.
--
The file name of an indirect node file is the string "iNode" immediately
followed by the link reference converted to decimal text, with no leading
zeroes. For example, an indirect node file with link reference 123 would
have the name "iNode123". - HFS Plus Volume Format, MacOS X
Bakko
> Is the security of an AES 256 self-extracting
> zip .EXE as good as an AES 256 .ZIP file?
Security in what way?
The "self-extracting" code can be modified i.e. in an MITM attack, and
so can malware code injected and run on the target machine.
For example.
Yours,
VB.
--
The file name of an indirect node file is the string "iNode" immediately
followed by the link reference converted to decimal text, with no leading
zeroes. For example, an indirect node file with link reference 123 would
have the name "iNode123". - HFS Plus Volume Format, MacOS X
On Fri 04 Jan 2008 08:18:43, Volker Birk
> Bakko
>> Is the security of an AES 256 self-extracting
>> zip .EXE as good as an AES 256 .ZIP file?
>
> Security in what way?
>
> The "self-extracting" code can be modified i.e. in an MITM attack, and
> so can malware code injected and run on the target machine.
>
> VB.
Perhaps you haven't read my original post in this thread?
On Thu 03 Jan 2008 23:11:32, VanguardLH
wrote:
> "Bakko"
> news:Xns9A1ACF8D8224864A18E@0.0.0.0...
>> I would like to know if a self extracting EXE has any weaknesses
>> compared to a ZIP (when both are encrypted).
>
>
> 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.
>
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)?
Bakko wrote:
> I understand there is (1) a wrapper and (2) a payload.
> Where does it keep the routine for testing the user-entered key?
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.
Bakko wrote:
>> The "self-extracting" code can be modified i.e. in an MITM attack, and
>> so can malware code injected and run on the target machine.
>>
>> VB.
>
> Perhaps you haven't read my original post in this thread?
Perhaps you didn't read it yourself? Telling that you want to send your data
via transfer of a physical media only came up later, and it doesn't mitigate
this thread at all (since the attacker can read out the physical media,
modify the data and write them to a new media).
And you never ever bothered about verifying its integrity via any means, so
this attack should be considered seriously.