Talk:SHA-2

Pseudo code error ?

From the pseudo code: append L as a 64-bit big-endian integer, making the total post-processed length a multiple of 512 bits
I barely know anything about SHA-2, but this seems like a error. Why would you change L if it is no longer being used after this point ? Garo (talk) 16:19, 5 October 2020 (UTC)

Never mind, my mistake, I understood it as "append to L" instead of "append L to" Garo (talk) 16:51, 5 October 2020 (UTC)

@Garo: If the page had simply used Module:SHA2 instead of pseudo-code, you would have had the opportunity to step through the program with a debugger. --Ysangkok (talk) 22:12, 5 October 2020 (UTC)

Fix SHA-2 page

[Discussion moved from Wikipedia talk:WikiProject Cryptography -- intgr [talk] 17:28, 6 January 2011 (UTC)]

The formula beneath the graphic on the SHA-2 page differs from the pseudocode given beneath in the calculation of Ch and Ma(j). ORs in the formula are ANDs in the pseudocode, and the second F (which is NOT-ed) in the formula is E in the pseudocode. I don't know which is correct, so I can't fix this myself. Everything else appears to be consistent between the two. —Preceding unsigned comment added by 70.176.109.171 (talk) 06:48, 20 December 2010 (UTC)

You are right. I added the formulas beneath the graphic. They were adopted from the following paper: Yu Sasaki, Lei Wang, and Kazumaro Aoki (2008-11-25). "Preimage Attacks on 41-Step SHA-256 and 46-Step SHA-512" (PDF). {{cite journal}}: Cite journal requires |journal= (help)CS1 maint: multiple names: authors list (link), formula (6) on page 4. This paper is the first reference on the SHA-2 page. I do not know which of these formulas is correct, but I have checked that they produce different results. Nielsduif (talk) 13:57, 5 January 2011 (UTC)

I have replaced the second F (which is NOT-ed) in the formula by E. This part is now the same as in the pseudocode. The difference between the use of AND and OR remains unresolved.Nielsduif (talk) 14:06, 5 January 2011 (UTC)

According to the document FIPS PUB 180-3, linked from the same article, AND should be correct in both functions.--193.40.16.60 (talk) 11:42, 15 January 2011 (UTC)

The Note 1 in SHA-256 algorithme header is unclear. "Calculating" doesn't mean much - the specific calculation (rotate, add) that wrap module 2^32 shall be explicitely described, as well as those which not wrap (shift). Emmanuel Deloget (talk) 16:24, 6 January 2011 (UTC)

I have changed the note to clarify that addition is modulo 2^32, and removed the word "wrap", as the use of that word is not correct to describe the overflow of the calculation when exceeding the 32-bit limit. Richieframe (talk) 06:44, 11 June 2013 (UTC)

Substitutes for formulas

c:= (e and f) xor ((not e) and g) can be substituded by ch := (e and f) or ((not e) and g) which again can be substituded by ch := g xor (e and (f xor g)) --213.178.64.5 (talk) 06:48, 17 February 2011 (UTC)

SHA-2 Variants

NIST has recently announced that a draft for FIPS180-4 that will add 224- and 256-bit variants of SHA-512 (since this should be faster than SHA-256 on a 64-bit computer), with designations SHA-512/224 and SHA-512/256. The current "Comparison of SHA functions" table is fairly unambiguous for the existing functions but it's not clear how to list the two new variants without significantly expanding the content of that column.

One approach would be to have one line per variant (2 for SHA-256 and 4 for SHA-512) but this would seem to overly bulk up the table (and it's not clear which variant was measured for the Example Performance column).

--PeterJeremy (talk) 20:10, 15 March 2011 (UTC)

@ 103.214.150.79 (talk) 05:31, 25 May 2024 (UTC)

Square root initialization constants

The pseudocode section talks about initializing the $h$ array using the "first 32 bits of the fractional parts of the square roots of the first 8 primes 2..19". For fun, I wrote a little piece of code that actually calculated the square roots of the first 8 primes and looked at the hexadecimal representation of them (using printf ("%a", sqrt(X));). The list of constants in the page is correct for the first two primes, but then is completely wrong. For reference, here's what I show as output from my code:

Square root of 2 is: 0x1.6a09e667f3bcdp+0
Square root of 3 is: 0x1.bb67ae8584caap+0
Square root of 5 is: 0x1.1e3779b97f4a8p+1
Square root of 7 is: 0x1.52a7fa9d2f8eap+1
Square root of 11 is: 0x1.a887293fd6f34p+1
Square root of 13 is: 0x1.cd82b446159f3p+1
Square root of 17 is: 0x1.07e0f66afed07p+2
Square root of 19 is: 0x1.16f8334644df9p+2

And here's what the pseudocode lists:

0x6a09e667, 0xbb67ae85, 0x3c6ef372, 0xa54ff53a, 0x510e527f, 0x9b05688c, 0x1f83d9ab, 0x5be0cd19

You can see that the first two match (0x6a90e667 and 0xbb67ae85), but after that they aren't even close. I did not edit the article because I don't know if I did something wrong in my program. But I wanted to point it out here so that others can verify if I'm right and decide what to do about it.

--Markkawika (talk) 01:58, 5 April 2011 (UTC)

Upon further review, I believe the table of cube roots is also incorrect. The first four match my calculations, but all of the rest appear to be wrong. --Markkawika (talk) 02:01, 5 April 2011 (UTC)

And upon still further review, I found out that there's many ways to represent a floating point number internally. I just was looking at the wrong representation. Sorry, my bad. The values are, in fact, correct. --Markkawika (talk) 02:19, 5 April 2011 (UTC)

addition with no carry v standard addition

I think also that the red [+] are standard additions, with carry propagation. However they don't overflow past 2^32.

 Fixed. RFC 6234 is pretty clear: You are right. So I changed the caption from "addition with no carry" (which usually means "XOR") to "addition modulo 2³²". --DavidCary (talk) 12:14, 12 July 2011 (UTC)

C implementation

I have created a C implementation of sha256 using contents of the article. I've tested it on x86 and x86_64 gnu/linux (latest Ubuntu). IMHO, that would be a good addition to the pseudocode.

A MediaWiki command, that hides text unless pressed, would be good here =) Bu I couldn't find it. — Preceding unsigned comment added by Ivze (talk • contribs) 18:15, 4 August 2011 (UTC)

