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?
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
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.
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!
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.