On a unix system, I encrypt a file file1 using OpenSSL AES-256-CBC: openssl aes-256-cbc -a -salt -in file1 -out file1.enc -k secret
The decryption is done via openssl aes-256-cbc -d -a -in file1.enc -out file1.dec -k secret
Is there a way to verify that, before actually starting the decryption process, the secret is correct?
My research has not shown any helpful results so far.
If all you have is the encrypted data it is impossible to determine if the key is correct prior to decryption. It is also impossible to determine if the key was correct after decryption other than by examining that the data make sense, is what you expect.
You would have to add some other method to determine if the key is the correct one.
What you are asking for is a check for integrity and/or authenticity. AES in CBC mode does not provide these features, only plain encryption/decryption.
If you need it you should switch from CBC to GCM mode. It provides authenticity and integrity check while decrypting. Therefore if the decryption succeeds you are sure that the decryption result is correct.
If this is your entire system, then no, OpenSSL does not have any mechanism to check the password prior to decryption (or in many cases even after decryption). You can build such a system, however, and can even build it out of OpenSSL if you're restricted to that.
If we were building it out of OpenSSL, then the absolute simplest way to solve it is to just encrypt some know piece of data with the same password. Glue the encrypted known-plaintext and the encrypted actual-plaintext together. You can glue them together many ways; the simplest in commandline form would be to stick them in separate files and then tar them together.
When you're ready to decrypt, tear them back apart, and try to decrypt the known-plaintext. If it decrypts correctly, then you're golden and you can decrypt your real data.
OpenSSL does not have a particularly strong KDF, so this approach can make brute-force password cracking a bit easier (though no easier than if your file has some known header).
This doesn't ensure that the ciphertext is unchanged, however. An attacker could still have modified it and OpenSSL won't always know. There are ways to fix that problem by modifying the format further, but again openssl doesn't provide any direct way that I'm aware of. The best approach here would depend on your exact constraints.
Related
I have a 200GB encrypted file as aes256.
I believe the password is one of 10 however it takes 5+ hours to decrypt currently before it gives an archive failed message in terminal.
my command is:
openssl enc -in ~/path/file.tgz.aes256 -aes-256-cbc -d -k password | tar -zxv -C ~/Desktop/location/
Is there a command I can run to quickly test archive with different passwords to ascertain the right password to use (brute force, essentially, but with a library of 10 passwords).
Decrypt the first part of the file data specifying no padding, it will need to be a multiple of the block size (16-bytes for AES). Then check if the decryption succeeded by looking at the decrypted data. It will either be what looks like random bytes or the correct data.
But your decryption is very slow, I can decrypt 200MB/s on an iPhone so 200GB would only take about 15 minutes plus the time to read the 200GB from disk. You may need to find another implementation that takes advantage of the Intel AES instructions (AES-NI). Software only decryption can be up to 1000 times slower.
I tried running travis encrypt "some secret string" multiple times in the same repository, and it returned different encrypted strings each time. Does Travis use probabilistic encryption? If not, what am I doing wrong?
Edit: if there is an IV, how is this IV agreed upon by my local travis cli and the Travis servers? Can I view or change it?
See Probabilistic Encryption WRT block ciphers .
An example of different results encryption the same data in a block based encryption algorithm such as AES and CBC mode with a random IV. The IV can be prefixed to the encrypted data and the encrypted data will be different because there is a different IV each time the same data is encrypted, this is a common and good standard practice, the IV does not need to be secret.
If the IV can be prepended to the encrypted data it is available for decryption, no prior agreement ios required.
Here is CBC mode, notice that the IV is xor'ed with the first block of data and each subsequent block is xored with the previous encrypted block. Thus the IV affects every block of the encrypted data.
This is done so that two identical messages will not have the same encrypted data. Consider the case where one of two messages is sent on an on-going basis: "0" or "1" where 0 meant sell and 1 meant buy. If the encryption were the same each time even though the message themselves could not be determined the two states could be determined and which one it was.
Travis-ci uses aes-256-cbc for it's Automated Encryption.
There are other encryption options such as asymmetric encryption such as RSA that can use random padding.
I've got a situation where the source system has PGP installed, and they can only encrypt the file with PGP tool, and Target System has GPG installed, and we can decrypt only using GPG. is is possible to accomplish this functionality ?
The thing with encrypting is the encryption algorithm you're using. These algorithms are published and documented - and that means anyone can write code to implement it.
PGP is a piece of software written to implement a crypto algorithm. GPG is the Gnu implementation of the same.
So there's no reason to think this wouldn't work - as long as you use an algorithm that both products support. I believe GPG has more options than PGP.
From:
http://en.wikipedia.org/wiki/GNU_Privacy_Guard
As of versions 2.0.26 and 1.4.18, GnuPG supports the following algorithms:
Pubkey: RSA, ElGamal, DSA
Cipher: IDEA (from 1.4.13/2.0.20), 3DES, CAST5, Blowfish, AES-128, AES-192,
AES-256, Twofish, Camellia-128, Camellia-192, Camellia-256 (from 1.4.10/2.0.12)
So as long as your encrypting application uses one of these it should work fine. (RSA is probably a pretty good bet.)
Currently i am encrypting sensitive files using the following OpenSSL Command:
openssl aes-256-cbc -a -salt -in large_file.zip -out large_file.zip.enc
and to decrypt:
openssl aes-256-cbc -d -a -in large_file.zip.enc -out large_file.zip
This is working fine so far, but being as i don't have much experience with encryption and cryptography i'm looking for some insight into if this is the best way to do things.
Am i encrypting/decrypting the file correctly?
Am i making full use of AES-256 this way?
Am i doing something wrong here that may impact the security of the encrypted file?
Comments/Replies are greatly appreciated.
Daniel.
PS: I'm not quite sure if this belongs in superuser or stackoverflow, please advise.
It can be secure, given the password is secure enough, and given that you only expect confidentiality. It is impossible to say if anything is secure without the use case, threat model and specific system setup though.
The OpenSSL password based key derivation methods are secure, and so is AES-256 in CBC mode. That said, modern crypto often uses some kind of integrity/authentication as in a secure mode of encryption such as GCM or by adding a MAC (using a separate key).
It's more something for http://security.stackexchange.com, although you may get closed/voted down if you don't show enough research etc.
I am trying to use asymmetric encryption to encrypt firmware. The bootloader will decrypt and update the flash. This is on a embedded device with 32 bit CPU executing at 60MHz.
I want to use ECC due to its varies advantages. I am new to encryption and my understanding os ECC as implemented in ECIES is to use ECC for the key generation and use AES for actual data encryption. Due to code and ram size, I cannot support multiple encryption algorithms.
Is there a implementation of ECC that can be used just like AES. All I am looking for is to use a "Private key" to encrypt firmware and the bootloader uses "Public Key" to decrypt it.
Thanks.
I'm not sure that you completely understand what ECIES consists of:
http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme
That's quite a bit of work, and it requires a whole lot of primitives, including at least one symmetric primitive, it seems to me. That might as well be AES.
Let's start from the last sentence of the question:
All I am looking for is to use a "Private key" to encrypt firmware and the bootloader uses "Public Key" to decrypt it.
There's some confusion in terminology here. Private keys are used to decrypt (or sign) and public keys are used to encrypt (or verify). If I understand correctly, what you want is for the bootloader to verify a signature on the firmware so that only a firmware that was properly signed by yourself will be accepted by the bootloader.
There are various asymmetric signature schemes which can be used for this purpose, including some which are based on eliptic curve cryptography. For example you could use the OpenSSL implementation of ECDSA (see http://www.openssl.org/docs/crypto/ecdsa.html).
I'm afraid there's not enough information in the question to properly choose the best signature scheme (and possibly an encryption scheme as well if there is a need to keep the firmware secret). In any case, good cryptography is not enough to make a system secure and other considerations such as secure implementation are no less important.
If this is is something that is important for you to protect and that you are worried that hackers may try to break, I would strongly advise procuring the services of a security professional. Using cryptography correctly is a very tricky business that requires a full understanding of the system - otherwise you may find yourself in a situation like this
If you look for "authentication" you have to use asymmetric algorithm like EC, this usually done because if the user or process want to update the "firmware" he should identify him self to the bootloader by his "signature" to check who request this update.
After that is done, the bootloader will load the symmetric key from a secure memory to decrypt what you want to do.
So, you have a symmetric key for encryption (AES), and asymmetric two keys for authentication (=Who are you?).
Note: there is no advantages of EC on 32 bit CPU executing at 60MHz for Encryption, unless your application need asymmetric for Encryption NOT authentication, this happen due to line between the user and bootloader is not secure.
Therefore, you could use bootloader's "public key" to encrypt firmware and the bootloader uses its "private Key" to decrypt it, however, the implementation cost a lot due to the high computing for asymmetric algorithm.
Look for "lightweight cryptography", it is typical for your application.