Is there a collision free Hash Function for dynamic data that preserves already created hashes?

I am familiar with the concept of hash functions and fingerprints but I am new to the implementation of functions and the specific characteristics of all those hash functions out there.

What I need

Say I have a table of employee data {FirstName, LastName, Birthday, …} which is dynamic. New employees join the the company, old employees leave. I want to hash the employee data. I need to make shure that the data of new employees is not hashed to the same value as any other employee that has ever been in the database.

In this sense the data set is append only. While deleting the employee data of an retiring employee is mandatory, I can store the hash, that was once linked to that employee. (Which most likely is of no use because the hash of past employees data will not evaluate to itself once hashed again 🙁 )

Hashing does not need to be cryptographic. Yet hashes must not easily be tracked back to employee data. By this I mean you are not supposed to use an efficient method to calculate employee data from hash values. Since information is lost in the process of hashing I would assume that this requirement is easy to match.

The Goal

I want to reduce the size of the hash (meaning bit size) as much as possible.

I would assume that, without collision resistance, I need to pick a fairly large hash (2^32 or bigger) to assure a tolerable risk of collision. Avoiding this is the main interest behind the question.

I must guarantee that never ever a new employees data is hashed to the same value as one of the prior employees data was hashed to. I can make assumption like “Given infinite time there will in total never be more then 1.000.000 people in the company or retired from the company.” So the total number space of hashes is fixed.

Is this solvable? If not, what would be the best hashing procedure that assures maximum collision resistance (Rabin’s Fingerprinting?)

Are the sha1 hashes used by common ssh configurations insecure?

I got an automated PCI security test result that checked various server configurations. The automated test determined the server to be unsafe due to the use of sha1 algorithm in some elements of the ssh configuration.

The configuration can be seen when running ssh -vvv, so here’s the relevant part of that output. I snipped out the other algorithms that are available on this particular server, but several are available.

debug2: KEX algorithms: ...snip...diffie-hellman-group14-sha1 debug2: MACs ctos: hmac-sha1...snip... 

It’s the use of:

  • diffie-hellman-group14-sha1 in the key exchange algorithms
  • hmac-sha1 in the MACs from client to server

I’ve searched this site a bit and I don’t see much data about whether these algorithms are 1) in use 2) considered insecure for a PCI compliant site in 2019.

Extracted LM Hashes doesnt match actual password

I’m new to LM Hashing and Windows authentication, and I’m having problems with LM hashes.

I’ve created 2 accounts with the password “123”, and both of them have different hashes, and none of the hashes match any online LM Calculator.

aaa:1005:C4EE3658F332B6C7FF1D33F62B106E84:4CF3088135D600E4911B98627744ED4F:::  abc:1006:4101BCC1A99F2B15F1E6855C0C6E105C:5FFFE78ED912250FCCBBFBCB9D685288::: 

These are the hashes I’ve got from pwdump7, same passwords, different hashes. Are the hashes salted or anything like that?

Comparing uniquely salted hashes

I have a system which needs to compare hashed identifier values. I want to salt my hashes, to prevent them being cracked with a rainbow table.

However, the system needs to be able to compare the hashed identifiers, so it seems that the same salt needs to be used for every hash.

A common salt would help protect the data from a pre-existing rainbow table, but an attacker could brute force crack one hash, determine the common salt, then crack the remaining hashes.

My question is, is there a more secure way to store the identifiers whilst preserving the ability to use them for matching?

Iterated salted sha256 hashes hashcat

I have a hash which was generated by concatenating a password to a salt, then repeating hashing 10000 times.

The description for salted sha256 in the output of hashcat -h is

1410 | sha256($  pass.$  salt)                              | Raw Hash, Salted and/or Iterated 

but I was unable to find any examples online as to specifying an iteration count for iterated salted sha256. Is this possible with hashcat? If it is, how would I specify the command line options to hashcat for this?

When encrypting password hashes, how to handle nonces?

I know that encrypting password hashes is a contentious issue. However, I have seen it recommended in some quarters. I know for instance that DropBox did this at one time with AES256. In these cases, all password hashes would be encrypted with one shared key, allowing for easy storage in a key management system (such as AWS KMS, HashiCorps Vault, or a HSM) and straightforward rotation.

However, most modern symmetric ciphers that would be appropriate for this task require random nonces. Wouldn’t this mean that the nonces need to be tracked and stored somewhere?

Appending a secret (pepper) to Argon2 password hashes

I’ve read quite a bit of the StackExchange and HackerNews debates on the user of “peppers” in password hash security. There are a number of different implementations of the idea of a pepper, ranging from an additional hardcoded salt in the code hash(password, pepper, salt), to encrypting each password hash separately, in which case the secret key is the pepper.

