Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have a big string
approx 4000 characters
i want encrypt and decypt it using MD5 because of i want to do convert in a small string please help me a lot of finding i found Base64 but it is not our solution please any one help me
my_string="abcdefghhhhhhhhhhhhhhhhhhhhhh"
Base64.encode64(my_string)
it gives us very lengthy string.
Encrypting a string will not make it smaller, it will at best be the same length. I think what you are looking for is a way to compress your string. That aside, MD5 is a one-way hashing algorithm, that means that it is designed, so there is now way of recovering the source string (it turns out that it was designed rather poorly).
MD5 is a one-way hash, you can't decrypt it.
To encode a string use Digest::MD5.hexdigest('foobar') but for most purposes I'd say use a better hashing algorithm; MD5 has been broken for a long time.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
Objective is to create a random encoded string. But I'm not a computer science major, any explanation in layman terms would be much appreciated.
irb(main):002:0> SecureRandom.base64
=> "9VpzpvCR4ww/ZQc9lN148A=="
irb(main):003:0> SecureRandom.hex
=> "29b6cd61ec3e58959b006b6d98550b97"
The difference between Base64 and hex is really just how bytes are represented. Hex is another way of saying "Base16". Hex will take two characters for each byte - Base64 takes 4 characters for every 3 bytes, so it's more efficient than hex. ... If it does matter, then clearly Base64 is better on that front.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
How to find the minimal number of bits to encode a set of known strings?
If the set of strings is known to both sender and receiver, then you need zero bits to transmit it. (In effect, the message is "Use the known set." I know that sounds silly, but it is often part of a comms protocol.)
If you need to send a single string from the set, you can send its ordinal index, using log2 N bits, where N is the size of the set.
if you are repeatedly sending messages containing a single string from the set but the frequency distribution of the messages is non-uniform, you can Hoffman-code the ordinal. That will optimize the total size of all messages over time.
I don't know exactly if you require this one but still have a look at it , it might help you . Let me know if it does:
Compression algorithm
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Is there an algorithm for handling secret words without storing them in clear text or using a reversible encryption?
Necessary operations include
getting the length of it, so that we can generate indexes
testing whether the n-th character matches a specific character
If you want to match the n-th character with another character, the encryption becomes easily reversible. An adversary just has to test all characters with all possible values. So in ASCII that will be 256*8=2048 for an 8 character password.
You should normally store a SHA-256 or SHA-512 of the password (possibly prefixed with a random salt) and compare this value against the user inputed value SHA-256/512ed.
You can also repeat the SHA-256/512 operations several thousand times to make attacks more difficult.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Bob and Alice each have a bit string they want to keep private. They each want to know what the logical AND of their two bit strings would be without telling the other or anyone else their actual bit strings... how can they do this? Keep in mind that even once they both hold the AND of their two bit strings, they should still not be able to calculate the other person's string exactly (unless of course one of their strings was all 1s).
I know that I have seen something similar before in some sort of key system/voting system but I couldn't remember the details. It has to be something like make a private random key, xor it and use that somehow... but I couldn't work out the details. Any clever encryption people out there?
I think that you are looking for homomorphic encryption systems, in which it's possible to do computation on encrypted values without ever exposing what those encrypted values are. This encompasses a far more general set of problems than simply computing bitwise AND.
Hope this helps!
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have a set of keys e.g (IENDKCAGI, RZRLBYBFH) and now I want to find the algorithm of it. I allready know the basics of cryptography but I don't know how to start reverse engeneering the algorithm.
I don't search a certain algorithm, I'm just interested how the process would look like.
cheers
EDIT: I don't want to crack any key!!! I buy the software I need!
I'm just interested in the approach of reengeneering a checksum from the result, thats my conceptual formulation, without knowing the algorythm. This topic is more theorethical, but in my opinion it has a certain relevancy also for stackoverflow
You can analyze it to some degree, at least enough to rule out several possibilities. You say you have a set of keys, and I'm not sure what you mean by that, so pretend for discussion that the left value is the plaintext and the right value is the encrypted equivalent.
You can determine that the left value has only one repeating character, "I", and that the right value has two, "R" and "B". From that you can rule out a simple substitution cipher, even one with characters rearranged.
Both values appear to have only characters in the range [A-Z] (a larger sample would help confirm), so you can rule out encryption techniques that yield binary results, like most block and stream ciphers. In fact, use of such a limited character set implies that it was designed for use by people rather than machines. That would imply a relatively simple cipher technique, but may also involve an additional key to which you do not have access.