I am doing encryption and decryption of an image using 3DES. After encrypting an image I am not able to see an encrypted image. Can any one please tell me why is this happening? I am using a jpeg image to encrypt. All this process has been done in Java.
After performing the Triple DES encryption the image is no longer readable as a JPG file until it has been decrypted. That’s generally the purpose of encryption to allow you to transfer that image and ensure it will be safe until it is read the intended recipient who has the private keys
Related
I need a way to allow multiple people encrypting various files but only one party been able to read them all. I wrote a program in Go by following various online examples but at some point I got the following error:
Error from encryption: crypto/rsa: message too long for RSA public key size
Is RSA the wrong way to go? Is it ok if I break the file into multiple chunks and encrypt them? Is there an asymmetric block cipher that I can easily use?
I read the discussion here and it is said that RSA is not the proper way to go.
Can you also provide with an example?
If you need public key asymmetric encryption for data larger than the key size you need to use hybrid encryption. Essentially this is how HTTPS works.
Hybrid encryption is where the data is encrypted with symmetric key encryption such as AES and that key is encrypted with asymmetric key encryption such as RSA or EC (Elliptic Curve) Cryptography.
Do not break the file into multiple chunks and encrypt them.
So I ended up using GPG and my service has one unique private key and I share the public one with my users.
I want to encrypt some specific property of a file like encryption type password decryption key these are custom properties.Can anyone tell How can i encrypt those properties?
The same way you encrypt any other data. Find some way to convert the various data into a buffer stream of formatted data (XML/TLV/etc.) and encrypt the buffer. Data is data.
That being said, if you're looking to transport this data along with the file, don't. That defeats the entire purpose of encryption. It only works if you do not send keys (except maybe public keys), passwords, etc along with the data. Rule #1 of encryption is keep your private keys private.
If there were a magic way to do this securely, we wouldn't need PKI.
Hello everyone now i am able to answer my question,
In Alfresco there is a bean name metadetaEncryptor inject that and use to encrypt and decrypt the data. by default it will use your alfresco keystore for key.
Want more info then comment below..............!!
I want to do searching on encrypted data. Which means that there is the need to have the same ciphertext every time I encrypt the same plaintext. I.e. think of a list of encrypted names and I want to find all "Kevin"'s in it. I would now encrypt "Kevin" and search the database for the encrypted text. All hits will be "Kevin"'s — but still only the one who has the password knows.
Now my question: What about security if I use the same salt and IV (to get the effect described above) all the time? Is the encryption still secure? Or is there any other method to do searching on encrypted data?
If you want to do a deterministic encryption then you should use an encryption mode
that has been designed for deterministic encryption (and not modify an encryption mode designed for something else).
One possibility is the SIV encryption mode described in
RFC 5297.
(Of course, deterministic encryption has its drawbacks, but discussing this is not part of this question.)
I have a csv file that required to be encrypted. I want to ask that is there any difference between encrypt the content and encrypt the file? Or they are the same? Because our client doesn't clearly specify what they want?
Thanks,
Encryption will always produce binary result, which can be "armored" (base64-encoded and wrapped) then in order to get the text. All implementations conformant to OpenPGP standard handle armored data by decoding it to binary automatically, so it doesn't really matter what mode you specify. One special case is when you plan to paste the result to some other text data (such as text document), then armoring is mandatory.
Usually when they say PGP encryption, they are talking about commercial programs that encrypt a file or files into one gpg file with their public, which they can decrypt with their private key.
The other way is encrypt it yourself line-by-line in code (there are libraries that do that using file streams; very easy).
Your client one way or another has to tell you how that expect to decrypt the data later on, which will tell you how you encrypt in the first place.
I'm a bit confused on encryption file formats.
Let's say I want to encrypt a file with AES-256. I run the file through the encryption algorithm and I now have a stream of encrypted bytes.
I obviously can write that stream of bytes to a file, but any third-party encryption application is not going to understand it since it's not expecting just a raw stream of encrypted bytes.
Into what file formats can I write that so that other encryption tools can understand it?
The ones I know of (I think) are:
PKCS#7
ASN.1
DER
PEM
PKCS#8
but I'm not sure how they all relate to each other.
Apparently the AESCrypt utility also has a format, which appears to be its own proprietary format:
http://www.aescrypt.com/aes_file_format.html
Is there a cheatsheet anywhere on this stuff? I've been googling and found bits and pieces, but never felt like I had the complete picture.
PKCS#8 is not an encrypted-file format, it's a format for private keys.
ASN.1 and DER are rules for translating a structured message into binary. They are not, in and of themselves, a file format, although they're used to define and describe file formats.
PKCS#7 is closely related to PEM, and they're both formats for public-key encrypted files. They are defined in terms of base-64 encapsulated DER encoded ASN.1 messages. They are the basis of the S/MIME format for secure internet mail. (see RFC3851)
In parallel with S/MIME is the OpenPGP file format, also mainly designed for public-key encrypted files. (See RFC4880)
In both S/MIME and OpenPGP formats, there is a block which contains symmetric-key encrypted data. It is possible to create valid S/MIME or OpenPGP files containing only this block. In this way, the S/MIME (a.k.a. PKCS#7) and OpenPGP formats can be used for symmetric-key encryption also.
AES is an encryption algorithm, not a file format.
As you point out, there are lots of knobs and levers on the algorithm - key strength is one. AES-256 just means, the AES algorithm with 256-bit key. But there are lots of other knobs. Mode, for one. AES has a number of modes: CBC, ECB, OFB, CFB, CTR, and others. Another is the IV, which applies to some modes. Padding is another. Usually these knobs are exposed in the AES api for whatever framework you're using.
In most cases AES is combined with other crypto technology - for example password-based key derivation (PBKDF2) is often used to generate keys or IVs. MAC's are often used to verify the integrity of the encrypted data.
Different tools use AES to encrypt, and if they want their data to be readable, they publish the list of knobs they use, and how they are set, as well as how any related crypto technology might be used.
When creating a file format, you'll need to store or publish those kinds of things, if you want your file to be readable by other applications.
You might want to look into Crypt4GH which was standardized at the end of 2019.
Crypt4GH, a new standard file container format from the Global
Alliance for Genomics and Health (GA4GH), allows genomic data to
remain secure throughout their lifetime, from initial sequencing to
sharing with professionals at external organizations.
From what I can see it is similar - in terms of crypto - to NaCl's crypto_box, but with the advantage of formalizing a file format on disk.
JSON Web Encryption RFC 7516 is an IETF standard that can do what you are looking for, it can handle AES in addition to other crypto algorithms.
JSON Web Encryption (JWE) represents encrypted content using JSON-
based data structures [RFC7159]. The JWE cryptographic mechanisms
encrypt and provide integrity protection for an arbitrary sequence of
octets.
There implementing of JWE in multiple languages for example in Java you can use nimbus