I am trying to determine the hash used to encrypt the following strings. From the length of the strings I gather it is a 32 bit hash however Adler32 and CRC32 do not give me the same values.
The original string and hashed value are as follows:
0145 : 68333235
0231 : F538CBE5
0343 : E16BE4A9
Any help would be appreciated.
NO, it's not a encrypted string that you will decrypt and find out. Rather it's a hashed string value of the original string and the best way to match is to generate hash value again using the same (or available's) hashing technique and compare the generated hash value to confirm it.
Related
I'm looking for a way to encrypt main password using short key/pin and decrypt it by this pin every time.
I tried to generate hash (sha256) from short key given by user and cut off the hash to desired length, decode it to bytecode and use as Fernet
Piece of code:
pin = self.pin_ent.get()
key: str = hashlib.sha256(pin.encode()).hexdigest()[10:-10]
f = Fernet(key.decode())
but python rise the error
ValueError: Fernet key must be 32 url-safe base64-encoded bytes.
It is unclear what you mean with "desired length". SHA-256 creates a 32 byte hash value (without the hex encoding that you added). You just need to base64url encode it, as the error description suggests.
A PIN is not suitable for encryption purposes as it is too easy to try all possible PIN values, and try to decrypt the stored password. If you'd use a normal-strength password to encrypt the other password (which seems counter-productive, but hey) then SHA-256 is not secure either, you'd have to use a PBKDF such as PBKDF2 to strengthen the password.
The utility openssl can be used to generate a sha512 based hash from a given string.
What is the possible range of characters it can produce in output. I mean that what all characters can the result produce. I am not able to find any documentation for the same.
openssl passwd -6
Password:
Verifying - Password:
$6$qJV2Hr9qSOw4/Zxx$pVe4wDNy1mDRIAcPrIWEr0dCzpZQDS2Zb83Ix2pktuCd5jEwvQjO8EiDMFtlAQ/TfYXucKO8qWf9NtLQPbdgi1
The above is an example of sha-512 hashed string using 'openssl'.
What is the possible range of characters SHA-512 can produce?
All 256 possible byte values, like with every other relevant hashing function. However, because the output is effectively random, binary data, hash values are almost always encoded to represent them as plain (ASCII) text. base16 (hex) and base64 are popular. Each encoding has its own alphabet.
$6$qJV2Hr9qSOw4/Zxx$pVe4wDNy1mDRIAcPrIWEr0dCzpZQDS2Zb83Ix2pktuCd5jEwvQjO8EiDMFtlAQ/TfYXucKO8qWf9NtLQPbdgi1
The above is an example of SHA-512 hashed string using 'openssl'
No, not really. It's a password hash in crypt format. The selected mode is based on SHA-512, but the output encodes much more information than just a SHA-512 hash value. To the best of my knowledge there is no formal specification of the crypt format.
Assuming that no parameter pairs are included (which openssl doesn't output as far as I know), the alphabet is that of base64 plus '$' and '.' which serve as separators.
To fully support all possible values in Modular Crypt Format, including those with key-value parameters (as in $md5,rounds=5000$GUBv0xjJ$$mSwgIswdjlTY0YxV7HBVm0) you should probably expect all printable ASCII characters, but at least '=' in addition to those mentioned above.
Password security is not my strong suit. Please help me out.
I use node.js 4.2.3 express 4.13.3. I found some examples to hash and salt passwords with crypto's pbkdf2.
Here is my code.
var salt = crypto.randomBytes(10).toString('base64');
console.log("salt > "+salt);
crypto.pbkdf2(pass, salt , 10000, 150, 'sha512',function(err, derivedKey) {
pass = derivedKey.toString('hex');
});
The final derivedKey does not include the salt. What am I missing? Should I join the two strings manually before saving?
Why some examples use base64 and others hex? To get different string lenghts? What is the default, so I can use it?
Why not to use basic64 in both salt and hashed password?
Is the final derivedKey string UTF8? Or this has to do only with the database it gets saved? My database is in UTF8.
Thanks
Yes, store the salt yourself, separately, unencrypted. Make sure it's randomly generated.
More importantly, you're crippling your PBKDF2 encryption by asking for 150 bytes (bytes per nodejs.org) of key length - SHA512 is a fantastic choice, but it only provides 64 bytes of native output. To get 10,000 iterations of 150 bytes of output, PBKDF2/RFC2898 is going to execute 30,000 times, while an offline attacker will only need to run 10,000 iterations and match the first 64 bytes (if the first 64 match, then the rest will too); you gave them a 3:1 advantage for free!
Instead, if you're happy with the work factor, you should use 30,000 iterations of 64 bytes of output - you'll spend the same amount of time, no difference, but the attacker now has to do 30,000 iterations too, so you took away their 3:1 advantage!
When you pass the salt to the PBKDF2 function, if you can, just pass in the pure binary. Also, the node.js docs say - reasonably "It is recommended that the salts are random and their lengths are greater than 16 bytes." This means binary 16 bytes, before the base64 or hex or whatever conversion if you want one.
You can save both salt and derivedkey as BINARY of the correct length for the most efficient storage (then you don't have to worry about UTF-x vs. ASCII), or you can convert one or both to BASE64 or hexadecimal, and then convert back to binary as required. Base64 vs hex vs binary is irrelevant as long as the conversions are reconverted as needed.
I'd also make the number of iterations a stored field, so you can easily increase it in the years to come, and include a field for the "version" of password hashing used, so you can easily change your algorithm in the years to come if need be as well.
Encryption works with data, not strings, this includes the encryption key. PBKDF2 produces a data key, which can be easily converted to a string, this conversion is necessary because many data bytes have no corresponding print character or unicode code point. Many scripting languages do not handle data well so the data is many times converted to Base64 or hexadecimal (hex).
You can use Base64 or hexadecimal for the salt and hashed password, just be consistent on all uses.
The salt and iteration count need to be the same for creating an checking, you will need to combine them or save them separately.
Your code is converting the derived key to hexadecimal, that is fine and base64 would also be fine. Again this is necessary because not all data bytes are UTF-8.
I need the algorithm about encrypt and decrypt using RSA algorithm. Now I have public key, private key, and string text. The questions are
I need to know how to encrypt it. Encrypt each character in text or encrypt whole text.
How to decrypt it when ciphertext has only number. How to divide number to decrypt.
p.s. Sorry about my bad English. = ="
The standard way is:
Generate a key of symmetric algorithm (for example, AES).
Encrypt the text with them.
Encrypt this key with RSA using, for example, PKCS#1 notation.
Compose an output structure containing ciphertext, encrypted key and other service information (symmetric algorithm identifier, recipient ID, etc.). Most used format is noted in RFC 5652.
You can take each character from the string take it ascii value encrpyt it and then again convert it into text and store.do it for all characters.This will be your encrypted text.Like wise do it for decryption..
hope it helps
I'm going to use this kind of approach to store my password:
User enters password
Application salts password with random number
Then with salted password encrypt with some encryption algorithm randomly selected array of data (consisting from predefined table of chars/bytes)
for simplicity it can be used just table of digits, so in case of digits random array would be simply be long enough integer/biginteger.
Then I store in DB salt (modified value) and encrypted array
To check password validity:
Getting given password
Read salt from DB and calculate decrypt key
Try to decrypt encrypted array
If successfull (in mathematical mean) compare decrypted value byte by byte
does it contains only chars/bytes from known table. For instance is it integer/biginteger? If so - password counts as valid
What do you think about this procedure?
In a few words, it's a kind of alternative to using hash functions...
In this approach encryption algorithm is about to be used for calculation of non-inversible value.
EDIT
# Encrypt/decrypt function that works like this:
KEY=HASH(PASSWORD)
CYPHERTEXT = ENCRYPT(PLAINTEXT, KEY)
PLAINTEXT = DECRYPT(CYPHERTEXT, KEY)
# Encrypting the password when entered
KEY=HASH(PASSWORD)+SALT or HASH(PASSWORD+SALT)
ARRAY={A1, A2,... AI}
SOME_TABLE=RANDOM({ARRAY})
ENCRYPTED_TABLE = ENCRYPT(SOME_TABLE, KEY + SALT)
# Checking validity
DECRYPT(ENCRYPTED_TABLE, PASSWORD + SALT) == SOME_TABLE
if(SOME_TABLE contains only {ARRAY} elements) = VALID
else INVALID
From what you write I assume you want to do the following:
# You have some encryption function that works like this
CYPHERTEXT = ENCRYPT(PLAINTEXT, KEY)
PLAINTEXT = DECRYPT(CYPHERTEXT, KEY)
# Encrypting the password when entered
ENCRYPTED_TABLE = ENCRYPT(SOME_TABLE, PASSWORD + SALT)
# Checking validity
DECRYPT(ENCRYPTED_TABLE, PASSWORD + SALT) == SOME_TABLE
First off: No sane person would use such a homemade scheme in a production system. So if you were thinking about actually implementing this in the real world, please go back. Don't even try to write the code yourself, use a proven software library that implements widely accepted algorithms.
Now, if you want to think about it as a mental exercise, you could start off like this:
If you should assume that an attacker will know all the parts of the equation, except the actual password. The attacker, who wants to retrieve the password, will therefore already know the encrypted text, the plaintext AND part of the password.
The chance of success will depend on the actual encryption scheme, and maybe the chaining mode.
I'm not a cryptanalyst myself, but without thinking about it too much I have the feeling that there could be a number of angles of attack.
The proposed scheme is, at best, slightly less secure than simply storing the hash of the password and salt.
This is because the encryption step simply adds a small constant amount of time to checking if each hash value is correct; but at the same time it also introduces classes of equivalent hashes, since there are multiple possible permutations of ARRAY that will be recognised as valid.
You would have to brute force the encryption on every password every time someone logs in.
Read salt from DB and calculate decrypt key
This can't be done unless you know what the password is before hand.
Just salt (And multiple hash) the password.