Hi, I am experimenting with pkcs1pad(rsa-generic) signature verify. The following numbers shall serve as examples -- using other valid signatures, similar results are visible. All signatures are correct. The result of the signature verify operation is the following byte stream: 3021300906052b0e03021a05000414ba3bc9c6fb57dfa3103e5991e8992d4387afa6f2d93e4f478d3cb74138b28cc5d1601f2bc549c2297e5bf76578fbaf5defe617748ac29f825aa974a56b7fdffe21f8d5c6abd7d9050525c60d94a36b3ce7a763af66b1ed501ebd0edd4b686a6bb8afd903c9ab97a60853fa7345fdd28fcc The hash of the message is: ba3bc9c6fb57dfa3103e5991e8992d4387afa6f2 The hash of the message is embedded in the data stream returned by the signature verify operation. Looking at the first bytes of the data stream from the signature verify, it looks like an ASN.1 sequence. Looking into the function pkcs1pad_verify_complete, that suspicion is confirmed: the padding is removed, but the decoding is not implemented. Shall a caller implement the decoding? If so, what is the purpose of the pkcs1pad implementation when only a part of the sig ver is implemented? Looking into pkcs1pad_sign, I also do not see the BER encoding. Again, shall the caller do that? Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