Thanks for collapse command :) --Ivze (talk) 18:31, 4 August 2011 (UTC)

Extended content

/** * This program implements SHA256 hash function for streams of bits. * * SHA 256 operates on streams of bits. After padding, a bit stream is * packed into bytes, for each byte the first bit comes to bit 7, and * the last comes to 0. This complies with Big-Endian phylosophy of * those people, who created SHA256. * * In practice SHA256 is rarely applied to bit streams: byte sequencies * are the target. A byte sequence is concieved to be a stream of bits, * produced by concatenating 8 bit blocks, where first bit of every * block comes from the most significant bit of the respective byte. */ #include <stdint.h> #include <string.h> struct sha256state { uint32_t h[8]; }; void sha256state_init(struct sha256state * S){ S -> h[0] = 0x6A09E667; S -> h[1] = 0xBB67AE85; S -> h[2] = 0x3C6EF372; S -> h[3] = 0xA54FF53A; S -> h[4] = 0x510E527F; S -> h[5] = 0x9B05688C; S -> h[6] = 0x1F83D9AB; S -> h[7] = 0x5BE0CD19; } /** * Standart constants, needed in processing **/ const uint32_t k[] = { 0x428A2F98, 0x71374491, 0xB5C0FBCF, 0xE9B5DBA5, 0x3956C25B, 0x59F111F1, 0x923F82A4, 0xAB1C5ED5, 0xD807AA98, 0x12835B01, 0x243185BE, 0x550C7DC3, 0x72BE5D74, 0x80DEB1FE, 0x9BDC06A7, 0xC19BF174, 0xE49B69C1, 0xEFBE4786, 0x0FC19DC6, 0x240CA1CC, 0x2DE92C6F, 0x4A7484AA, 0x5CB0A9DC, 0x76F988DA, 0x983E5152, 0xA831C66D, 0xB00327C8, 0xBF597FC7, 0xC6E00BF3, 0xD5A79147, 0x06CA6351, 0x14292967, 0x27B70A85, 0x2E1B2138, 0x4D2C6DFC, 0x53380D13, 0x650A7354, 0x766A0ABB, 0x81C2C92E, 0x92722C85, 0xA2BFE8A1, 0xA81A664B, 0xC24B8B70, 0xC76C51A3, 0xD192E819, 0xD6990624, 0xF40E3585, 0x106AA070, 0x19A4C116, 0x1E376C08, 0x2748774C, 0x34B0BCB5, 0x391C0CB3, 0x4ED8AA4A, 0x5B9CCA4F, 0x682E6FF3, 0x748F82EE, 0x78A5636F, 0x84C87814, 0x8CC70208, 0x90BEFFFA, 0xA4506CEB, 0xBEF9A3F7, 0xC67178F2 }; /** * Implements right cyclic shift * @param w - integer to shift * @param N - shift value * @return shifted value */ uint32_t rightrotate(uint32_t w, uint8_t N){ return (w >> N) | (w << (32 - N)); } /** * Processes one 512 bit block * @param state - hash sate structure * @param data - array of 64 bytes, containing bits to be processed */ void sha256state_apply64bytes(struct sha256state * state, const uint8_t * data) { uint8_t i; /* loop variable */ /* Make first 16 32-bit integers from data bytes considering * Big-Endian rules */ uint32_t w[64]; for (i = 0; i < 16; i += 1) { uint8_t of; of = i * 4; w[i] = ((uint32_t)data[of] << 24) | ((uint32_t)data[of + 1] << 16) | ((uint32_t)data[of + 2] << 8) | ((uint32_t)data[of + 3]); } /* Uncompress first 16 integers into 64 ones */ for(i = 16; i < 64; i += 1){ uint32_t s0, s1; s0 = rightrotate(w[i-15], 7) ^ rightrotate(w[i-15], 18) ^ (w[i-15] >> 3); s1 = rightrotate(w[i-2], 17) ^ rightrotate(w[i-2], 19) ^ (w[i-2] >> 10); w[i] = w[i-16] + s0 + w[i-7] + s1; } /* Copy state */ uint32_t a,b,c,d,e,f,g,h; a = state -> h[0]; b = state -> h[1]; c = state -> h[2]; d = state -> h[3]; e = state -> h[4]; f = state -> h[5]; g = state -> h[6]; h = state -> h[7]; /* Main ciphering loop */ for(i = 0; i < 64; i += 1){ uint32_t Sigma0, Ma, t2, Sigma1, Ch, t1; Sigma0 = rightrotate(a, 2) ^ rightrotate(a, 13) ^ rightrotate(a, 22); Ma = (a & b) ^ (a & c) ^ (b & c); t2 = Sigma0 + Ma; Sigma1 = rightrotate(e, 6) ^ rightrotate(e, 11) ^ rightrotate(e, 25); Ch = (e & f) ^ ((~ e) & g); t1 = h + Sigma1 + Ch + k[i] + w[i]; h = g; g = f; f = e; e = d + t1; d = c; c = b; b = a; a = t1 + t2; } /* Push values back to state */ state -> h[0] += a; state -> h[1] += b; state -> h[2] += c; state -> h[3] += d; state -> h[4] += e; state -> h[5] += f; state -> h[6] += g; state -> h[7] += h; } /** * High-level data structure for processing data in blocks of variable * length. */ struct sha256hash { struct sha256state state; uint8_t inbuf; /* bytes waiting in buf[] */ uint8_t buf[63]; uint64_t message_bits; /* Number of message bits, allready processed */ }; void sha256hash_init(struct sha256hash * hash){ sha256state_init(& hash -> state); hash -> inbuf = 0; hash -> message_bits = 0; } /** * Pushes len message bytes into hasher. To process bit stream, bits * shall be packed in bytes in Big-Endian manner. * @param hash - highlevel hash object * @param buf - data buffer * @param len - number of bytes in buffer, 32 bit unsigned for code * stability **/ void sha256hash_process_bytes(struct sha256hash * hash, const uint8_t * buf, uint32_t len) { uint64_t all_len = (uint64_t)len + hash -> inbuf; uint64_t full_blocks = all_len / 64; uint8_t trailing_bytes = all_len % 64; uint64_t i; for(i = 0; i < full_blocks; i += 1){ if(i == 0){ /* concatination with (hash -> buf) is possible */ if(hash -> inbuf == 0){ /* no concatenation here */ sha256state_apply64bytes( &hash -> state, buf ); }else{ uint8_t mem[64]; memcpy( mem, hash -> buf, hash -> inbuf ); memcpy( mem + hash -> inbuf, buf, 64 - hash -> inbuf ); sha256state_apply64bytes( &hash -> state, mem ); } }else{ /* all data taken directly from buf */ sha256state_apply64bytes( &hash -> state, buf + (i*64 - hash -> inbuf) ); } } /* copying trailing bytes to buf */ if(full_blocks == 0){ /*Couldn't get enough data for a block, add new data to bufer*/ memcpy(hash -> buf + hash -> inbuf, buf, len); hash -> inbuf += len; }else{ /* Have had at least one full block, all hash -> buf data * gone there */ memcpy(hash -> buf, buf + (full_blocks*64 - hash -> inbuf), trailing_bytes); hash -> inbuf = trailing_bytes; } /* incrementing message bit length */ uint64_t new_bits = full_blocks * 512; hash -> message_bits += new_bits; } /** * Called before end of hashing. Applies bits, not fitted into last byte. * @param hash - hash object * @param bits - one byte, containing 0 to 7 bits, that are last bits of * the message in Big-Endian order. Zero bits shall be used for hashing * sterams of bytes. * @param len - number of bits */ void sha256hash_process_trailing_bits(struct sha256hash * hash, uint8_t bits, uint8_t len) { uint8_t mem[128]; /* From 1 to 2 last blocks are going to be generated */ uint16_t bits_left = (uint16_t)hash -> inbuf * 8 + len;/* So many message bits left unprocessed */ /* Writing first block */ uint8_t mempos = 0; memcpy(mem, hash -> buf, hash -> inbuf); mempos += hash -> inbuf; /* at most 63 */ mem[mempos] = ( bits & (0xff << (8-len)) ) | ( 0x01 << (7-len) ); /* '1' bit with some zero bits according to padding standart */ mempos += 1; /* at most we've filled the whole first block */ uint8_t bytes_except_padding = hash -> inbuf + 1 + 8; /* This + N zero bytes => one or two 512 bit blocks */ uint8_t write_zero_bytes; uint8_t twoblocks = bytes_except_padding <= 64 ? 0 : 1; /* One or two blocks will be produced */ if( !twoblocks ){ /* one block is enough */ write_zero_bytes = 64 - bytes_except_padding; }else{ write_zero_bytes = 128 - bytes_except_padding; } /* applying zero bytes */ memset(mem + mempos, 0, write_zero_bytes); mempos += write_zero_bytes; /* appending message length in bits */ hash -> message_bits += bits_left; uint8_t i; for(i = 0; i < 8; i += 1){ mem[mempos + i] = hash -> message_bits >> 8*(7-i) & 0xff ; } /* push the block or blocks through hasher */ sha256state_apply64bytes(&hash -> state, mem); if(twoblocks) sha256state_apply64bytes(&hash -> state, mem + 64); /* Done! Quk-ik */ } /** * Outputs hash value as a sequence of bytes. * @param hash - high-level hash object * @param mem - array of 32 bytes to put data to */ void sha256hash_get_result(const struct sha256hash * hash, uint8_t * mem) { uint8_t ksi, eta; for(ksi = 0; ksi < 8; ksi += 1){ for(eta = 0; eta < 4; eta += 1){ mem[ksi * 4 + eta] = hash -> state . h [ksi] >> (8*(3 - eta)) & 0xff; } } } /* Below is a sample program, that hashes sequences of bytes from * a file */ #include <stdio.h> #include <stdlib.h> /** * Prints mem in hex */ void print_beautiful(uint8_t * mem, uint8_t len){ uint8_t i; for(i = 0; i < len; i += 1){ printf("%.2x", mem[i]); } printf("\n"); } int main(int argc, char ** argv){ if(argc < 2){ fprintf(stderr, "Specify a file to calculate hash for\n"); fprintf(stderr, "usage: ./a.out file [buffer_size]\n"); fprintf(stderr, "file - file to open and read data from\n"); fprintf(stderr, "buffer_size - read buffer length in bytes \ from diapason [100-65535]\n"); return 0; } uint16_t buffer_size; if(argc >= 3){ int buffer_size_i = atoi(argv[2]); if(buffer_size_i < 100 || buffer_size_i > 65535){ fprintf(stderr, "Wrong buffer size\n"); return 1; } buffer_size = (uint16_t)buffer_size_i; }else{ buffer_size = 8192; } struct sha256hash hash; sha256hash_init(&hash); FILE * file = fopen(argv[1], "r"); if(file == NULL){ fprintf(stderr, "Can't open file\n"); return 2; } uint8_t mem[buffer_size]; uint16_t nread; do{ nread = (uint16_t)fread(mem, 1, buffer_size, file); sha256hash_process_bytes(&hash, mem, nread); }while(nread == buffer_size); /* end of data or IO error */ if(ferror(file)) fprintf(stderr, "Error reading file\n"); fclose(file); sha256hash_process_trailing_bits(&hash, 0, 0); /* No trailing bits, just finish the digest */ uint8_t out[32]; sha256hash_get_result(&hash, out); print_beautiful(out, 32); return 0; }

