Editing User talk:Masterzorag
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 189: | Line 189: | ||
We got info0 + info1, 64bytes each | We got info0 + info1, 64bytes each | ||
content is 2845bytes, total is data | content is 2845bytes, total is data lenght 2973 | ||
info0, info1 are not encrypted | info0, info1 are not encrypted | ||
</pre> | </pre> | ||
| Line 394: | Line 394: | ||
*those two needs investigation | *those two needs investigation | ||
1. "''For every digest, we have 1 and only 1 signature (R,S).''"<br /> | |||
Sorry , but don't think so, because as you can have read, r comes from a random number. (I'll check)<br /> | |||
2. "''Pseudo Random number (that used to creating signature) now is F(digest);''"<br /> | |||
They can't be so idiots, since digest is ever known...<br /> | |||
<br /> | |||
=playing on the vsh curve= | =playing on the vsh curve= | ||
| Line 420: | Line 417: | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
|'''m'''<br />You have already seen differences between two files, but maybe some other not. Here a png.<br />Page is telling me that at 0xB0 there is an ECDSA signature, and you are pointing out that we have the same (ECDSA) signature on two different files !?!<br />1. I see your "same signature", but how do you get "metadata digest = DA39A3EE5E6B4B0D3255BFEF95601890AFD80709" from both?<br />2. Conclusion to me are that at 0xB0 there is not an ECDSA signature, so: have you checked? Have you validated? Have you proven that r, s is the valid signature for the digest?<br />3. There is also another aspect to not forget: alignment (%16 = 0), so there is an ECDSA signature in 40 bytes? does not sound good to me...<br />4. SHA-1 produces a fixed | |'''m'''<br />You have already seen differences between two files, but maybe some other not. Here a png.<br />First of all, that wiki page have a lot of "?", so something can be (really) different from what I've read.<br />Page is telling me that at 0xB0 there is an ECDSA signature, and you are pointing out that we have the same (ECDSA) signature on two different files !?!<br />1. I see your "same signature", but how do you get "metadata digest = DA39A3EE5E6B4B0D3255BFEF95601890AFD80709" from both?<br />2. Conclusion to me are that at 0xB0 there is not an ECDSA signature, so: have you checked? Have you validated? Have you proven that r, s is the valid signature for the digest?<br />3. There is also another aspect to not forget: alignment (%16 = 0), so there is an ECDSA signature in 40 bytes? does not sound good to me...<br />4. SHA-1 produces a fixed lenght of 20 bytes: at wiki page I read "''0x40 QA digest, size 0x10 (seems like to be a SHA-1 hash of the non-finalized file) ... Can be ... zeroed on forged file.''" !?!<br />5. There are two ECDSA signatures on an EDAT file and only one to protect CORE_OS_PACKAGE.pkg from alteration !?!?! || [[File:EDATs diff.png|thumbnail|100px]] | ||
|} | |} | ||
<br /> | <br /> | ||
| Line 436: | Line 433: | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
|'''m'''<br /> | |'''m'''<br />I've verified all, as you can see in my shots.<br />I've also noticed one thing that explain something: with zeroed ECDSA signature every digest results in a valid signature!<br />Why?<br />Because the signature becomes the point at infinity!<br />That's because on signature generation when r = 0 you have to select another random integer, as 0 < rand < n! And the same applies for s.<br />But really cool stuff can happen exacly with this kind of crazyness!||[[File:EDAT signatures on vsh curve 1.png|thumbnail|100px]] || [[File:EDAT signatures on vsh curve 2.png|thumbnail|100px]] | ||
|} | |} | ||
<br /> | <br /> | ||
| Line 451: | Line 448: | ||
r = 00a2732e0161e20c290108fdd0b567120c42aab3d2 | r = 00a2732e0161e20c290108fdd0b567120c42aab3d2 | ||
s = 00b894e8775aff90a3cbb6cc08bc918c14f759d439 | s = 00b894e8775aff90a3cbb6cc08bc918c14f759d439 | ||
hash = da39a3ee5e6b4b0d3255bfef95601890afd80709 < | hash = da39a3ee5e6b4b0d3255bfef95601890afd80709 < zerolenght metadata digest | ||
call to check_ecdsa return 1, signature is VALID! | call to check_ecdsa return 1, signature is VALID! | ||
r = 00ff83adbd03d9ba619f3a6d80efef6408561f08d2 | r = 00ff83adbd03d9ba619f3a6d80efef6408561f08d2 | ||
| Line 462: | Line 459: | ||
call to check_ecdsa return 1, signature is VALID! | call to check_ecdsa return 1, signature is VALID! | ||
|| | || | ||
could you try to validate a zeroed signature on two random hash with your implementation?<br /> | could you try to validate a zeroed signature on two random hash with your implementation?<br /> | ||
f0f's one (and derived make_npdata) does not check for 1 < (r, s) < N - 1 as stated in signature verification algorithm, so a zeroed sig is valid for us!!<br /> | f0f's one (and derived make_npdata) does not check for 1 < (r, s) < N - 1 as stated in signature verification algorithm, so a zeroed sig is valid for us!!<br /> | ||
I'm thinking that in EDATs (with two signatures), when metadata length is zero the signature is valid as you told me (and verified), but when signature is zeroed is NOT valid, so maybe the second one act as fallback check!<br /> | |||
|} | |} | ||
<br /> | <br /> | ||