In the case of one of the middle ground approaches, a shared and secret pepper is included via hash(hmac(password, pepper),salt). This is necessary primarily because of many hashing algorithm’s reliance on the Merkle–Damgård construction which is vulnerable to length extension attacks.

However, Argon2 is not based on a Merkle–Damgård construction and therefore this attack would not apply. In using Argon2, can the naive approach of argon2(password, pepper, salt) be used?

Additionally, the Argon2 specification Introduction seems to indicate that using HMACs, peppers, or secret keys at all is unnecessary. Is Argon2ID with strong memory, threads, and time costs enough on its own?

How to make suitable changes to the bruteForce method to crack the password hashes

I want to crack the password hash. This is my data which I want to display the username and the passwords. Please Ignore if my editing is wrong I am new to stack flow.

Thanks in advance.

enter image description here

This is my code

import; import;  import java.util.Scanner;  import;  import; import; import; import javax.crypto.SecretKeyFactory; import javax.crypto.spec.PBEKeySpec; import javax.crypto.SecretKey; import javax.xml.bind.annotation.adapters.HexBinaryAdapter;  import com.opencsv.CSVReader;   public class LabSecurity {     private static final char[] characters = {'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j',             'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z'};      private static final int HASH_ITERS = 10000;     private static final int SALT_LENGTH = 32;     private static final int HASH_LENGTH = 512;      private boolean found;     private String match;      private MessageDigest md5;      private byte[] byteRepresentation;     private byte[] hash;     private String strHexHash;     private HexBinaryAdapter hba;       /**      * Constructor for objects of class LabSecurity      */     public LabSecurity() {         try {             md5 = MessageDigest.getInstance("MD5");             hba = new HexBinaryAdapter();         } catch (NoSuchAlgorithmException nsae) {         }     }      public void tryMD5() {         try {             String str;             do {                 System.out.println("Input a string to generate its MD5 hash (press enter to quit)");                 Scanner terminalInput = new Scanner(;                 str = terminalInput.nextLine();                 if (!str.equals("")) {                     System.out.println(encodeMD5(str));                 }             } while (!str.equals(""));         } catch (Exception e) {         }      }      private String encodeMD5(final String input) throws Exception {         byteRepresentation = input.getBytes("UTF-8");         hash = md5.digest(byteRepresentation);         strHexHash = hba.marshal(hash);         return strHexHash;     }      public void bruteForce(final String input) {         try {             CSVReader reader = new CSVReader(new FileReader(input));             String[] nextLine;             reader.readNext();              System.out.println("Brute force");             while ((nextLine = reader.readNext()) != null) {                 System.out.print(nextLine[0] + " " + nextLine[1] + " ");                 found = false;                 String password = "not found";                 if (found) {                     password = match;                 }                 System.out.println(password);             }         } catch (Exception e) {         }     }      /**      * Recursively explore all passwords shorter or equal to parameter <length>,      * made up of characters from the <characters> class variable      * to find the password which has the same MD5 hash as parameter <hash>.      * The <found> global variable needs to be initialised to false prior to calling the method.      * Results are stored in the <found> and <match> global variables.      * <p>      * bruteForceRecursive(10, 0, "", <hash>) will try passwords      * of 10 or fewer characters until it finds one that hashes to <hash> or      * all passwords have been tried unsuccessfully.      */     private void bruteForceRecursive(final int length, final int position, final String baseString, final String hash) throws Exception {         for (int i = 0; i < characters.length & !found; i++) {             String attempt = baseString + characters[i];             found = hash.equals(encodeMD5(attempt));             if (found) {                 match = attempt;             } else {                  if (position < length - 1) {                     bruteForceRecursive(length, position + 1, attempt, hash);                 }             }         }     }      public String generateHash(String password) {         String result = "";         return result;     }      private byte[] hashPassword(final char[] password, final byte[] salt, final int iterations, final int keyLength) {          try {             SecretKeyFactory skf = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA512");             PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, keyLength);             SecretKey key = skf.generateSecret(spec);             byte[] res = key.getEncoded();             return res;         } catch (NoSuchAlgorithmException | InvalidKeySpecException e) {             throw new RuntimeException(e);         }     }   } 

Would it be possible to store hashes generated in a file, then brush through them to find out if they are under the target?

I have been wondering if it would be possible to generate hashes, store them in a file, then use them as hashes when mining. When you would mine, you would not generate the hashes, but instead, just compare them to the target. This would be much more efficient, right? Anyway, here is some psudo python code i made up:

import hashlib while True:     hash = hashlib generate random hashes     file = open('hashes.txt', 'w')     file.write(hash) 

or something like that.