sha256 in libgcrypt/gnupg2

[Ben Clifford]

I felt like trying stupid code linked against something real.

So, I wired the one-block sha256 stupid C implementation into libgcrypt,
replacing the existing sha256 hash code there.

Here's the usual test case with unhacked gpg:

$ echo -n abc | gpg --verbose --print-md sha256
BA7816BF 8F01CFEA 414140DE 5DAE2223 B00361A3 96177A9C B410FF61 F20015AD

and here it is with the stupid-using gpg2:

$ echo -n abc | gpg2 --verbose --print-md sha256
write block - stupid C version (2)
stupid C read hash
BA7816BF 8F01CFEA 414140DE 5DAE2223 B00361A3 96177A9C B410FF61 F20015AD

Now at some size it breaks because it doesn't implement sha256 properly...

$ echo -n 1234567890123456789012345678901234567890123456789012345 | gpg
--verbose --print-md sha256

03C3A70E 99ED5EEC CD80F737 71FCF1EC E643D939 D9ECC76F 25544B02 33F708E9

$ echo -n 12345678901234567890123456789012345678901234567890123456 | gpg
--verbose --print-md sha256

0BE66CE7 2C2467E7 93202906 00067230 66617916 22E0CA9A DF4A8955 B2ED189C

That's not enough to be able to actually sign something with gpg2 using
that hash (in fact, gpg2 crashes when I even attempt that) but it gave me
a nice feeling to see something...

--
http://www.hawaga.org.uk/ben/

[Ben Clifford]

> So, I wired the one-block sha256 stupid C implementation into libgcrypt,
> replacing the existing sha256 hash code there.

Some notes:

A. I needed a prototype for the stupid sha256 function

void sha256(uint8 output[32],uint8 message[64],uint32 message_bits);

in order to call it.

I did this with cut-and-paste but there should be a nicer way. For
example, a .h file could be generated alongside each .c file?

B. The stupid implementation modifies message, which is permitted by this
signature:

void sha256(uint8 output[32],uint8 message[64],uint32 message_bits);

However, what I'm passing in there from gcrypt is flagged const; and in
stupid, because message is an input, it should not be modifiable.

To make the libgcrypt build happy, I manually changed the signature to

void sha256(uint8 output[32],const uint8 message[64],uint32 message_bits);

and inserted code into the stupid-geneated sha256 function to duplicate
message into a locally mutable array.

I think that i) the example sha256 should be modified to not modify
message; and ii) the stupid-C backend should put const modifiers on inputs
to help catch this.

--
http://www.hawaga.org.uk/ben/

[Ben Laurie]

On 21/03/2010 11:05, Ben Clifford wrote:
>
>> So, I wired the one-block sha256 stupid C implementation into libgcrypt,
>> replacing the existing sha256 hash code there.
>
> Some notes:
>
> A. I needed a prototype for the stupid sha256 function
>
> void sha256(uint8 output[32],uint8 message[64],uint32 message_bits);
>
> in order to call it.
>
> I did this with cut-and-paste but there should be a nicer way. For
> example, a .h file could be generated alongside each .c file?

Yeah, that was my plan.

> B. The stupid implementation modifies message, which is permitted by this
> signature:
>
> void sha256(uint8 output[32],uint8 message[64],uint32 message_bits);
>
> However, what I'm passing in there from gcrypt is flagged const; and in
> stupid, because message is an input, it should not be modifiable.
>
> To make the libgcrypt build happy, I manually changed the signature to
>
> void sha256(uint8 output[32],const uint8 message[64],uint32 message_bits);
>
> and inserted code into the stupid-geneated sha256 function to duplicate
> message into a locally mutable array.
>
> I think that i) the example sha256 should be modified to not modify
> message; and ii) the stupid-C backend should put const modifiers on inputs
> to help catch this.

Indeed, and it will be when I get this struct stuff working properly,
and I agree about const modifiers. Also, overflow checks.

--
http://www.apache-ssl.org/ben.html http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

[Ben Laurie]

On 20/03/2010 20:36, Ben Clifford wrote:
>
> I felt like trying stupid code linked against something real.
>
> So, I wired the one-block sha256 stupid C implementation into libgcrypt,
> replacing the existing sha256 hash code there.
>
> Here's the usual test case with unhacked gpg:
>
> $ echo -n abc | gpg --verbose --print-md sha256
> BA7816BF 8F01CFEA 414140DE 5DAE2223 B00361A3 96177A9C B410FF61 F20015AD
>
> and here it is with the stupid-using gpg2:
>
> $ echo -n abc | gpg2 --verbose --print-md sha256
> write block - stupid C version (2)
> stupid C read hash
> BA7816BF 8F01CFEA 414140DE 5DAE2223 B00361A3 96177A9C B410FF61 F20015AD

Cool!

> Now at some size it breaks because it doesn't implement sha256 properly...

Working on it!