748F0F9B-A02C-414F-A819-4253FEE87EE0

Removal of recommendations of outdated FIPS180-1

In the applications section, saying that FIPS180-1 recommends that non-government organizations use SHA-1 is outdated, as FIPS180-3, which replaces FIPS180-1 and FIPS180-2, states that "The adoption and use of this Standard is available to private and commercial organizations," which Standard recommends SHA-2. Should this line be removed, or changed? Derekstucki (talk) 04:02, 4 December 2011 (UTC)

Big-endian vs. Little-endian

From the article: 'Note 2: All constants in this pseudo code are in big endian'

I believe Note 2 at the beginning of the SHA-256 pseudo code is massively confusing. FIPS180-2 specifies, 'Throughout this specification, the “big-endian” convention is used when expressing both 32- and 64-bit words, so that within each word, the most significant bit is stored in the left-most bit position.' This statement concerns left-to-right natural language representation in the text of the standard and not the architecture of the machine executing the code.

All compilers I am familiar with use left-to-right notation for constants in their source code. This may not be true for compilers in natural languages other than English, but the article is in English; thus one should expect the pseudo code to be read by someone who understands English conventions.

There is no need to modify pseudo code constants when translating pseudo code to source code. Only when binary code is transferred between big-endian/little-endian computers is conversion needed. I believe Note 2 should be removed.

