as the title says, I just have the very basic question of whether or not a file (let's say a txt file in this case) can be decrypted using a program that it wasn't encrypted with?
For instance if I encrypted a txt files with GPG, could I decrypt it with AES Crypt or openssl?
Thanks for the insight.
I assume you're talking about symmetric encryption since you included AESCrypt, which only supports symmetric encryption.
While there are standard encryption algorithms like AES and DES, and there are standard encryption modes like CBC and CTR, there aren't really any standard data formats for symmetrically encrypted content. (Yes, CMS can encode symmetrically encrypted messages, but I haven't seen a product that uses it this way.)
In short, everyone winds up building their own file format. In particular, OpenSSL and AESCrypt each has its own proprietary format. GnuPG uses something very close to RFC-4880 I believe, which like CMS can encode symmetric messages, but this isn't usually used this way. I made my own format for RNCryptor because I couldn't find a good standard for symmetric encryption.
In short, the answer is almost always, for symmetric encryption, "not unless the product explicitly says its compatible with some other product."
As long as the format of the file and the encryption algorithm are supported by the program you'd like to use for decrytping your file, it will work. That much for theory. In reality, even though I'm not an expert, I'd say OpenSSL is not meant for decryption of GPG encrypted files; also, AES Crypt sounds like it does just AES but GPG is a package and can do various encryption algorithms or ciphers, including AES, and even if the ciphers match, the file formats might still be incompatible and need conversion.
There's a good book you could read to get a pretty good understanding of this sort of stuff (I know, I read it myself): http://www.amazon.com/Cryptography-For-Dummies-Chey-Cobb/dp/0764541889 .
AES is just an encryption algorithm, like ROT13.
How and in which language it is implemented doesn't matter, which makes exchanging encrypted files easy: As long as both email programs support S/MIME they can decrypt files send by a different program.
So yes, you can decrypt files encrypted by a different program. But both must implement the same algorithms, you can't open a PNG file with a program that only understands how to display JPEG files.
Related
I have to encrypt a string within an XML element with "PKCS#7-Standard and Base64 coded" and also decrypt it when I get the XML as a response.
I guess I will receive a public key for encryption.
But the more I read about it the more confused I get.
I've also found a lot of code examples in Java and PHP, but I have to do it in Perl.
For the base64 encoding and decoding I have already found the module to do so
which works fine: MIME::Base64.
What I am curious about is that the paper says the security must follow these prerequisites:
RSA-Algorithm with minimum 2048 Bit
AES – Advanced Encryption Standard [RFC 3565] (256 Bit, CBC-Modus)
SHA-256
X.509 v3-certificate (V1.0.2)
PKCS#7 – electronic signature and encryption
I am totally confused as I thought I just had to encrypt with a public key and sign with private key. I have problems in understanding the prerequisites.
Is the module Crypt::SMIME from CPAN the right one?
How could I simulate the situation by creating certificates/keys by myself for testing?
I need to generate a QR code from a PGP message. The problem is the code is coming out way too big (about 3 x 3 inches).
How can I shorten the length of the PGP message to generate the QR code?
The size of an OpenPGP message depends on:
The message itself (compressability, length)
The symmetric encryption algorithm (mainly because the cipher block needs to be stored)
ASCII armored output is much larger than the binary version, don't armor if it works without
As #Duncan already said, signing needs further space
Try different symmetric algorithms, and try whether forcing GnuPG not to compress actually makes the message smaller (as the compression headers also need a little bit of space).
To look into an OpenPGP message and see what's contained, use gpg --list-packets.
Furthermore, you can try to tweak the QR code (redundancy), or put an URL into the QR code which links to the message itself.
There's not a lot you can do really. Check your PGP message is using compression, assuming your recipients support it. Otherwise, you have very few options:
Shorten the contents of your message
Encrypt to fewer recipients
Encrypt without signing, if that suits your security model
Friends,
I am using J2ME WTK 2.5.2 for Application Mobile Development and I am using Base64 Encryption Method in join with Cipher. The Encryption and Decryption works are expected.
My problem is when I encrypt the String with Base64 Encryption or with Cipher, the Size of the String increases (ie if Original Size of String is 10 Characters, it increases size to 15 characters). I am storing some to the device itself so store space is an big issue. I looking for the Encryption method which does not increase the String Size.
Without a code example, it's not entirely clear what you are already doing. But many encryption modes (such as ECB or CBC) when combined with a padding scheme will produce encrypted data that is a little larger than the input.
If you need it to be exactly the same size, try a mode like CFB.
I am researching Cryptography. I wanted to know how one can differentiate between normal text & text encrypted by sha256 algorithm, either using python or using regular expressions.
SHA256 is not encryption algorithm, it's cryptographic hash function, so you cannot encrypt anything with it. What are you trying to distinguish?
This is very similar to another question I'm asking, but still a little different. Both questions are attacking the same problem, and I really just need one or the other answered:
https://stackoverflow.com/questions/13443236/how-can-you-make-rtmfp-encrypt-streams-using-256-bits-not-128
Basically I know that RTMFP, for the most part, uses 128-bit encryption for streaming. But is this statement just an over-generalization to some extent? Is there some particular part of the process, while streaming audio and video, specifically on which it uses 256-bit encryption?
Thanks!