Just found this website: hashpass.com and here is the JS implementation which they use to encrypt the key-value pair: http://hashapass.com/sha1.js
So, can there be a "simple" and obvious alternative to this?
Thanks
I'm not sure how secure this is. For one thing, the output is a short Base64 string. Due to its length and restricted character set, it should be easier to brute-force than a regular password that avoids the common and dictionary values while combining alpha, numeric and other.
You want it to be simpler in <what?> way? You want it to be more obvious in <what?> way?
Do you care about the cryptographic strength?
If you don't care about that, you can simply take a sum modulo 2<<32 (or something) and encode the result as 8 hex digits.
I sure wouldn't trust my logon to that kind of security , but is
simple
obvious
Related
How can I obfuscate an Int64 so that it's not obvious to know the original value? I m not looking for something terrible, some a simple obfuscation method.
Xor it with a static value. Xor again with the same static value to get the original value.
Why do you want to obfuscate it? What are you obfuscating against?
For example, if you're trying to protect a single 64-bit integer from static analysis, the xor approach will protect it somewhat. If you're looking for protection from dynamic analysis, you'll need a more complicated solution that provides anti-debugging and anti-tamper protections.
Why is this constant worth protecting? What are the programmatic constraints on this, e.g. how frequently does this value need to be revealed, just once?
Encryption with a real encryption algorithm will go further than xoring with another value and isn't actually very hard. You might use AES/CBC/PKCS5Padding (AES is a current standard algorithm, CBC is for chaining blocks (this doesn't matter with only 8 bytes of data), and PKCS5Padding is padding to allow less than the block size). There are examples all over the internet, including SO (Rijndael is AES).
This question already has answers here:
Is it possible to decrypt MD5 hashes?
(24 answers)
Closed 5 years ago.
ร encodes into 0f93821e0fbc6d3736da7df2c73024aa
I was wondering if it's possible to decode the hash back into the unicode form. If so, how can I approach this or how can I perform this.
Any help is appreciated, thanks.
m5d is a hashing algorithm, that is by nature monodirectional.
You just can't "decode" it.
The only option you have is bruteforcing.
The whole point of a hash is to present a fixed-length output for arbitrary input with the property that the same input results in the same output. Cryptographic hash functions like MD5, or SHA-1 are even designed so they cannot be reversed easily. Thus, no, you cannot do that.
Also, just as a thought exercise that shows that in the general case it just cannot work: MD5 is 128 bits long, so how could you possibly recover input that's larger than that? There are an infinite number of strings turning into the same digest, so while you could find a string that has the same hash, you're not guaranteed to find the one you started with.
Whites11 has mentioned brute-forcing, however take into account this is not 'Decoding' the hash. This is simply hashing common inputs and comparing the 2 hashes to see if they match, unless you have a set of common inputs that may actually match the hash its very unlikely you will get anywhere with it.
Hashes are intentionally mono-directional, I can't think of why you would need to either you may need to rethink the logic of whatever project you're doing.
To summarize, you can't decode a hash, this is intentional and that's why hashing algorithms exist. And brute-forcing is hashing common inputs to see if they match your hash. It's commonly used for password cracking etc. Done with common password data sets. So may not be useful in your case.
http://www.md5online.org is a good example of bruteforcing, it is a database of previously bruteforce/tested hashes and their unicode inputs. You can try hashing a basic word like "password" and throwing it in there, it should show the original unicode input if it's a known hash!
Here are 2 excellent informative videos that cover hashing algorithms and brute-forcing hashes:
https://www.youtube.com/watch?v=b4b8ktEV4Bg
https://www.youtube.com/watch?v=7U-RbOKanYs
I am fairly new to cryptography, but I have come across this :
ea706916-4d0a-460d-9778-4d1a7195b229
which looks like a familiar format. It's original value is tjotol.
Would anyone know what format the above code is in? I know that if it has hashes it can be a giveaway. Base64? HTML? Something else?
It does not look like Base64, it may be MD5 with dashes in-between. However, remember that a hash is a one-way function (ie. it's not reversible), while a cryptographic function is two-way (you can encrypt and decrypt it). Hence, it's not correct to speak about "hash decrypting". I don't know what you mean by "format language", would you care to elaborate on that?
A quick google search took me to this article that seems to be well written an covering many issues regarding your concern related to hashes being a "giveaway".
Note: Base64 is hardly an encryption algorithm, it is indeed just an encoding/representation format.
This have the format of a Globally unique identifier (GUID). Take a look here: Globally unique identifier
I am curious about developing my own Simple Hashing mechanism.
I would like to know some math functions that are irreversible.
I know that raised to function and modulus are some functions that are irreversible in the sense that the reverse procedure gives two answers.
e.g.:- square root(4) = 2 or -2
I need a function that is not reversible because, even if anyone cracked my cipher, they should not be able to produce a decrypter, that can easily decrypt the passwords in my hashing.
Using this functions I can make my hashing more secure.
It would be helpful if someone could give more such functions with explanations.
Squaring in R is irreversible in the sense that it loses information. But that's not at all what hash functions are about.
Cryptographic hash functions have two main properties:
It's hard to find two inputs with the same output, called a collision
It's hard to find an input matching a given output, called a pre-image
Squaring on R has neither of these properties:
Finding a collision is trivial. Given x just calculate -x, both of which square to x*x.
Finding a pre-image is easy. Calculate the square-root. There are efficient algorithms for this. (Ignoring the problem that you can't output the infinite sequence of digits if the result is irrational)
Unfortunately there are no "simple" functions with these properties.
Related questions:
Why are hash functions one way? If I know the algorithm, why can't I calculate the input from it?
Modulo is irreversible. Absolute value is irreversible. Rounding is irreversible.
Power of 0.
Imaginary numbers are good as a computer can only pass the equation if it already knows what to do with it.
Rounding numbers.
Salting "functions" should be reversible. The point of a salt is just to add extra (hard to guess) data to the value you want to hash. This way, attackers have a much harder time reverse engineering hashes with their own guesses.
One common solution is to just prepend/append the salt to the text you're going to hash.
For example, if your hidden value was "password" and your salt was a random number between 0 and 255, the thing actually stored in your database might be md5(123password), 123. So it doesn't really make sense for the salt operation to be irreversible, as it's already hashed, which is, kind of, irreversible.
I realize this question might not be that programming related, and that it by many will sound like a silly question due to the intuitive logical fault of this idéa.
My question is: is it provable impossible to construct a cryptographic scheme (implementable with a turing-complete programming language) where the encrypted data can be decrypted, without exposing a decryption key to the decrypting party?
Of course, I can see the intuitive logical fault to such a scheme, but as so often with formal logic and math, a formal proof have to be constructed before assuming such a statement. Is such a proof present, or can it easely be constructed?
Thank you for advice on this one!
Edit: Thank you all for valuable input to this discussion!
YES!!! This already exists and are called zero knowledge protocols and zero knowledge proofs.
See http://en.wikipedia.org/wiki/Zero-knowledge_proof
However, you have to have a quite a good background in mathematics and crypto to understand the way it works and why it works.
One example of a zero knowledge protocol is Schnorr's ZK protocol
No; but I'm not sure you're asking what you want to be asking.
Obviously any person who is decrypting something (i.e. using a decryption key) must, obviously, have the key, otherwise they aren't decrypting it.
Are you asking about RSA, which has different keys for decrypting and encrypting? Or are you asking about a system where you may get a different (valid) result, based on the key you use?
If by "decrypted" you just mean arrive at the clear text in some way, then it is certainly possible to create such a cryptographic scheme. In fact it already exists:
Take an asymmetric encryption scheme, eg: RSA where you have the public key but not the private key. Now we get a message that's been encrypted with the public key (and therefore needs the private key to decrypt it). We can get the original message by "brute force" (yes, this'll take an enormously long time given a reasonable key/block size) going through all possible candidates and encrypting them ourselves until we get the same encrypted text. Once we get the same encrypted text we know what the decrypted text would be without ever having discovered the private key.
Yes.
Proof: Encryption can be considered as a black box, so you get an input and an output and you have no idea how the black box transforms the input to get the output.
To reverse engineer the black box, you "simply" need to enumerate all possible Turing machines until one of them does produce the same result as the one you seek.
The same applies when you want to reverse the encryption.
Granted, this will take much more time than the universe will probably live, but it's not impossible that the algorithm will find a match before time runs out.
In practice, the question is how to efficiently find the key that will decode the output. This is a much smaller problem (since you already know the algorithm).
It's called encoding.
But everyone with the encoding algorithm can "decrypt" the message. This is the only way of keyless encryption.