17:49, 12 December 2011 (UTC) — Preceding unsigned comment added by 76.18.184.9 (talk)

It was confusing, the main issue with endianness in FIPS180 is regarding how input bytes of the message are converted to words of the message schedule, I have edited the note in such a way to hopefully avoid future confusion. Richieframe (talk) 06:37, 11 June 2013 (UTC)

Zappos

A blog post on ZDNET says Zappos was using SHA-2 for their passwords: "Zappos Thursday said it was using a SHA-2 cryptographic hash but would not disclose any details about its “cryptographically scrambled” password format in the wake of a breach that forced the company to reset 24 million passwords."

Is that appropriate to add here? http://www.zdnet.com/blog/identity/zappos-was-using-sha-2-hash-now-working-with-fbi/162 — Preceding unsigned comment added by 67.87.231.208 (talk) 04:01, 20 January 2012 (UTC)

Definitely not here, nor would it go in the Internet article since that was probably the breach avenue. The information may be suitable for the Zappos article though. —EncMstr (talk) 08:16, 20 January 2012 (UTC)

Secret backdoor

If I was a government, and had to design a hash, I would almost certainly want a back door in it. If I was a mathematician, and I had to put a back door in something, I would head straight to prime numbers. It's beautifully easy to use prime moduloarithmetic to "scramble" one number into some other number, in a way that cannot be reversed easily. It's even got a name: asymmetric cryptography. Of course, if you know the secret key, then you *can* reverse it: so there's your back door. If you look into how RSA gets programmed, it boils down to simply a stack of binary operations, carried out in some order determined by the keys. If you look at how SHA gets programmed, it boils down to simply a stack of binary operations, carried out in some interesting order. So the challenge for the mathematician: how to write the SHA algorithm so that nobody suspects it's really an alternative representation of a particular pre-chosen public key hard coded into an asymmetric cipher.

The dead giveaway here is "prime numbers". SHA is initialized with a whole stack of carefully chosen constants that are all derived from prime numbers. This smells to me like it was designed from the start to have a secret inverse. — Preceding unsigned comment added by 120.151.160.158 (talk) 04:12, 31 August 2012 (UTC)

The SHA hash algorithms have been and are continuously analyzed by cryptographers all over the world. If there really was a basis for backdoor concerns, you would have something more concrete to rely on than "if I was a government"

I disagree. The financial value of exploiting a backdoor may well outweigh the esteem value of publishing the find, and, this is an arms race: for as long as the government was better than researchers, nobody's going to find it - and lets face it - they *have* got more resources ($28bn, 20 years ago).120.151.160.158 (talk) 22:00, 5 October 2012 (UTC)

Look at Dual EC DRBG for an example how a certain government tried to push a backdoored algorithm and how the cryptography community reacted -- the backdoor was uncovered and researchers complained very loudly.

It is also incorrect to call RSA "simply a stack of binary operations". RSA and other asymmetric algorithms have simple and neat mathematical descriptions. In RSA that's $c=m^{e}{\text{ (mod }}n{\text{)}}$ -- basically describes the whole algorithm.

I disagree. I have hand-coded RSA in assembly language from first principals. If you were to use a fixed key, you could optimise the code into something that looks similar to a hash with preconceived constants.120.151.160.158 (talk) 22:00, 5 October 2012 (UTC)

In contrast, symmetric algorithms such as SHA, AES etc, do not have a simple mathematical form -- they are indeed just binary operations (Confusion and diffusion).

About the "prime numbers" argument, see nothing up my sleeve number. SHA-2 doesn't use plain prime numbers, it uses square roots of very small prime numbers (and nowhere in the algorithm are these numbers squared up again). For these numbers to be useful for asymmetric cryptography, they would have to be very large primes (e.g. which are used for RSA). -- intgr [talk] 08:39, 31 August 2012 (UTC)

This only fuels my suspicion - picking constants that are deliberately non-random numbers with interesting potential mathematical properties? They should have announced their intention in advance to pick the results of unpredictable events in future, and used those (eg: lotto, weather, exchange data, whatever).120.151.160.158 (talk) 22:00, 5 October 2012 (UTC)

References

'too technical' template

Anyone want to propose changes we could make to be able to take that 'too technical' box off? It seems like nontechnical readers should go follow the "cryptographic hash algorithm" link and learn what those are, and that once you know what a hash is there's very little nontechnical additional info about SHA-2 that's interesting--maybe there's a paragraph or so more to be written about history/security/applications. It's like how the pages on chess openings don't make sense if you haven't learned a little about chess. Perhaps we could nudge people towards reading the more basic articles if they're lost, but I'm not sure what we'd change to do that.

What thinkst all y'all? — Preceding unsigned comment added by 24.7.67.251 (talk) 00:36, 29 November 2012 (UTC)

 Done. This was removed by Dwarvenux (talk · contribs) in 2013 from edit 563336099. -- Richie Frame (talk) 09:28, 13 December 2014 (UTC)

Fips 180-4 and SHA-512/t

The updated standard from March 2012 introduced SHA-512/224 and SHA-512/256 and generally SHA-512/t. I've updated some of the sections to mention this. This moves things around a bit, since we can't say "SHA-224/256" anymore for two different hash functions, that would be confusing. SHA-512/224 and SHA-512/256 are in the info table because it is in the standard as well. 81.186.243.41 (talk) 15:13, 14 January 2013 (UTC)

 Done. Several of the revisions made in the last year should have cleared up any confusion and misnomers regarding truncated SHA-512 variants. --Richieframe 08:21, 20 December 2013 (UTC)

