2012-05-29 28 views
5

RFC 4880 opisuje paczkę wersja 4 Podpis, Tag 2, jakOpenPGP Podpis Packet zakodowane dane

- One-octet signature type. 
- One-octet public-key algorithm. 
- One-octet hash algorithm. 
- Two-octet scalar octet count for following hashed subpacket data. 
Note that this is the length in octets of all of the hashed 
subpackets; a pointer incremented by this number will skip over 
the hashed subpackets. 
- Hashed subpacket data set (zero or more subpackets). 
- Two-octet scalar octet count for the following unhashed subpacket 
data. Note that this is the length in octets of all of the 
unhashed subpackets; a pointer incremented by this number will 
skip over the unhashed subpackets. 
- Unhashed subpacket data set (zero or more subpackets). 
- Two-octet field holding the left 16 bits of the signed hash 
value. 
- One or more multiprecision integers comprising the signature. 

i zakładam, że drugi do ostatniej linii oznacza po prostu wziąć sznur na sub-hashed i mieszania go z algorytm mieszający i pierwsze 2 bajty. jednak bez względu na to, co robię, nie mogę tego uzyskać.

I generowany ten fałszywy klucz dawno temu

-----BEGIN PGP PUBLIC KEY BLOCK----- 
Version: BCPG v1.39 

mQGiBE5B0h8RBAD533Z5bK1IpBx02QyQL0QoJE4uFRIMGDiwXuwmZzVl+R7Vlurd 
GRLsCCbE6vOOh7XQVZGzLEBy9WNzZ9m+EbCfSVAYkjS6FhLws6hG6irrnS+b3JBf 
gFJ8vNGF9Z7bhx+7y7NBk0IMyWkGnUkcnav73t5FQUI2faEBN4c/yAGJZwCgjcB7 
3akWk9XVWvTCsiMXxpyvkukEALXsvB6cOoFEtQq9cQHjP63fBlvD94dhhMiM0cH6 
hW9JotxdK+cxFGG9ZIWgoN2PWbMJka/H4W5EL6tS+YiNAR7I1Ozkt6X16GjnQUzZ 
MlSpleK+KiKVN2anRaPEoOIinHrE3ZXd6QlJ/4+OJn4IVWmSEaJpFf4QNgvEu4rh 
xinyBAD2RNzREOA+wpnFZ4lDt9NZXmXdxQME/l0J9XcvWhpGsxA/MATQKImy7N49 
7GT/M38F+TrpBobag1O3buE99fOLyws4Tbc+sZMdHxoiGZDAIRNQS2rv475E6ktj 
7vd5CYvOkA6+8sX1+hPcNlkHtHB1OFkJRsYp6k0zkyC9adjBM7QTYWJjIDxtYWtj 
bUBhYWEuY29tPohGBBMRAgAGBQJOQdIfAAoJEDBSJUXPd92GRSQAoItbtbToOg7a 
/hcg2sA/aBEQNwuxAKCGR69vmSoCWoBP5waPk0UsjM3BSbjMBE5B0h8QAgCUlP7A 
lfO4XuKGVCs4NvyBpd0KA0m0wjndOHRNSIz44x24vLfTO0GrueWjPMqRRLHO8zLJ 
S/BXO/BHo6ypjN87Af0VPV1hcq20MEW2iujh3hBwthNwBWhtKdPXOndJGZaB7lsh 
LJuWv9z6WyDNXj/SBEiV1gnPm0ELeg8Syhy5pCjMAf9QHehP2eCFqfEwTAnaOlA6 
CU+rYHKPZaI9NUwCA7qD2d93/l08/+ZtFvejZW1RWrJ8qfLDRtlPgRzigoF/CXbR 
iEYEGBECAAYFAk5B0h8ACgkQMFIlRc933YZRrACfUnWTjHHN+QsEEoJrwRvFmvzj 
bR4An24pTpeeN+I6R59O/sdmYsAhjULX 
=sStS 
-----END PGP PUBLIC KEY BLOCK----- 

co myślę im robić:

sha1("\x05\x02\x4e\x41\xd2\x1f") = "52f07613cfd61c80d2343566a8f3f487a0975b80" 

