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.
Related
I am developing a tool to encrypt one or multiple files using PGP.
So far, I had no problem to encrypt a single files.
For encrypting several files, I had to resort to zip them in a single file, and then encrypt the single file.
However, I know that Symantec PGP can encrypt several files inside one .PGP file, without having to zip multiple files.
I think this is a more elegant solution, as one does not have to decrypt and unzip (two steps), but only open the PGP file and then select the files.
I have only found examples to encrypt a single files, but no information on how to encrypt several ones.
For the record, I am using BouncyCastle.
I fear there is no way around using ZIP compression before encrypting.
While you could use multiple Literal Data Packets (one per file) inside your message, section 11.3 of RFC4880 hints that there can only be a single Literal Data Packet per message. This is also the interpretation of the OpenPGP Interoperability Test Suite which shows that quite a bunch of implementations reject messages with more than one Literal Data Packet.
Going with ZIP is your best option here.
I have a keystring which allows customer to have additional features.
Obviously I would like the software to check that this string is valid, and not modified.
Is the following idea feasible:
get the key string as encrypted value, and encode it in Base64
(my encrypted string is around 100 characters, for my purpose)
calculate the checksum (MD5) of course using a private salt.
weave the checksum into the encrypted data
In principle :
xxxxCxxxxxxCxxxxxxxxCxxxxxxxxxxCxxxxxxxxxxxxxCxxx
the places to weave into the encrypted data could be determined by first cher of the encrypted, creating up to 16 different patterns.
On checking the code validity I simply "unweave" the checksum, test if it's correct, and thereby know if the data has been modified.
Is my line of thoughts correct ?
The cryptographic feature you're thinking of is called "authentication," and there are many well-established approaches. You should strongly avoid inventing your own, particularly using a long-outdated hash like MD5. When an encryption system is authenticated, it can detect changes to the ciphertext.
Your best approach is to use an authenticated cipher mode, such as AES-GCM. Used correctly, that combines encryption an authentication in a single operation. While decrypting an authenticated scheme, the decryption will fail if the cipher text has been modified.
If you don't have access to AES-GCM, the next option is AES-CBC+HMAC, which uses the more ubiquitous AES-CBC with a random IV, and appends a type of encrypted hash (called an HMAC) to the end of the message to authenticate it. In order to authenticate, you need to remove the HMAC, use it to validate that the cipher text is unmodified, and then proceed to decrypt normally. This scheme is generally called "encrypt then MAC."
The implementation details will depend on your language and frameworks.
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'm trying to crack winrar's password using some methods as explained below.
Because rar uses AES-128 encryption, brute-force and dictionary attacks are useless as they would take years.
But, if we convert a password-protected rar file into an SFX archive (I'd prefer to winconsole because GUI takes much memory) that is an EXE format, I'm quite sure that it would be out of protection from winrar's gates.
Even then rar writes the encryption keys to that exe file.
So, if we could use an exe debugger or disassembler, can't we knock out the key that contains the password?
I used w32dasm, olly dbg & pe explorer to modify these exe files.
All I could find are the strings like "Extracting, CRC failed, Encrypted" and some other things. I used several sfx archives as test files (with different passwords) and tried it through disassembly. Those hexadecimal keys are looking quite similar!
So do I need a better disassembler or debugger? OR, someone tell me that if this method is useless and why?
Another question.. Does this following image has any link to winrar encryption? If yes, please explain how.. It would be very helpful.
When you create a password-protected SFX it does not store the password. It asks you for it.
You can't just "convert" password-protected content into not-protected content. If that was possible the encryption scheme would be completely worthless.
I think the problem is that trying to change the file to an SFX does nothing to decrypt the already encrypted content of the file hence it won't work. The data is already encrypted. Unless the data is NOT encrypted, then you would have to undergo the decryption process to get to your data no matter what you did to the file. No?
It is not easier to attack an SFX file versus a RAR file. A RAR archive consists of your compressed and (optionally) encrypted data. An SFX file is, like RAR, a package of compressed and encrypted data, but it also includes a miniature form of WinRAR that can decrypt the packaged data after the user enters the password.
The SFX file needs your password to decrypt your data; when you enter the wrong password, it's not because it tested your password against one embedded in the file. It means that when it tried to decrypt the data with the supplied password, something went wrong. This is all due to the magic of symmetric-key cryptography: the ciphertext (packaged within the RAR/SFX archive) goes through the AES decryption using the password you entered and the result (plaintext) is exported to whatever location you chose.
In conclusion, you'd have the same luck trying to break an SFX file as you would with RAR archive.
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