Pseudocode is broken

A bug was recently introduced into the pseudocode: [2] It is pretty obvious that the h variable is inadvertently overwritten. --87.144.116.61 (talk) 00:51, 7 February 2013 (UTC)

 Done. Pseudocode rewrite and some prior modifications no longer have this problem. Richie Frame (talk) 08:27, 20 December 2013 (UTC)

SHA-256 pseudocode problem (or lack of clarity, at best)

The psuedocode for SHA-256 contains the following three lines:

break message into 512-bit chunks
for each chunk
    break chunk into sixteen 32-bit big-endian words w[0..15]

This sounds like it is declaring a word array of 16 words, each 32 bits in length, which is incorrect. The very next loop of code iterates with i as an index, from 16 to 63, and accesses w[i], which implies that array w must be sized as a word array of 64 words, each 32 bits in length. If the array is defined as w[0..15] as is implied, the loop would run off the end of the array.

I downloaded FIPS PUB 180-4 and checked the formulas listed there, which appears to confirm that the message schedule w is comprised of 64 words (see page 22) and also indicates that the first 16 words of the message schedule are copied directly from the original message block, while the remaining 48 words are computed using the formulas described in that doc (and likewise in the rest of the pseudocode).

I think those three lines would be more accurate and more descriptive if they read:

break message into 512-bit chunks
for each chunk
    copy chunk into first 16 words of 64-word array w[0..63], where each word is 32 bits in length

I considered making the change myself, but I'd appreciate another pair of eyeballs on the NIST doc to confirm the change first. JonathanSomers (talk) 20:48, 26 March 2013 (UTC)

I have made multiple changes to the pseudocode to clarify this as best as I could for both non-experts and programmers. Richieframe (talk) 06:39, 11 June 2013 (UTC)

 Done. The pseudocode now explicitly states "a 64-entry message schedule array w[0..63] of 32-bit words" which seems pretty clear to me. I agree with JonathanSomers and Richieframe that the FIPS publication actually does call for a 64-entry array, and the old pseudocode we used to have in this Wikipedia article was unclear on this point. --DavidCary (talk) 12:37, 14 October 2013 (UTC)

Security of a Hash function is too generic to deserve a paragraph in the abstract

Hi guys, great article! Still, I would suggest removing or moving below the following paragraph: """The security provided by a hashing algorithm is entirely dependent upon its ability to produce a unique value for any specific set of data. When a hash function produces the same hash value for two different sets of data then a collision is said to occur. Collision raises the possibility that an attacker may be able to computationally craft sets of data which provide access to information secured by the hashed values of pass codes or to alter computer data files in a fashion that would not change the resulting hash value and would thereby escape detection. A strong hash function is one that is resistant to such computational attacks. A weak hash function is one where a computational approach to producing collisions is believed to be possible. A broken hash function is one where a computational method for producing collisions is known to exist."""

Whereas it is true, this applies to a Hash function, and I can't see anything specific for SHA-2. I would personally remove it, but I'm perfectly ok with just moving it below, or reducing the number of lines.

Carlesso (talk) 14:17, 16 December 2013 (UTC)

I agree. How about cut-and-pasting this to Cryptographic hash function, section #Properties or #Cryptographic hash algorithms? --Claw of Slime (talk) 16:56, 16 December 2013 (UTC)

I have been looking over that paragraph as well, as it is incorrect. That is saying collision resistance is the only important thing, and completely forgetting about preimage resistance. I plan on making a lot more edits to this page and will work on that section eventually. --Richieframe 08:52, 19 December 2013 (UTC)

After further review, I am removing those 2 paragraphs, similar paragraphs do not exist on the SHA-1 page, and there are too many issues with its content. I will adjust the cryptanalysis section to compensate for this plus the recent edit by Dionyziz. The Cryptographic hash function article has a more comprehensive and accurate description already. --Richie Frame (talk) 09:28, 21 December 2013 (UTC)

Picture of data flow is flawed.

If I had more authority, I would remove the data flow picture. (Or if I had time I would replace it).

• It contains symbols without explanation
• the >>> symbol is not in agreement with the explicit description later.
• I've a mathematical background and recognize ^ as a logical and(never as a *bitwise and*.) In a context like this almost everybody expects it to be xor.

Even so it is illustrative, so it is much better to replace it than just remove. 80.100.243.19 (talk) 11:23, 21 December 2013 (UTC)

Actually, >>> stands for a right rotate (no carry bit) and is common notation for an equivilent ror in ASM. I do fully agree with the ^, as it is not used for AND in any style of pseudocode I am aware of (other than for c style XOR), and will make the appropriate change. -Richie Frame (talk) 09:58, 28 December 2013 (UTC)

It is the standard notation for boolean algebras. 83.77.191.161 (talk) 12:17, 28 December 2013 (UTC)

The symbols should still be different, as two operations are rotates and the third is a shift.66.87.135.24 (talk) 21:17, 9 November 2014 (UTC)

It doesn't seem to add much value as the Ch(), Ma(), and sum functions just reach a cold trail from there and aren't explained further. Anyone coming here (like me) to just learn a high-level overview of how SHA works just gets this figure and that's it. That doesn't add value in my opinion. — Preceding unsigned comment added by 107.1.64.82 (talk) 19:26, 24 February 2014 (UTC)

175.156.140.184 (talk) 11:08, 19 March 2014 (UTC) I did not sign in the IPV4, somebody did it. i did not join any domain.. which was without my notice .. Pls trasmit the massege to them person who steal my particular and profile

and they have encript my device witht eh password protected.

If you are kind enough pls do to delete or terminate it .

Meiching

SHA-2 notability revert re: Bitcoin

