Jaki jest wynikowy format podpisania pliku za pomocą openssl?

Używam tego polecenia do podpisania pliku:

openssl dgst -binary -sha1 -out signedFile.bin -sign file.pem plainText

Chcę wiedzieć, jaki format jest wynikiem tego polecenia. Moim celem jest przeanalizowanie wyniku i wyodrębnienie tablicy mieszającej.

Jaki jest format Czy są jakieś narzędzia do parsowania wyniku?

openssl

— jww
źródło

Nie jestem pewien, czy rozumiem. W tym poleceniu określasz, że powinien on być wyprowadzany jako plik .pem. Do jakiego formatu się odwołujesz?

Pytasz o plik podpisu w formacie binarnym. Rozważ użycie w poleceniu opcji -hex zamiast -binary i sprawdź, czy wynik jest bardziej zgodny z oczekiwaniami.

— zedman9991

@ilikebeets podanym (jedynym) wyjściem jest podpisany plik.bin, który nie powinien być i nie jest PEM. Wiele plików danych openssl jest domyślnie PEM, ale nie ten.

— dave_thompson_085

JEŻELI plik.pem zawiera klucz prywatny RSA (w takim przypadku nazwa ta wprowadza w błąd) wynikiem jest „pusty” podpis RSA PKCS # 1 (v1.5) - liczba N-bitów, gdzie N jest rozmiarem modułu, zaokrąglonym w górę w razie potrzeby, co rzadko zdarza się, ponieważ ludzie zwykle używają rozmiarów kluczy takich jak 1024 i 2048, bez metadanych zwykle używanych z podpisem. dgst -signDomyślnie jest to -binarytak, że jest zbędny (the hash tylko forma dgstnie), ale jak mówi @ zedman9991 można prosić -hex.

Ale parsowanie tego nie ma sensu. To jest liczba. Jeśli chcesz „odzyskać” podpisaną wartość skrótu, którą obsługuje PKCS # 1, ale inne formaty RSA mogą tego nie robić, a inne algorytmy, takie jak DSA i ECDSA, zdecydowanie tego nie robią, musisz (1) wykonać obliczenia modexp-e (często niepoprawnie nazywane „deszyfrowanie za pomocą klucza publicznego”), następnie (2) rozpakuj, a następnie (3) dekoduj ASN.1. „parsowanie” może być rozsądnie użyte w znaczeniu (2) lub (3) lub obu. Możesz napisać program C, aby to zrobić w około 20 liniach. Biorąc pod uwagę plik binarny, rsautl -verifyrobi (1) i (2) (przy dgst -signdomyślnym dopełnieniu do wersji 1.5) i możesz zrobić (3) ręcznie lub za pomocą asn1parse:

c:\work>echo test >in & od -tx1 in
0000000 74 65 73 74 20 20 0d 0a
0000010

c:\work>openssl dgst -sha1 -hex in
SHA1(in)= a02bfe060e0d7857137b7082124541237ed740c7

c:\work>openssl dgst -sha1 -sign rsakey.pem in >sig & od -tx1 sig
0000000 53 e3 68 70 69 d9 fd 1f b1 83 6e eb 1c 6f 58 ab
0000020 b5 44 88 3f d2 67 19 21 9b 95 39 bb ce 2d 7c ac
0000040 51 03 c3 a5 61 7e 47 f6 4b e1 c0 4a 74 ee 7f 29
0000060 b2 cc ff 91 20 97 c4 f9 2e 3e 9f 61 06 62 e3 fe
0000100 ea 4c 3f a6 3b da b4 03 62 81 a7 8c 91 b7 d5 49
0000120 8c d1 e9 92 ff 4b 97 c0 b5 74 59 4d 19 e1 57 c9
0000140 a8 98 f4 c8 df 70 b4 89 57 b0 24 f5 b0 a9 69 b4
0000160 dd ed a0 26 73 bd ca ad a0 f9 e2 0e ea fe 39 8d

c:\work>openssl rsautl -verify -inkey rsakey.pem <sig >rec & od -tx1 rec
Loading 'screen' into random state - done
0000000 30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 a0
0000020 2b fe 06 0e 0d 78 57 13 7b 70 82 12 45 41 23 7e
0000040 d7 40 c7
0000043

c:\work>openssl asn1parse -inform der <rec
    0:d=0  hl=2 l=  33 cons: SEQUENCE
    2:d=1  hl=2 l=   9 cons: SEQUENCE
    4:d=2  hl=2 l=   5 prim: OBJECT            :sha1
   11:d=2  hl=2 l=   0 prim: NULL
   13:d=1  hl=2 l=  20 prim: OCTET STRING      [HEX DUMP]:A02BFE060E0D7857137B7082124541237ED740C7

Wartość ostatniego pola (OCTET STRING) „odzyskanego” podpisu DER, który w tym przypadku jest również jego ostatnimi 20 oktetami, jest wartością skrótu.

(Dla prostego przykładu użyłem 1024-bitowego klucza RSA, a zatem 128-bajtowego podpisu. RSA-1024 jest obecnie uważany za zagrożony awarią w dającej się przewidzieć przyszłości, więc co najmniej 1536, a zwykle 2048 lub więcej jest ogólnie wymagany dla bezpiecznych aplikacji).

— dave_thompson_085
źródło