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.
Related
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
Working with Linux 3.2, I would like to implement a UID algorithm using /dev/urandom.
There may be a chance of reading 16 random bytes twice, and getting the same result. But is the chance small enough to be negligible?
/dev/urandom is supposed to be a random device that should look uniformly random, and in a uniformly random sequence you would expect to find repeated patterns. However, since there are 2128 possible 16-byte sequences, this should happen with probability 2-128, which is vanishingly small.
That said, /dev/urandom is not known to be cryptographically safe and there may be attacks that aren't in the open literature to force the behavior to degenerate (perhaps some government agency knows how to do this, for example). From the man pages:
A read from the /dev/urandom device will not block waiting for more
entropy. As a result, if there is not sufficient entropy in the
entropy pool, the returned values are theoretically vulnerable to a
cryptographic attack on the algorithms used by the driver. Knowledge
of how to do this is not available in the current unclassified
literature, but it is theoretically possible that such an attack may
exist. If this is a concern in your application, use /dev/random
instead.
(My emphasis) Therefore, I wouldn't rely on this if you are trying to go for cryptographic security.
In short, if you just need random values, this is probably fine. If you want to go for cryptographic security, I would not recommend doing this.
Hope this helps!
you have a 1/2^128 chance of reading the same data, so yes - the probability is very negligible. Roughly the same probability of breaking the AES128 encryption scheme.
Assuming the values are perfectly random, due to the Birthday Paradox the probability is approximately 2-64 (the square root of getting any particular value). That is, at about 264 UIDs, the probability to find a pair becomes greater than 50%.
For most applications that should be fine.
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.
I am given a text:
Xli wigsrh qiwweki aew irgvctxih ywmrk xli pmriev gshi amxl e xlvii
erh o wmb.
I need to dechiper it. How to decipher a text without knowing which method was used to encode it? I just need some hints.
Thanks in advance.
Deciphering works by achieving the reversal of the encryption's (ciphering's) effect:
Through brute force, basically meaning "trial and error", either by hand or with automated or semi-automated tools; And usually including finding out what type of cipher you are dealing with, to make deciphering easier.
or
Through obtaining and reverse-engineering the encryption or decryption code, which is hardly ever obtainable unless the application is 100% local; Not to mention doing so is almost always completely illegal.
This applies to deciphering all types of encryption, but please notice that this considers ciphering only, and that ciphering is almost never applied alone: Things like hashing, message-digesting and obfuscation exist and are widely used along with it.
As for your specific case, it is as #nickhar mentioned: A substitution-cipher, meaning the alphabet's element's positions were rotated and/or swapped.
I won't lie to you: This is a very weak cipher that can be deciphered by hand with a little bit of word-letter-counting and guesstimation, and as such, there are plenty of automated tools out there that will decipher it with the press of a button.
But then again, I wont lie to you: If you want to really understand the stuff, get your head down, your hands dirty, and do it (decipher) yourself.
If you study and learn, you will be answering this type of question in no time! =D
Deciphering is not a big deal. You just have to check for every value of k, i.e. 25
as there are total 26 letters.
After deciphering it gives "The second message was encrypted using the linear code with a three and k six", and the K used was 4(k=4).
Is 1024 bit rsa secure, or is it crackable now? Is it safe for my program to use 1024 bit rsa? I read at http://pcworld.about.com/od/privacysecurity1/Researcher-RSA-1024-bit-encry.htm that 1024 bit encryption is unsecure, but I find 2048 bit slower, and also I see that various https sites (even paypal) use 1024 bit encryption. Is 1024 bit encryption secure enough?
Last time I checked, NIST recommends 2048-bit RSA and predicts that it will remain secure until 2030. Page 67 of this PDF has the table.
Edit: They actually predict 1024-bit is OK until 2010, then 2048-bit until 2030, then 3072-bit after that. And it's NIST, not the NSA. Been too long since I did my thesis, LOL.
What are you trying to protect? If you are encrypting something that is not terribly vital, then 1024 may be fine, but, if you are protecting something that is very vital, such as someone's medical or financial info then 4096 bits would be better.
The size of the key really depends on what you are protecting, and how long you expect the encryption to hold. If your timeframe is that the info is only valid for 10 mins then 1024 works fine, for 10 years of protection it isn't.
So, what are you protecting?
There is no easy answer to the question "is size n secure ?" because it depends on the resources of an expected attacker. This has two parts:
Resources that the attacker is willing to invest heavily depend on the situation: defeating your grandmother, a bored computer-science student, or the full secret service of some big, rich country, does not involve the same attack power. It also depends on the perceived value of the protected data.
When designing the system, you want some margin of security, which means that you will make some prophecies on how computing power will evolve in the future, and this raises the difficult question of the notion of cost.
So there are several estimates which have been proposed by various researchers and government institutes. This site offers a survey of such methods, with online calculators so that you may play a bit with some of the input parameters.
Short answer is that if you want short-term security (i.e. security is not relevant beyond, say, year 2015) and 1024 bits are not enough for you, then your enemies must be very powerful indeed. Scarily so. To the point that you should have other, more urgent trouble on your hands.
It is necessary to define the meaning of secure to get a useful answer.
Is your house secure? Mostly we make it "good enough." For example, making it harder to break in than the neighbors is often adequate. That way the thieves spend time trying to break into next door rather than your place.
It might be secure if it requires X hours to break in and the valuable content is worth Y. Converting time to money is tricky, but if it takes a cracker 100 hours of his time to break in, and the contents of your information is worth, say $100, then your data is probably secure enough.
Nothing is going to be totally secure forever. If you're that worried about it, just use 2048-bit and sacrifice speed for better security.
Besides, as the article states:
But determining the prime numbers that make up a huge integer is nearly impossible without lots of computers and lots of time.
It all depends on whether or not you think people will actually try that hard to get at whatever information you're trying to protect.
Found a recent paper addressing exactly this question:
On the Security of 1024-bit RSA and
160-bit Elliptic Curve Cryptography
version 2.1, September 1, 2009
http://eprint.iacr.org/2009/389.pdf
It is said that, currently 1024 bit numbers cannot be factored but, RSA 1024 bit (which is about 310 decimal digits) is not considered secured enough. It is advisable to use RSA with 2048 bit or more, if one needs long term security. There are too many research companies, which are well-funded, doing research and there is a chance that they would not share everything at all. So i think, we can say it is not secure at all. I mean, if one day I happened encrypt an important data, i would prefer 2048 bits or more considering the long term security and the unknown developments in that field.