usnistgov / OSCAL

Open Security Controls Assessment Language (OSCAL)
https://pages.nist.gov/OSCAL/
Other
674 stars 183 forks source link

Suggestions for generating a 48 character SHA-384 hash #2053

Open Telos-sa opened 1 month ago

Telos-sa commented 1 month ago

Question

For our back-matter resources in OSCAL models, we have been generating SHA-384 hashes of files for the hash objects. We haven't been able to get the resulting hash to be 48 characters with this algorithm. The validation constraints require SHA-384 hashes to be exactly 48 characters. We are currently utilizing the the hashlib package from the python standard library, which generates a 96 character SHA-384 hash. We were wondering if this might be an incorrect regular expression used in validation, or if not, if you had any suggestions for generating a 48 character SHA-384 hash.

Screenshot 2024-09-24 at 3 51 58 PM Screenshot 2024-10-08 at 3 50 25 PM
david-waltermire commented 6 days ago

I wrote a small test in Java as follows:

  @Test
  void hashTest() throws NoSuchAlgorithmException {
    String[] algorithms = {
        "SHA-224",
        "SHA-256",
        "SHA-384",
        "SHA-512",
        "SHA3-224",
        "SHA3-256",
        "SHA3-384",
        "SHA3-512"
    };

    String text = "The rain in spain falls mostly in the plain.";

    for (String algorithm : algorithms) {
      MessageDigest md = MessageDigest.getInstance(algorithm);
      md.update(text.getBytes());

      byte[] digest = md.digest();

      String hex = bytesToHex(digest);

      System.out.println(algorithm + "(" + hex.length() + "): " + hex);
    }
  }

  private static String bytesToHex(byte[] bytes) {
    StringBuilder sb = new StringBuilder();
    for (byte b : bytes) {
      sb.append(String.format("%02x", b));
    }
    return sb.toString();
  }

Given the text:

The rain in spain falls mostly in the plain.

This produces the following output:

SHA-224(56): d68309e6c133a7e67f6e6dbfedb4ab8ae2db75c69281a4a3ec328fa4
SHA-256(64): c4456f09303ef3074f8192c66620d591c42d06cdaaf9d0ceb9753085e57b352c
SHA-384(96): e0b7ab07c6e94468e52f8836fb8eb54820f2fe2922806d19c68312ebdf17a69a92a34d9c82363aa4e7d45dc1b46c1a12
SHA-512(128): b0e1cf04dd19ac4a1d0ceb0e170f7db840869343f769346c55b00306374c5a53f3ba56e64524d301c24e66e961bdaa6ab1677af1bc9765a265d611faa897ebb7
SHA3-224(56): f79e101f48008d6cf3008dcd3b5ba9cd1f1543d9d5906117137aaca4
SHA3-256(64): 5ed870a86cd928097a7342d8df611a20e76025249c087c38e4fccacc646bb21d
SHA3-384(96): e67e1707a412e197b2a58321b2b57facd6af534d09ed8b134f95ab978fdc62e925e4524ef48417286ec37c767542e3bc
SHA3-512(128): b6337f28c2ae8e614516db5233a39034edae3c38b793a89b0bcfead82d4b5bcffead9d82ac6b41c641791a22e6cc5f9a13c9861cc2843c18869d5f6a4b0e7599

Based on this testing, the hexadecimal representations of these hashes should be twice the size that they are. This is consistent with what @Telos-sa is seeing.

I'll submit a PR to fix this.