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.)
Related
I wonder about PKWARE Strong Encryption algorithm.
ZIP File Format Specification v6.3.5 says about Strong Encryption by PKWARE (7.0 Strong Encryption Specification). This description is not completed and it's impossible to implement this encryption in the application.
I wonder about is there any working source code using this encryption algorithm? Does not matter what language. I'm planning to add it to my own application but did not succeed yet.
P.S. This is not a Traditional PKWARE Encryption, that described in 6.0 Traditional PKWARE Encryption
To my knowledge, there are no open source implementations.
The strong encryption functionality is patented. If you have not already done so, contact zipformat#pkware.com to obtain a license.
After you have a license, if you provide more details about what you think is missing from the description, I can try to help.
Source: I'm an engineer at PKWARE
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.
what is difference between symantec command line pgp encryption and other pgp encryption tool like iGolder,GnuPG etc.
Is it possible that a file pgp encrypted by symantec command line that can be decrypt by other tool like iGolder,GnuPG, bouncy castle etc.
In general, compatibility between various OpenPGP applications and libraries is achieved by using the algorithms defined in the RFC 4880. This means that if Symantec PGP follows OpenPGP standard and doesn't use proprietary patented extensions (they do exist), the resulting file would be handled by other applications.
The other thing to check is that the algorithm used by the originating application is supported by the software that decrypts the file later. For modern versions this is not an issue, but some companies use the dated versions of PGP software, which doesn't handle some of the newer algorithms. In this case you can have an issue.
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.