[Ben Clifford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Well, I seem to be able to generate signatures with sha256 now that
validate ok (at least for me).

gpg2 --personal-digest-preferences SHA256 --clearsign --output msg.gpg msg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (Darwin)

iQEcBAEBCAAGBQJLpqG5AAoJEELh1osTSZpQtEkH+wbKplUzxaB52xleOGW0/Mkr
uBLCpt6ho8M+5U5CRKHsQXGs1g4KIex/KKAAyH8lFf417gHNZKxbZpZ4yzu0ynS6
rGEmhwjg3SqFtAchu0A4YgmOQZK+u3qTeTjXcgPWQ/JK+tYOjUQ670hFy2VjZOh6
5tXKx0BhWbiZQy0j3gXRXm61e7frC2mrp9nbWkvLE1PW0sG9Q1gfj+W2xNZR6+c1
kjQi+/d9EwZJrIQfIZcboE2kSlPe/GeIMvVtKczr17kqW7VXsSI6p6mUa//bxpcb
eXKURathHKOPh80iOmH7Fodp9EJeB4hcVAxhIkyDWi9Cs8kH9OKkPlQ/Ajumd+c=
=zjSR
-----END PGP SIGNATURE-----

[Ben Clifford]

here's the public key to go with the previous message:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.13 (Darwin)

mQENBEuU5zMBCACwr2Eu/Jj6qey8GcBiQg/aKIVWEPSP40HWQf5+ilN+CA4ydmr7
5s42kJVALacTRXkwEK0DgDV2W5QNOICosLTRMUsZiqo0efIk7zllBSMFmxHj85BX
O6H3l8W4iNTKKaJE1JUMUTz6jeiN672B53TYIdEwEwh+vEEtv/zF3M4RZbERGMvO
hBcDwHY3xrWJ3EIwp8DLHfjS3CKL8Sw8ZWVzxsuAZjD27Xzh9LdGrwkIx1C0fEM+
bdgL7kUfSkARDUn13axDFes/Fdg8Up+Su+o5k6ezTJlmkqEX1jQfgM7F15mQ8DLf
fdxwo0oNkRZCRny39TgMq5M2+sdEoIZagYgJABEBAAG0S3Rlc3Qgb25seSBiZW5j
MSAob25seSBhIHRlc3QsIG5vdCBmb3IgcmVhbCB1c2UuLi4pIDxkb25vdHVzZUBo
YXdhZ2Eub3JnLnVrPokBPgQTAQIAKAUCS5TnMwIbAwUJAeEzgAYLCQgHAwIGFQgC
CQoLBBYCAwECHgECF4AACgkQQuHWixNJmlDyBQf/SR40lKdWUTK+OmCJSkJmNe+E
C2EmvzdmEOL2N4qQBrW2yX7s0gNQYHC/+UKBD3DRvNGRsiv7LH3xYoZLmnoaCDig
S4BJ/zI0ntPhYpCNoCwqncGIN1yhCR9Mpf3fN1rwGZbZCnTrXbpeYg+AcyArZIXD
G830JXRm8vDdAmMqYDcjeiCvq0PYnzzbS2f1wAl5bdHyEG424ZeryqzEq7xHofN/
mXlfAdNpCRt/W+sAgMrX3dyc2BmfiejeVb//AFfWA6mlYi3GNWe4197gCFzOQEuO
1vtnqu6HhplNldO/X92K3mUm07CD2EjD/KY35F6pXhFBh4sCMeDMFGvvby9UW7kB
DQRLlOczAQgAv7n+i8cZ5+OdwOJYjRdo7QRWoWZCW8XPlDEvUjuSS59zCVVavZZA
TuFI9Sbo+EhKPgn2mtDAwCNjNmIEkJ+tnY01T03irgNUB66pREEQ+5Xof39FeXzT
kpLOjeBDcbzdEvUnowWr5YjVQMSBpQ+RWWAWEYeuVDmlShyrqp912hzBvOt/axxK
uJnGCm9CyxiM9F3JA/Sqi16jEnOBrJ9Ixm1HHsXBR68TG+SV5sEsUewvv5oO4i9q
d7R2eqWiKTr+qZOZQ3+QtqtzYge2awlgjx9hhRaLmfPjfavHSk4Nt40sPWW2DQxM
Qei6t54J5MsNX27NL2cY8NCDNAEGadjUWQARAQABiQElBBgBAgAPBQJLlOczAhsM
BQkB4TOAAAoJEELh1osTSZpQ22QIAKyQNsG/uYsJRxMyR2DLdv5psqi21V0PvThr
+PzH834Gajvq5K2huxv62RR8nbbQ0BZhP+qoDzOw/UnPFaPebQbULBRJ4KayAzIN
oOUzmG8pGXXJVL12+g4dgkOGNedKbjgVe6JR2zOAIzUrJRTtx5jd0a7OFzKDfJEg
1y06NjVYKIx9I6uHggnTKTXRFnnmPi6n5homlV7Mkg6wnpGFVq9Jsaiy07fYPU+Q
qbKNy0F78qE5IpQjfVMso3LbY2GTxQB9HCCGu4W2AaMtc29jthC3s3KcADqMeTtN
P5vcgIBMt6tckp1YzXqMbWgVtYWmhSAz7uX4Dw12PFZD6s1LezY=
=CXir
-----END PGP PUBLIC KEY BLOCK-----

--