\x05 - length of subpacket 
\x02 - subpacket type 
\x4e\x41\d2\x1f - creation time 

Od pgpdump.net, widzę, że lewa 2 bajty hash (SHA 1) wartość to 45 24 dla pierwszego pakietu podpisu i 51 ac dla drugiego. otrzymuję 52 f0 dla obu. oczywiście, nie obejmuję niektórych informacji, ale co to jest? zakodowane sub-pakiety są identyczne, a wszystkie dane przed hasłami są takie same, z wyjątkiem różnych typów pakietów sygnatur (0x13/0x18). nie mogłem uzyskać żadnej z poprawnych wartości skrótu, nawet gdy dodaję/biorę znaki z pakietu danych. klucz generujący jest dokładnie taki sam, jak pokazany tutaj klucz z wyjątkiem wartości mieszania.

jakie są dane, które powinienem mieszać?

edit: jeśli znajdzie to trochę później:

The concatenation of the data being signed and the signature data 
from the version number through the hashed subpacket data (inclusive) 
is hashed. The resulting hash value is what is signed. The left 16 
bits of the hash are included in the Signature packet to provide a 
quick test to reject some invalid signatures. 

ale jaka jest dane są podpisane? wszystkie pakiety przed podpisaniem? tylko pakiet przed aktualnym pakietem sygnatur?

Kluczowy przykład tam składa się z packet 6 + packet 13 + packet 2 + packet 14 + packet 2. Próbowałem wszystkie rodzaje połączeń packet 6, packet 13 i packet 2 (z numerem wersji do zakodowane dane włącznie), ale nadal nie można znaleźć ciąg, który mieszań do prawidłowych wartości

Odpowiedz

2

Podczas generowania pakiet podpisu, to zawsze podpis z coś przez ktoś. Oznacza to, że istnieje pewna ilość danych, które są podpisywane, oraz klucz publiczny, a punktem podpisu jest to, że jest to coś, co powinno być możliwe tylko dla kogoś, kto ma takie dokładne dane i odpowiedni klucz prywatny.

Tak więc "dane będące w trakcie podpisywania" będą takie same, jakimi są blob danych. W niektórych przykładach patrz sekcja 5.2.1 dokumentu RFC4880. W tym przypadku prawdopodobnie interesują Cię pakiety sygnatur wewnątrz twojego bloku kluczy publicznych.

Pierwsza z nich to "Pozytywna certyfikacja identyfikatora użytkownika i pakietu klucza publicznego (0x13)". Jest to opisane w sekcji 5.2.4 dokumentu RFC4880.

Drugi to "sygnatura oprawy podpasma", przy czym klucz podstawowy (DSA) gwarantuje, że podklucz (tylko szyfrowanie ElGamal) należy do niego. Sposób, w jaki to działa, jest również opisany w sekcji 5.2.4 dokumentu RFC4880.

Oto odpowiedni tekst z 5.2.4:

Jeżeli podpis jest na klucz, dane hash rozpoczyna się oktetu 0x99, a następnie przez dwie długości oktetu na klucz, a następnie ciało kluczowego pakietu. (Zauważ, że jest to nagłówek pakietu w starym stylu dla pakiet klucza o długości dwóch oktetów.) Podpis pod klucz (typ 0x18) lub podpis klucza podstawowego (typ 0x19), a następnie przypisuje podklucz przy użyciu tego samego formatu jako główny klucz (także przy użyciu 0x99 jako pierwszego oktetu ). Kluczowe podpisy odwołania (typy 0x20 i 0x28) zawierają wartość tylko ten klucz jest unieważniany.

a następnie

Podpis certyfikatu (typ 0x10 przez 0x13) mieszań identyfikator użytkownika wiążąc się klucz do mieszania po kontekście powyższych danych. Certyfikat V3 miesza zawartość identyfikatora użytkownika lub atrybutu pakietu , bez nagłówka. Certyfikacja V4 skróty do stałą 0xb4 dla certyfikaty identyfikator użytkownika lub stałej 0xD1 dla certyfikatów użytkownika cechę, po której następuje numer cztery oktetu podając długość identyfikatora użytkownika lub danych atrybutu , a następnie identyfikator użytkownika lub Użytkownika Atrybut danych.