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
Related
Actually I'm working on some encryption/decryption algorithm. I have hard coded it in python and I want to experiment it. So what is the best way to establish a text communication in windows. Like communication between two virtual eniviroment or something. If my question is not clear please let me know. I can say simply that i want to test my encryption/decryption algorithm through a plain text chat medium with minimum two users.
I ran my code in my system and code in working prefectly here. Like if we give input as plain text you will get output as encrypted output and decrypted output. I want to try same code with in two users chat encryption/decryption lively.
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?
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.
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.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Could any please tell me how I can take in a 16 character string and generate a 16 character encrypted string ( In human readable format ) using command line tools.
I have explored options like openssl but I am not able to control the length of the output.
Could anyone please advise?
There is a description of ROT13 in Linux here. I have not tested it:
$alias rot13="tr '[A-Za-z]' '[N-ZA-Mn-za-m]'"
That may meet your needs, though it is not at all secure.
echo "abcdefghijklmnop" | gpg --armor -c --output -
However, this will not break down into your 16 character limit.
Resulting output:
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux)
jA0EAwMCnM6hI0xpVVFgyScCfr6Zo2fZeuiVWteZKeptcvSBj9wxk2gRMqTERtz9
8dNUHZq2eRA=
=Jpku
-----END PGP MESSAGE-----
I don't know where this will be used an what are the details of your security requirements, so I'll answer based on the information you gave. You require:
strong encryption;
output must be the same size of the input;
output must be human-readable.
If you give up any one of those requirements, it's easy. If not, it's hard -- if not impossible with standard Linux/Unix tools.The standard block ciphers will encode data in blocks, so they do have the same size for input and output -- but they transform bit sequences into bit sequences, and there is no guarantee that the output will be "readable". You can then encode the output in HEX (base16) or base64, but that will expand it (that's what UtahJarhead meant by "will not break doen into your N character limit").
Possible solutions (each breaking one requirement) are:
Use weak encryption (a substitution cipher like ROT13 -- or, if you want something a bit more sophisticated, implement the Vigenère cipher, but you'd have to code it -- or trust someone else's implementation);
encrypt using AES or some other good block cipher (via OpenSSL, as you mentioned), then run base64 on the output;
encrypt using AES or some other good block cipher (via OpenSSL), but don't expect anyone to read the output.
One last point: an encryption scheme is something hard to devise and to implement and there are too many subtleties involved, so creating an ad-hoc encryption method is not recommended at all...
edit: as mentioned in a comment to another answer, you could implement a one-time-pad, but you'd need paswords as long as the text, and each character of the password would need to be chosen with uniform distribution over the alphabet. Hashing the password, encoding as ascii and taking the first n characters is probably good enough [1].
Anyway, remeber that is the plaintext is too short and it can be "tested" (like passwords to sites or to encrypted documents), the adversary can do an exhaustive search.
[1] Some cryptologists will not agree that you can consider the output of a hash function as "random" (you'd be using the "Random Oracle model"). The encoding of the hash must be such that, given a uniform distribution of bits in the input, there is a uniform distribution of letters as output. When you combine this "pad" with the message, it must be a one-to-one mapping, so the distribution of the final output is uniform.