2

I am looking for a cross-platform way to encrypt credentials I need to send to a client.

I know encrypted zip archives leak metadata and can be tampered with, but how strong is the encryption cypher?

zip -ejr "/path/to/folder.zip" "/path/to/folder"
7
  • Apparently encryption is done using ZipCrypto which is pretty broken.
    – sunknudsen
    Aug 20 '20 at 13:03
  • "cross-platform" is not your biggest problem. It's whether the client has the function to decrypt (whatever that way is). GPG is cross-platform, but not every client has it pre-installed. So, are you looking for a cross-platform method or a method that pre-exists on every platform?
    – schroeder
    Aug 20 '20 at 13:07
  • I am looking for a compromise between security and convenience so a client with little to no technology skills can decrypt the archive (PGP is probably too complicated, same for VeraCrypt).
    – sunknudsen
    Aug 20 '20 at 13:08
  • 1
    Encryption is too difficult to get right "by default". There isn't a default way to make it work for non-technical users. That's why it is normally handled in a lower layer in the OSI stack to abstract the user from the process.
    – schroeder
    Aug 20 '20 at 13:33
  • 3
    Consider 7-Zip which has broad cross-platform support and whose default encryption doesn't suck. Recipients may need to install it but there's also a PortableApps version which may make that easier.
    – gowenfawr
    Aug 20 '20 at 15:34
1

You wrote: "I am looking for a cross-platform way to encrypt credentials I need to send to a client."

You do not define what you mean by "cross-platform." Your best solution is *not to use zip.

If "cross platform" means "Windows and Mac," then your best solution is to use Microsoft Word's encryption or Adobe Acrobat's. Both systems use AES in their most recent incarnation.

If "cross platform" means "Windows, Mac and Linux," then use Acrobat.

In either case, you will need to exchange a high-entropy encryption key for the document with your client. That is, you will need to exchange a password in order to exchange your encryption key. Of course, if you can do that, you might as well just send the credentials themselves using this out-of-band mechanism, no?

So what you really want to do is to use public key cryptography. That is, you are probably best off having your client spin up an S/MIME certificate and send your client encrypted mail using Apple Mail or Microsoft Outlook or Thunderbird or any of the other cross-platform approaches for using S/MIME. You'll find details in NIST SP800-177, "Trustworthy Email."

Other people will suggest that you use PGP. I won't, because it's too hard to use. But if you want to use PGP, give it a try!

If all of this sounds like too much work, you could go low-tech and put the credentials in an envelop, sign your name across the back of the envelope, put that in a second envelope, and send it to your client through postal mail.

0

zip format can use an old, weak encryption method, and AES encryption (128, 192 or 256 bit keys).

You can read the AES Encryption Specification for the details.

The command line zip client is almost surely used the traditional zip encryption, which you don't want to use.

I do like the solution, when targetting non-technical users of sending AES-encrypted files, since:

  • Generally users are have used zip files in the past, and are familiar with them. You are not "insisting on using a weird format".
  • You can force the secure encryption (AES) at your side (this could be a problem if they would also needed to send you back an encrypted zip).
  • If they use a client without AES encryption support, the error message will clearly say "You need a newer version to open zip files format X.Y". This points the user to a problem with their software, not the sender.

As a way to create a zip file using AES encryption, you can use 7-zip (you would want at least version 19.00), from the command line that would be:

7z a -p -mem=aes256 -tzip "/path/to/folder.zip" "/path/to/folder"

You could create a simple shell script for that:

#!/bin/sh
7z a -p -mem=aes256 -tzip "$@"

Limitations:

Obviously, you will be leaking metadata such as file names, file sizes (before and after compression), timestamps... If your only concern is to share some credentials, I would recommend not compressing the contents (store method), to avoid BEAST-like information leaks, but these issues don't seem too problematic. You still need to somehow securely share with the customer the zip password, though. And I wouldn't be surprised if they then saved the extracted file with the plaintext credentials on their desktop.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.