@Intgr:, your revert on SHA-2 wrt Bitcoin seems well-intentioned but I think you should re-consider. The edit you reverted didn't say, "SHA-2 is only notable for its use in Bitcoin," it said that SHA-2's use in Bitcoin is notable. Ot at least, that's what I meant to say! :) Bitcoin itself is clearly notable: Bitcoin's article has 8x the number of watchers, 9x the authors, and 29x more edits than SHA-2, so that seems to suggest that Bitcoin itself is certainly as notable as SHA-2 if not moreso, from a volume of interest perspective. That SHA-2's foundational role in Bitcoin's transaction integrity is now missing from the SHA-2 article due to your revert is a pretty big omission, given the public interest in Bitcoin and how it works. In light of the above, I think you should reconsider your revert. If not, would you be open to me adding a different wording like, "SHA-256 notably has a key role in Bitcoin transaction processing and mining."? Thanks in advance, --Jm3 (talk) 23:37, 14 October 2014 (UTC)

@Jm3: Well there are multiple reasons why I don't like that statement.

1. The lead section is already too long.
2. Back in the days it used to be common to have long lists of "software using hash X" on every hash article. Everything starts with good intentions, first it's one or a few important apps, but then everyone and their dog comes along and thinks their favorite application needs to be included in the list and we end up with WP:Listcruft.
3. Cryptocoin people seem to have the idea that the whole world of cryptography revolves around them. It generates lots of headlines, sure, but compared to technologies like SSL, SSH and PGP and perhaps TrueCrypt using SHA-2, Bitcoin is just a small niche. I find it arrogant to imply that usage in Bitcoin makes SHA-2 notable.

PS: I agree that discussing it here is the right place. The ping mention is enough, no need to send an email. -- intgr [talk] 08:16, 15 October 2014 (UTC)

@Intgr: Thanks for responding. I'll let your revert stand and modify the existing mention of cryptocurrencies in SHA-2#Applications; TLS + SSH are already well represented in this section, so I think your concerns have been addressed.

Jm3 (talk) 20:23, 15 October 2014 (UTC)

External link to spreadsheet by DavidRabahy

DavidRabahy (talk · contribs) recently added a URL to Google Documents of a spreadsheet which breaks down the SHA calculation into small pieces with an extensive narrative. In many ways, this is a more approachable discourse than what is presently in the article. I think the link should be added. —EncMstr (talk) 21:45, 20 November 2014 (UTC)

My objection was on the grounds of self-promotion. If someone else thinks it's a useful resource and wants to add it, no problem. -- intgr [talk] 13:06, 23 November 2014 (UTC)

I have attempted to eliminate the self-promotion portions. Is it ok to have the copyright in it? —DavidRabahy (talk) 20:21, 5 December 2014 (UTC)

Linking to your own work is self-promotion, regardless of the content. -- intgr [talk] 08:54, 7 December 2014 (UTC)

How does one "release" work so that it is no longer their own? —DavidRabahy (talk) 21:28, 9 December 2014 (UTC)

@DavidRabahy: Well, you can contribute appropriate content to Wikipedia, at which it becomes subject to other editors and Wikipedia's policies and guidelines. But I think that content is not a good fit for Wikipedia. -- intgr [talk] 18:00, 11 December 2014 (UTC)

How does one request that someone else add a link that would be self-promoting if added by the author? Hmm, or is it s simple as asking in this talk page? —DavidRabahy (talk) 21:34, 9 December 2014 (UTC)

Yep, ask on the talk page and add a {{Request edit}} template. -- intgr [talk] 18:00, 11 December 2014 (UTC)

External link to spreadsheet by DavidRabahy

Would someone please add said external link? —DavidRabahy (talk) 18:10, 11 December 2014 (UTC)

I don't think either your spreadsheet or youtube video by other people improve this article. Wikipedia is not a HOWTO manual, not a place for demonstration, not a place for advertisement. —Claw of Slime (talk) 20:50, 11 December 2014 (UTC)

Per Encyclopedia#Characteristics, "... encyclopedias often contain guides on how to do a variety of things, ..." —DavidRabahy (talk) 22:26, 11 December 2014 (UTC)

I agree with David, the content is appropriate as an external link, however I believe it requires refinement in both format and content before I would consider linking to it. As for the video, I am not sure linking is appropriate, as encyclopedic video content for Wikipedia is generally not an external link, and the video is more hobby than in depth technical report. I would be appropriate however to mention it in your spreadsheet. Richie Frame (talk) 08:46, 13 December 2014 (UTC)

Thank you. Would you please specify the refinements you believe it requires? —DavidRabahy (talk) 18:57, 31 December 2014 (UTC)

Pure Lua Scribunto module implementation

