This is the
talk page for discussing improvements to the
SHA-2 article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||||
|
This article links to one or more target anchors that no longer exist.
Please help fix the broken anchors. You can remove this template after fixing the problems. |
Reporting errors |
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)
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)
{{
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)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)
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)
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)
The pseudocode section talks about initializing the 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)
I think also that the red [+] are standard additions, with carry propagation. However they don't overflow past 2^32.
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)
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 h8];
};
void sha256state_init(struct sha256state * S){
S -> h0 = 0x6A09E667;
S -> h1 = 0xBB67AE85;
S -> h2 = 0x3C6EF372;
S -> h3 = 0xA54FF53A;
S -> h4 = 0x510E527F;
S -> h5 = 0x9B05688C;
S -> h6 = 0x1F83D9AB;
S -> h7 = 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 w64];
for (i = 0; i < 16; i += 1) {
uint8_t of;
of = i * 4;
wi =
((uint32_t)dataof << 24) |
((uint32_t)dataof + 1 << 16) |
((uint32_t)dataof + 2 << 8) |
((uint32_t)dataof + 3]);
}
/* Uncompress first 16 integers into 64 ones */
for(i = 16; i < 64; i += 1){
uint32_t s0, s1;
s0 = rightrotate(wi-15], 7) ^
rightrotate(wi-15], 18) ^ (wi-15 >> 3);
s1 = rightrotate(wi-2], 17) ^
rightrotate(wi-2], 19) ^ (wi-2 >> 10);
wi = wi-16 + s0 + wi-7 + s1;
}
/* Copy state */
uint32_t a,b,c,d,e,f,g,h;
a = state -> h0];
b = state -> h1];
c = state -> h2];
d = state -> h3];
e = state -> h4];
f = state -> h5];
g = state -> h6];
h = state -> h7];
/* 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 + ki + wi];
h = g;
g = f;
f = e;
e = d + t1;
d = c;
c = b;
b = a;
a = t1 + t2;
}
/* Push values back to state */
state -> h0 += a;
state -> h1 += b;
state -> h2 += c;
state -> h3 += d;
state -> h4 += e;
state -> h5 += f;
state -> h6 += g;
state -> h7 += 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 buf63];
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 mem64];
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 mem128]; /* 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 */
memmempos = ( 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){
memmempos + 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){
memksi * 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", memi]);
}
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(argv2]);
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(argv1], "r");
if(file == NULL){
fprintf(stderr, "Can't open file\n");
return 2;
}
uint8_t membuffer_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 out32];
sha256hash_get_result(&hash, out);
print_beautiful(out, 32);
return 0;
}
|
748F0F9B-A02C-414F-A819-4253FEE87EE0
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)
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)
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)
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)
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)
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)
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)
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)
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)
If I had more authority, I would remove the data flow picture. (Or if I had time I would replace it).
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)
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
@ 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 ( talk) 20:23, 15 October 2014 (UTC)
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)
This edit request by an editor with a conflict of interest was declined. A consensus could not be reached. |
Would someone please add said external link? — DavidRabahy ( talk) 18:10, 11 December 2014 (UTC)
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)
I understand that changing an image has drawbacks. I just try to explain the motivation for a new schematic SVG image.
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.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.
-- Enrique Santos L. ( talk) 19:09, 25 October 2015 (UTC)
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:
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: 18 January 2022).
Cheers.— cyberbot II Talk to my owner:Online 17:33, 10 January 2016 (UTC)
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:
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: 18 January 2022).
Cheers.— cyberbot II Talk to my owner:Online 00:48, 13 February 2016 (UTC)
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)
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 2L evaluations". If you try 2L 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)
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)
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:
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)
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 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)
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)
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)
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)
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))
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)
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)
Do we profit form it kwanele 16:13, 7 July 2018 (UTC) — Preceding unsigned comment added by Kwanele22 ( talk • contribs)
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
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)
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))
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)