ctx->data[63] = ctx->bitlen;
ctx->data[62] = ctx->bitlen >> 8;
ctx->data[61] = ctx->bitlen >> 16;
ctx->data[60] = ctx->bitlen >> 24;
ctx->data[59] = ctx->bitlen >> 32;
ctx->data[58] = ctx->bitlen >> 40;
ctx->data[57] = ctx->bitlen >> 48;
ctx->data[56] = ctx->bitlen >> 56;

I ran your code but got this error conversion from 'unsigned __int64' to 'BYTE' from lines that show at the top. Final result is FAILED.

The BYTE and WORD typedefs defined in sha1.h are suboptimal for use in Windows code - Windows resolves WORD to unsigned shorts, which is incompatible with the 32-bit integer that you use (Also, even the identical BYTE typedef will redefine and cause an error). Took me a moment to figure out why the hashes were mostly zero! I suggest using prefixed typedefs or simply stdint.h.

The RC4 cipher generates a constant byte as key stream after a while (~160 characters). The reason is that i and j are initialized to 0 every time arcfour_generate_stream() is called, but they should be part of the global state initialized to 0 only once.

Pseudocode of RC4 PRG algorithm:

i := 0
j := 0
while GeneratingOutput:
    i := (i + 1) mod 256
    j := (j + S[i]) mod 256
    swap values of S[i] and S[j]
    K := S[(S[i] + S[j]) mod 256]
    output K
endwhile

The implementation in this repo:

void arcfour_generate_stream(BYTE state[], BYTE out[], size_t len)
{
    int i, j;
    size_t idx;
    BYTE t;

    for (idx = 0, i = 0, j = 0; idx < len; ++idx)  {
        i = (i + 1) % 256;
        j = (j + state[i]) % 256;
        t = state[i];
        state[i] = state[j];
        state[j] = t;
        out[idx] = state[(state[i] + state[j]) % 256];
    }
}

Maybe I'm just dumb as the test program probably compiles for other people, but it complains about aes_decrypt_cbc() being undeclared. And I'm not seeing it in the aes.h...

Also, I think the base64_test.c isn't working -- it needs to zero the "buf" before doing the encode as well, or the result won't be 0-terminated which makes the strcmp() fail.

As a side note, strcmp()/strlen takes "const char_", while the BYTE_ is unsigned. This probably doesn't affect a C-compilation, though. On the other hand, casts won't affect the C-compilation either, but will fix C++ compilations :-)

And while I'm at it -- the "BYTE ch" at the top of base64_decode() isn't used, which produces a warning to that effect (unless warnings are disabled, of course).

Not sure whether this works, but here's a diff with the suggested changes:
Diff.txt
Might not be the most useful thing, though. I don't know whether the result of "svn diff" can be used for anything other than looking at it :-)

/Sgetz

Hi,

I just download the benchmark. Tried with base64, which fails. Did I make something wrong? Thanks.

parallels:crypto-algorithms$ gcc base64*.c -o a_base64
parallels:crypto-algorithms$ ./a_base64
Base64 tests: FAILED

Zhoulai

int md5_file(char * name, char * out) {
if (name == NULL || out == NULL) {
return -1;
}

MD5_CTX ctx;
md5_init(&ctx);

struct stat st;

if(-1 == stat(name, &st)) {
md5_update(&ctx, name, strlen(name));
}
else {
FILE * fp = fopen(name, "r+");

if (!fp) {
  fprintf(stderr, "md5_file: open file(%s) error!\n", name);
  fclose(fp);
  return -1;
}

char buff[1024];
memset(buff, 0, sizeof(buff));
size_t len = 0;

while (len = fread(buff, 1, sizeof(buff), fp)) {
  md5_update(&ctx, &buff, len);
}

fclose(fp);

}

BYTE digest[MD5_BLOCK_SIZE] = {0};
md5_final(&ctx, digest);

for(int idx = 0; idx < MD5_BLOCK_SIZE; idx += 1) {
sprintf(out + (idx * 2), "%02x", digest[idx]);
}

return 0;
}

Hello,
The finalizing function of hash algorithms doesn't clean up their previously used buffers, as a result, anyone is able to read the data from the context. This is a bad thing as if it's being used to create private hashes, it might be possible that someone can snoop the context and retrieve the hash later.

A small solution would be purging everything with explicit memset function after calling the final function, and only keeping the hash to its target location.

Something like: memset(ctx, 0, sizeof(*ctx)); at the end of the final function.

HI

This is a good Project.

and
Is this Project Support AES256/CBC/PKCS7Padding ???
or something can reference ??

Thanks

sha256("abc") should give:

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f200‌​15ad

but calculates wrong

2bb53935edbba17dc04a04854518754d8a66484491b585b0d0700cd2512f5420

instead.
See also https://stackoverflow.com/questions/22880627/sha256-implementation-in-c

It seems not to be an endianess issue. Any idea?

cannot compile. dev c++ returns the following errors:
254 C:\algorithms-lib\des.c cannot convert bool' toDES_MODE' for argument 3' tovoid des_key_setup(const BYTE_, BYTE ()[6], DES_MODE)'
259 C:\algorithms-lib\des.c cannot convert bool' toDES_MODE' for argument 3' tovoid des_key_setup(const BYTE, BYTE (_)[6], DES_MODE)'

The sha256 output of "aaaaaaaaaa" should be 0xbf2cb58a68f684d95a3b78ef8f661c9a4e5b09e82cc8f9cc88cce90528caeb27.

We would like to integrate the files but need a known licence to know if we are allowed or not.
Could you please add a licence file?

https://github.com/B-Con/crypto-algorithms/blob/master/blowfish.c#L248

On this line it says that the key size supported is 56 bytes (448 bits) or less. However, I believe that this actually supports a key size of up to 72 bytes/576 bits.

At idx=17, idx2=68 in the loop. This means that on the 18th iteration, its reading from bytes 68-71%len.
If len is 72, it seems like that, and not 56, is the upper bound of the key size, anything above that being truncated.

The read from data is promoted to int, and so the left shift by 24 in md5.c may cause signed overflow. This requires cast to an unsigned int:

--- a/md5.c
+++ b/md5.c
@@ -42,3 +42,3 @@ void md5_transform(MD5_CTX *ctx, const BYTE data[])
        for (i = 0, j = 0; i < 16; ++i, j += 4)
-               m[i] = (data[j]) + (data[j + 1] << 8) + (data[j + 2] << 16) + (data[j + 3] << 24);
+               m[i] = (data[j]) + (data[j + 1] << 8) + (data[j + 2] << 16) + ((WORD)data[j + 3] << 24);

UBSan reveals this in the tests:

$ gcc -fsanitize=undefined,address md5_test.c md5.c
$ ./a.out 
md5.c:43:78: runtime error: left shift of 128 by 24 places cannot be represented in type 'int'

Hey,
Can it be used as-is in commercial product for hashing passwords ? No changes at all

Thanks
Nitin