I just made the Module:SHA2 which can currently compute 224 and 256 SHA-2 variants of strings. An example SHA-224 of "The quick brown fox jumps over the lazy dog": {{#invoke:SHA2|hash224|The quick brown fox jumps over the lazy dog}}. Maybe we could use this in the article? I'm sure somebody has objections though, which is why I'm posting here. --Ysangkok (talk) 20:15, 20 December 2014 (UTC)

Yes. What's the point? All you're doing is making the wiki markup less obvious without any change in output. -- intgr [talk] 11:11, 21 December 2014 (UTC)

@Intgr: sample hashes for all pages could be generated automatically if a module implemented all hash algorithms on wikipedia. it would be easy it change the sample strings and the module itself would serve as proof that the hash function is self-contained and implementable. --Ysangkok (talk) 14:59, 21 December 2014 (UTC)

Proposal for clearer schematic of the algorithm

I understand that changing an image has drawbacks. I just try to explain the motivation for a new schematic SVG image.

• The original (current) schematic has several line crossings, and lines are long. Both features makes the image less clear at first sight.
• Also, the more important data input is Wt, as it is the preprocessed message to be encrypted. But in the original (current) image, it is on a smaller font type, at the right, at middle height, and without a box. All of that makes more difficult to graphically see at first sight that it is really the main data input.
• Besides, this schematic proposal reflects the fact that the 8 working variables are more naturally processed from H to A, as once each of them is used, it becomes free to be overwritten with the new value (faster and using less memory for highly optimized hardware, like ASIC), which does not happen if processed from A to H.

This proposal respects the original types, labels, and colors, with no need to modify the image caption.

1=Un esquema que muestra una iteración del algoritmo SHA256.

--Enrique Santos L. (talk) 19:09, 25 October 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on SHA-2. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20111107215111/http://google.com/codesearch/p?hl=en to http://google.com/codesearch/p?hl=en#nywQboHfkw4/apt/apt-pkg/acquire-item.cc&q=SHA256

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 17:33, 10 January 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on SHA-2. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20130526224224/http://csrc.nist.gov/groups/STM/cavp/documents/shs/sha256-384-512.pdf to http://csrc.nist.gov/groups/STM/cavp/documents/shs/sha256-384-512.pdf

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 00:48, 13 February 2016 (UTC)

Section of 'cryptographic hash function' page linked to has been renamed or something

This section no longer exists: Cryptographic_hash_function#message_digest. The link is meant to explain what "digests (hash values)" are. There is another link to the same page (redirected from 'message digest') lower down in the article. I lack the expertise to figure which section of the 'cryptographic hash function' page is most relevant. — Preceding unsigned comment added by JS Hoyer (talk • contribs) 00:28, 3 June 2016 (UTC)

"Cryptanalysis and validation" text is not strictly true

The first paragraph under "Cryptanalysis and validation" makes two claims: one about finding a preimage and one about finding a collision. Both cannot be true. And in fact it's the first one, "finding a message that corresponds to a given message digest can always be done using a brute force search in 2^L evaluations". If you try 2^L texts you will almost certainly get a lot of collisions, and hence almost certainly will not produce every possible hash value.

This needs to be reworded somehow to make it true. SamIAmNot (talk) 15:21, 8 August 2016 (UTC)

No explicit mention of irreversibility?

I searched for "one way", "one-way", "revers", "decrypt" to see any mention that SHA-2 being a hashing algorithm, it cannot be reversed to get the input given a particular output. However, I did not find any mention of this. Shouldn't this be explicitly stated? There is a lot of talk about having to try a large number of inputs to find something that gives a particular output. However, someone who does not know that hash functions are one-way would just be puzzled why this matters, thinking that the input could be computed from the output.

Encyclopath (talk) 22:58, 2 September 2016 (UTC)

How can anyone claim to have understood this article if they have not read the article on hash functions? --146.140.210.15 (talk) 15:55, 16 November 2016 (UTC)

C++ implementation should be renamed C implementation

The C++ implementation currently shown should be renamed to C implementation as it lacks any features that makes up the "++" portion of "C++". To support the statement of this being a C code are these arguments:

1. Existence of macros that could be trivially replaced by inlined functions
2. Heavy use of reinterpreting type-casting that uses C-style casts (deemed "unsafe" in C++)
3. Absence of any C++ libraries when some could be utilized (cstring is a port of string.h)

That said, it essentially means that there is no reason to write this in C++. The only changes needed to port this code to C is the 2 following changes:

 unsigned int *msg = new unsigned int[width << 2]; -> unsigned int *msg = (unsigned int*)malloc((width << 2) * sizeof(unsigned int));
 delete[] msg; -> free(msg);

Which is to say, virtually none.

SecularJohannes (talk) 12:11, 18 September 2016 (UTC)

C++ Implementation has severe bugs - Remove it until there is a proper version

Here are some issues with the source code, detected at first glance. More may exist. So I suggest to remove it until there is a properly reviewed version.

• The code works only for very short messages, up to 55 bytes. Longer messages mean that there is more than one block to process. However, the code uses the following construct to iterate over the blocks: "do { ... Process Block ... } while(!(blocks--));", so the loop terminates already after one block. (BTW: Don't know why the author has used do-while loops everywhere, for-loops are much more readable...)

• The code makes explicit assumptions on the size of data types and it is therefore platform / compiler dependent. I.e. an (unsigned) int is expected to be 32 bits. However, this is not always the case. I'd recommend to use data types like uint32_t etc. available since C++11.

• The internally allocated buffer is 8 times as large as required ((width << 2) unsigned int values, so that is 8*width bytes, assuming that an unsigned int is 4 bytes). Not harmful, but a waste of memory.

• The variable "chunk" is (mis)used as a pointer to a memory location. However, it is declared as int. On many platforms an int has a size of 32 bit, even when compiled for a 64 bit architecture. Therefore, if the address of message is accidentally above 2 GB on a 64 bit architecture, an invalid memory access will result because the pointer is truncated / wrapped. — Preceding unsigned comment added by Holger Strauss (talk • contribs) 07:47, 7 October 2016 (UTC)

Removed it for now. I'm not sure why this article needs C++ implementation at all.TheInevitable (talk) 15:35, 7 October 2016 (UTC)

explain meaning of "/t"

The current article mentions "SHA-512/224" and "SHA-512/256" in paragraphs 2 and 3 of the introduction, and mentions "SHA-512/t" in the last paragraph of "Pseudocode", but these two distinct names aren't linked anywhere. The /224 and /256 are concrete examples of /t but that link isn't explained anywhere in this document.

In paragraph 2, this could be fixed by saying "SHA-512/224 and SHA-512/256 are also truncated versions of SHA-512, known generically as SHA-512/t, described in FIPS PUB 180-4". — Preceding unsigned comment added by 2001:470:67:917:2AD2:44FF:FE34:DB4F (talk) 23:25, 19 April 2017 (UTC)

Addition by User:Awchamoun91

For the third time, now, I have taken out this user's addition because the burden is on them to provide a published reliable source for his claim, since a cryptographic hashing function is quite obviously not under the purview of WP:CALC. I strongly dislike how in particular, they seem to be promoting their own work, which runs up against WP:COI and WP:NOR. I strongly believe that the content as-is must stay out of the article.--Jasper Deng (talk) 18:34, 15 October 2017 (UTC)

@Awchamoun91: The source you just cited is insufficient. To infer that it supports your claim of that hash collision is improper synthesis. I am refraining from reverting only out of a desire to not edit war.--Jasper Deng (talk) 18:56, 15 October 2017 (UTC)

As you can see for yourself the inputs provided here only differ by a single integer.

https://docs.google.com/document/d/1Cv0xwBm9W5gVBiqIO2t65mL_w3Q1NSlLShhBZ_WT96w/edit?usp=sharing

while the outputs are similar enough to warrant their place in the encyclopedia.

57a8141e6831e84996f615176a6d66f5060ed09e06be7493743f43e1481adfaf Compare with: 57ba81a06b336033f1da709211a7d6f30ce7667b711472f672b23f0db1d65c8d

I'm sorry but I cannot cite principles found in the Arabic language anymore than I can take credit for creating them myself, or anymore than I can cite that 2+2=4. It is evident for you to see it if you want to see it, especially considering that "peer review" publication isn't as high of a bar as it's made out to be.— Preceding unsigned comment added by Awchamoun91 (talk • contribs)

@Awchamoun91: I'm sorry, but that's not how Wikipedia works. I don't care how "obvious" it is to you. We only report what published reliable sources say. WP:CALC allows for conclusions like 2 + 2 = 4, but a cryptographic hash function is much more complex than that and hence does not meet that exception. And "similar" is subjective, and a near-collision is not a collision. I have already linked WP:RS multiple times - you should also read WP:V. These are the policies and guidelines that govern our project and you must adhere to them.--Jasper Deng (talk) 19:14, 15 October 2017 (UTC)

I agree with Jasper. Dr. K. 19:17, 15 October 2017 (UTC)

Difficulty is subjective, in the future SHA-256 will be child's play, remember that for an ape 2+2=4 is a very difficult calculation. — Preceding unsigned comment added by Awchamoun91 (talk • contribs)

@Awchamoun91: This project is written by humans for humans, and right now SHA-256 clearly is much more difficult to calculate than 2 + 2 = 4. I don't care what it will be like in the future. Verifiability is one of the core principles of Wikipedia and arguing about the exact wording will get you nowhere.--Jasper Deng (talk) 19:29, 15 October 2017 (UTC)

So be it, quite frankly I don't understand why I need to fight so hard simply to include some information that a reader is likely to find highly interesting and useful. — Preceding unsigned comment added by Awchamoun91 (talk • contribs)

Misleading Comments on Cryptanalysis and Preimage Resistance in Introduction

The introduction makes comments on the state of cryptanalysis which can be misleading to a fairly technical person not intimately familiar with cryptanalysis:

> Currently, the best public attacks break preimage resistance for 52 out of 64 rounds of SHA-256 or 57 out of 80 rounds of SHA-512, and collision resistance for 46 out of 64 rounds of SHA-256.[1][2]

(I just edited to add back in the "out of x rounds" fragments)

This tidbit has spurred some popular online discussion: https://security.stackexchange.com/q/34256/5997

If you read the link, you'll see that people online take this to mean that the strength of the algorithm is perhaps in question. Discussion at the same link suggests that this is not exactly the case.

This paragraph seems to raise questions in the mind of the reader that are not appropriate for an introduction. A more detailed explanation of what these numbers mean and don't mean could be given. This would likely expand the length beyond what is appropriate for an introduction, so I suggest that this paragraph be moved elsewhere.

(Frazz (talk) 17:34, 15 January 2018 (UTC))

Header is too long

Not 1 paragraph, not 2 paragraphs, not 3 paragraphs, but 6 paragraphs long. While this is a technical topic and needs to have lots of detail, the header before the TOC has gotten out of control. Unless you have a small (unreadable) font, the TOC won't show up on the first page of a non-full screen browser window. Time to for it to shrink. 74.104.188.4 (talk) 06:39, 2 March 2018 (UTC)

Problem with table "rounds" columns

Expressing an attack is against 39 of 80 rounds as "39/80" is troublesome. I would suggest either removing the "/80", changing to "of 80" or "39(80)", since I had to look several times to be confident of what was meant. 74.104.188.4 (talk) 07:38, 2 March 2018 (UTC)

The main use of SHA

Do we profit form it kwanele 16:13, 7 July 2018 (UTC) — Preceding unsigned comment added by Kwanele22 (talk • contribs)

SHA-256 rightshift type

In SHA-256 pseudocode there is "rightshift" function, but which one is it? According to this wikibooks page it can be either arithmetical or logical (which I assume is right, but I'm not sure). Can you specify which one is it?

9787F771-E3A3-4F75-9A04-027763DB2E0B

Currently

It always amazes me that Wikipedia editors think (or DON'T think) that using words like "now", "recently" and "currently" can be justified in these articles. Specifically, the lede says "Currently, the best public attacks break preimage..." and give two references- from 2012 and 2011. As I write this late December 2020, there is NOTHING current about something done in 2012. The fact is, that if the offending sentence were changed to "As of 2012, the best public attacks..." few people, I think, would find it relevant or worthy of inclusion 8+ years later. Since this article has obviously NOT been well-maintained, and is chock-full of jargon and a lot of information that 99.9% of anyone reading it will find useless, I'd suggest it is in dire need of a rewrite. Since this is US NIST information, there is no need to duplicate information that can be easily found on the free internet, is there?98.21.247.38 (talk) 07:24, 30 December 2020 (UTC)

Explain "Security against collision attacks" and "Capacity against length extension attacks" with short examples

In the section SHA-2#Comparison_of_SHA_functions it would help to briefly explain the interpretation of tabulated data for "Security against collision attacks" and "Capacity against length extension attacks" with short examples.

For instance, something like:

"In the above table, if the security against collision attacks is listed as (say) 10 bits, it means that a brute force attack would (on average) need 2^10 attempts to defeat the security; if the capacity against length extension attacks is listed as 20, it means that ...."

or whatever is actually factual. Currently the table requires too much assumed knowledge to understand, and there are insufficient explanations (even considering the wikified links) to clarify for the general reader.

—DIV (137.111.13.4 (talk) 05:36, 2 March 2021 (UTC))

Regarding hashes' backwards compatibility?

I think the current article fails to explain why hashes are not designed to be backwards compatible and the topic should be addressed. (For example, SHA-256 hash of the same file should logically start the exact same as the SHA-1 checksum and only those characters in the extra length "tail" would be different. Similarly SHA-1 would be the same as the MD5, except for the extra characters at the end. That way old computer programs, including those running on very old systems, could verify the unchanged nature of an object to a significant degree of confidence as long as they speak MD5, even if they lack the algorithm or hardware power to calculate SHA-256.) 158.88.16.3 (talk) 13:39, 25 May 2023 (UTC)

A messed up situation 2001:5B0:BAA4:4D80:E08A:868E:FA5B:CC35 (talk) 22:15, 8 August 2024 (UTC)