I am using this sample example to do some AES encryption/decyption inside a module. All the calls pass successfully but the decrypted text is not same as the plain text.
[ 4703.053265] encrypting -> plain: bb 2b d7 fb fc c6 0c f6 82 92 cd e1 62 2f 9f 95 .+..........b/..
[ 4703.053277] encrypted: 91 1c 91 51 3c 22 77 dd 82 b4 b7 52 c7 95 af 18 ...Q<"w....R....
[ 4703.053280] Encryption triggered successfully
[ 4703.053290] decrypting -> encrypted: 91 1c 91 51 3c 22 77 dd 82 b4 b7 52 c7 95 af 18 ...Q<"w....R....
[ 4703.053295] decrypted: 31 81 92 38 37 da ac 6c 1b fd 4e 86 a1 1b 06 26 1..87..l..N....&
[ 4703.053297] Decryption triggered successfully
Source at :
https://kernel.readthedocs.io/en/sphinx-samples/crypto-API.html#code-example-for-symmetric-key-cipher-operation
Any hint in right direction would be appreciated !
Storing key and iv in the caller and passing a copy of it to encryption and decryption call works fine.
Related
I'm trying to understang which TLS version is used based on this logs (http trace)
System.Net Information: 0 : [2544] SecureChannel#49129953::.AcquireClientCredentials, new SecureCredential() (flags=(ValidateManual, NoDefaultCred, SendAuxRecord), m_ProtocolFlags=(Ssl3Client, Tls10Client), m_EncryptionPolicy=RequireEncryption)
Algorithm: RSA
Length: 2048
Key Blob: 30 82 01 0a 02 82 01 01 00 b8 de 6a 2c a0 05 1d c1 2e 54 2d de 74 40 a6 83 2b 81 25 29 8d c1 2b e1 4d 4b 63 bd 7f c0 75 fe 15 eb 6b a6 2f 3c 65 d6 7a 55 dc 68 07 1c 6c 2e 8c cd d5 01 74 9f ca ca bb 5e b0 6d 9a 44 d1 1c 74 11 ca 4f 44 fa 59 59 22 f5 f9 c2 00 21 d6 1d a3 09 5a 0e fe da b7 ea d2 c8 55 51 c7 53 90 d1 b9 bf 2c 98 49 75 82 30 ....
System.Net Information: 0 : [2544] SecureChannel#49129953 - Remote certificate was verified as valid by the user.
System.Net Information: 0 : [2544] ProcessAuthentication(Protocol=Tls, Cipher=Aes128 128 bit strength, Hash=Sha1 160 bit strength, Key Exchange=RsaKeyX 2048 bit strength).
Any idea? If you need more log let me know.
Thank you
... m_ProtocolFlags=(Ssl3Client, Tls10Client)
... ProcessAuthentication(Protocol=Tls
Based on this it should be TLS 1.0. For other versions like TLS 1.2 there is probably something like Protocol=Tls12 instead
How does the server using the Certificate Private Key to create Certificate Verify message in TLS 1.3? And how the Client using the Certificate public key to verify the handshake not to be modify? Just in TLS 1.3 not TLS 1.2
As a good overview of the phases of the TLS 1.3 handshake I like to use this site, which breaks down the connection to easier to understand phases then going through the RFC's.
From the above site:
Signature
Because the server is generating ephemeral keys for each
session (optional in TLS 1.2, mandatory in TLS 1.3) the session is not
inherently tied to the certificate as it was in previous versions of
TLS, when the certificate's public/private key were used for key
exchange.
To prove that the server owns the server certificate (giving the
certificate validity in this TLS session), it signs a hash of the
handshake messages using the certificate's private key. The signature
can be proven valid by the client by using the certificate's public
key. 08 04 - reserved value for RSA-PSS-RSAE-SHA256 signature 01 00
- 0x100 (256) bytes of signature data follows 17 fe b5 ... 36 9f 9e - a signature over this handshake's hash We can verify the signature
ourselves using the server's certificate at the command line:
build the data that was signed:
1. add 64 space characters
$ echo -n ' ' > /tmp/tosign
$ echo -n ' ' >> /tmp/tosign
2. add this fixed string
$ echo -n 'TLS 1.3, server CertificateVerify' >> /tmp/tosign
3. add a single null character
$ echo -en '\0' >> /tmp/tosign
4. add hash of handshake to this point
$ handshake_hash=3e66361ada42c7cb97f9a62b00cae1d8b584174c745f9a338cf9f7cdd51d15f8
$ echo $handshake_hash | xxd -r -p >> /tmp/tosign
copy the signature that we want to verify
$ echo "17 fe b5 33 ca 6d 00 7d 00 58 25 79 68 42 4b bc 3a a6 90
9e 9d 49 55 75 76 a5 20 e0 4a 5e f0 5f 0e 86 d2 4f f4 3f 8e b8 61
ee f5 95 22 8d 70 32 aa 36 0f 71 4e 66 74 13 92 6e f4 f8 b5 80 3b
69 e3 55 19 e3 b2 3f 43 73 df ac 67 87 06 6d cb 47 56 b5 45 60 e0
88 6e 9b 96 2c 4a d2 8d ab 26 ba d1 ab c2 59 16 b0 9a f2 86 53 7f
68 4f 80 8a ef ee 73 04 6c b7 df 0a 84 fb b5 96 7a ca 13 1f 4b 1c
f3 89 79 94 03 a3 0c 02 d2 9c bd ad b7 25 12 db 9c ec 2e 5e 1d 00
e5 0c af cf 6f 21 09 1e bc 4f 25 3c 5e ab 01 a6 79 ba ea be ed b9
c9 61 8f 66 00 6b 82 44 d6 62 2a aa 56 88 7c cf c6 6a 0f 38 51 df
a1 3a 78 cf f7 99 1e 03 cb 2c 3a 0e d8 7d 73 67 36 2e b7 80 5b 00
b2 52 4f f2 98 a4 da 48 7c ac de af 8a 23 36 c5 63 1b 3e fa 93 5b
b4 11 e7 53 ca 13 b0 15 fe c7 e4 a7 30 f1 36 9f 9e" | xxd -r -p > /tmp/sig
extract the public key from the certificate
$ openssl x509 -pubkey -noout -in server.crt > server.pub
verify the signature
$ cat /tmp/tosign | openssl dgst -verify server.pub -sha256 \
-sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -signature /tmp/sig
Verified OK
I've generated a public key using openssl
BIGNUM* e = BN_new();
BN_set_word(e, 17);
RSA* rsa = RSA_new();
if(!RSA_generate_key_ex(rsa, 2048, e, NULL)) {
LOG(security, debug) << "failed to generate private key";
}
And these are written to files:
FILE* pubwriter = fopen("key.pub", "wb");
int err = PEM_write_RSAPublicKey(pubwriter, key);
if(!err) {
throw new std::runtime_error("Failed to store public key");
}
FILE* privwriter = fopen("key.priv", "wb");
std::string password = "password";
err = PEM_write_RSAPrivateKey(privwriter, key, EVP_des_ede3_cbc(),
(unsigned char*)password.c_str(),
password.size(), NULL, NULL);
And they seem to be stored correctly, key.pub then contains something like
-----BEGIN RSA PUBLIC KEY-----
MIIBCAKCAQEA0rG1b0g3NIsDT8HkzgTx8BUI9LhueWbH1NuAvIh9qTF57GzEXuTu
jxBcuSzWXlR83ci4oITp7VqV6KLVoJryf8orGXBVi9A73JYOQVB6FEzARKym/g8E
fSEwSmdQ4NfiTESwOCtIextdu3x8pANSYDyyqdiWsSHy0SiZmkbvdVYomIBJZOV9
jhb3mkmD0WUYie9AXziTbli97YqDiN168kMI+7ePpbNJFSVSIUkPPocSgvgcAux/
HuDqftzBgyAF3NGb3AAra1A8T7yPOqLyYyXdIJmF+/Svk5PdMbZVE/U76cjBThch
Q9AiLo25hOjkmtuEQubCuwrUDleblr93aQIBEQ==
-----END RSA PUBLIC KEY-----
Now I want to try these to make sure I haven't got anything wrong but it wont' load:
$ openssl rsautl -encrypt -inkey key.pub -pubin -in data.txt -out enc.txt
unable to load Public Key
What am I missing?
int err = PEM_write_RSAPublicKey(pubwriter, key);
PEM_write_RSAPublicKey writes just the public key. You can make the command work using PEM_write_PUBKEY. The various *_PUBKEY routines write the SubjectPublicKeyInfo, which includes the algorithm OID and public key.
When you write the SubjectPublicKeyInfo, OpenSSL calls it "traditional" format. It will also have the header -----BEGIN PUBLIC KEY----- (and not -----BEGIN RSA PUBLIC KEY-----).
Below, I used PEM_write_PUBKEY to save the public key rsa-public.pem:
$ openssl rsautl -encrypt -inkey rsa-public.pem -pubin -in data.txt -out enc.bin
$ hexdump enc.bin
0000000 45 53 31 ad 9d 6a c4 37 1e 22 4b 83 c6 27 c8 3c
0000010 df cb 87 a4 60 d8 63 9a 83 9f ee ca e5 8f 8e dd
0000020 d4 d0 98 97 1c b3 36 55 f1 84 ea 7f fe bf 22 b6
0000030 93 20 a2 d5 b2 bd 20 cc 52 8e c7 1b 33 e6 40 40
0000040 cb 7d 6f 17 f1 eb f1 d4 9d 66 fb 67 eb 67 ba 2a
0000050 44 c2 52 15 54 8d 79 76 ad 26 61 35 27 9c bb 6c
0000060 5b 0e 79 b3 d3 27 0b a9 72 17 0d 2d 19 d7 60 19
0000070 16 46 80 4b c0 ae 75 53 9e 6f f5 24 d9 1a a3 6a
0000080 2f 38 13 f6 72 19 20 94 de 40 75 20 51 f4 08 f4
0000090 74 b8 ac 49 01 d6 f8 f4 e5 79 38 88 2d 02 b7 bd
00000a0 f7 63 c1 e1 e5 ec 39 a1 fa 7c ce 0f 83 16 70 7e
00000b0 cd 7e f5 6b 51 c2 db d7 f6 c4 46 5d e5 93 d3 3d
00000c0 ab e6 3b 1a 97 d4 c9 54 e7 aa 90 2d 0a b9 c2 4b
00000d0 3c 58 fd 26 58 5a 63 c0 8c ae b9 72 24 a1 68 5d
00000e0 83 d7 5b ae 56 2a 78 46 8c f4 21 96 bd d3 0c 93
00000f0 8e 35 61 9c b8 56 2e 3a 4e 05 d9 1e 0b 59 14 11
0000100
PEM_write_PUBKEY requires a EVP_PKEY. Just use something like:
EVP_PKEY* pkey = EVP_PKEY_new();
ASSERT(pkey != NULL);
int rc = EVP_PKEY_set1_RSA(pkey, rsa);
ASSERT(rc == 1);
...
EVP_PKEY_free(pkey);
The set1 bumps the reference count on the RSA key, so you have to free it through EVP_PKEY_free.
The difference between PEM_write_RSAPublicKey and PEM_write_PUBKEY is very obvious when you save in ASN.1/DER. But it gets lost in the PEM encoding.
Here's the non-traditional key in ASN.1/DER and dumped. Its the ASN.1 equivalent of PEM_write_RSAPublicKey. Its just {n,e}:
$ dumpasn1 rsa-public-1.der
0 266: SEQUENCE {
4 257: INTEGER
: 00 D1 C8 05 BF AC 04 72 AA 0E 84 FB 47 75 59 97
: E1 81 65 0B 0A 1D 9D 2A A8 A1 E0 B1 14 5D 57 69
: D4 D2 E2 C6 64 54 94 C2 92 CC C7 99 1A 97 89 72
: F6 36 6A A7 B8 34 2C AB A9 CB 77 EB 0D A1 4E 72
: 24 9F 96 D6 1C 28 ED 44 E8 0B 22 7F F3 5B 52 E2
: 7E A6 5E F1 7C A2 29 4F F1 8B 9D 0F 94 27 05 D5
: BD 2E 1A AD B4 12 0D E0 69 3E 0B 1B A7 F8 71 B5
: AD 22 4B 18 FF 72 88 F3 C5 77 B0 CF 88 5C F4 19
: [ Another 129 bytes skipped ]
265 3: INTEGER 65537
: }
0 warnings, 0 errors.
Here's the traditional public key in ASN.1/DER and dumped. Its the ASN.1 equivalent of PEM_write_PUBKEY. Its the one that writes the SubjectPublicKeyInfo, and it includes an algorithm OID and public key:
$ dumpasn1 rsa-public-2.der
0 290: SEQUENCE {
4 13: SEQUENCE {
6 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
17 0: NULL
: }
19 271: BIT STRING, encapsulates {
24 266: SEQUENCE {
28 257: INTEGER
: 00 D1 C8 05 BF AC 04 72 AA 0E 84 FB 47 75 59 97
: E1 81 65 0B 0A 1D 9D 2A A8 A1 E0 B1 14 5D 57 69
: D4 D2 E2 C6 64 54 94 C2 92 CC C7 99 1A 97 89 72
: F6 36 6A A7 B8 34 2C AB A9 CB 77 EB 0D A1 4E 72
: 24 9F 96 D6 1C 28 ED 44 E8 0B 22 7F F3 5B 52 E2
: 7E A6 5E F1 7C A2 29 4F F1 8B 9D 0F 94 27 05 D5
: BD 2E 1A AD B4 12 0D E0 69 3E 0B 1B A7 F8 71 B5
: AD 22 4B 18 FF 72 88 F3 C5 77 B0 CF 88 5C F4 19
: [ Another 129 bytes skipped ]
289 3: INTEGER 65537
: }
: }
: }
0 warnings, 0 errors.
err = PEM_write_RSAPrivateKey(privwriter, key, EVP_des_ede3_cbc(),
(unsigned char*)password.c_str(),
password.size(), NULL, NULL);
I believe the OpenSSL folks recommend you use PEM_write_PKCS8PrivateKey. See PEM(3) and pkcs8(1).
Now I want to try these to make sure I haven't got anything wrong but it wont' load:
$ openssl rsautl -encrypt -inkey key.pub -pubin -in data.txt -out enc.txt
You can understand the behavior by looking at <openssl src>/apps/rsautl.c. Here are the relevant lines:
else if (!strcmp(*argv, "-pubin")) {
key_type = KEY_PUBKEY;
}
...
case KEY_PUBKEY:
pkey = load_pubkey(bio_err, keyfile, keyform, 0, NULL, e, "Public Key");
break;
...
Then, in apps.c:
if (format == FORMAT_ASN1) {
pkey = d2i_PUBKEY_bio(key, NULL);
}
...
else if (format == FORMAT_PEM) {
pkey = PEM_read_bio_PUBKEY(key, NULL, ...);
}
...
The observation above is the routines are using *_PUBKEY.
There's also a code path based on format == FORMAT_PEMRSA that calls PEM_read_bio_RSAPublicKey, but I don't know how to trigger it. Looking at rsautl(1), I don't think you can because there's no switch that exposes it.
If it was going to trigger, it would be based on a combination of the -keyform option combined with format == FORMAT_PEMRSA. But apps.c's str2fmt does not return a FORMAT_PEMRSA.
I think that means your only option is to use a SubjectPublicKeyInfo. And that means using PEM_write_PUBKEY (or convert the key after the fact).
Now related: OpenSSL Bug Report, Issue 3887: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails.
I faced the same problem and managed to debug by following #jww answer above. In the process I discover a simple command that does not require a EVP_PKEY.
Just use PEM_write_bio_RSA_PUBKEY(BIO * bp, RSA * x) directly. Read PEM_write documentation for details.
In wireshark, I am able to see the encrypted data to and fro from my PC. It does not use diffie hellman algorihm for key exchange because I see only the Client Key Exchange packet but there is no Server Key Exchange packet. That means the browser is sending the encrypted key to the server(encrypted using the server's public key).
But I do not see any encrypted data in that packet("Client Key Exchange"). How to view the encrypted key?
You won't see the encrypted shared-key, it's not exchanged. You can see the encrypted pre-master secret when using RSA authenticated key exchange. (Note that using Ephemeral Diffie-Hellman isn't the only reason for not seeing a server key exchange message: it could also use a DH_DSS or DH_RSA cipher suite, but this is unusual as far as I know).
If you follow the instructions about decrypting SSL with Wireshark, use the "SSL debug file" option to store the logs into a file. (Note that the user interface has changed slightly in newer versions of Wireshark, in the way you configure the private key.)
The log files will contain the pre-master secret and the shared keys.
(By the way, you need the server's private key to do this, of course.)
Using the sample data provided on the Wireshark page, you get:
pre master encrypted[128]:
65 51 2d a6 d4 a7 38 df ac 79 1f 0b d9 b2 61 7d
73 88 32 d9 f2 62 3a 8b 11 04 75 ca 42 ff 4e d9
cc b9 fa 86 f3 16 2f 09 73 51 66 aa 29 cd 80 61
0f e8 13 ce 5b 8e 0a 23 f8 91 5e 5f 54 70 80 8e
7b 28 ef b6 69 b2 59 85 74 98 e2 7e d8 cc 76 80
e1 b6 45 4d c7 cd 84 ce b4 52 79 74 cd e6 d7 d1
9c ad ef 63 6c 0f f7 05 e4 4d 1a d3 cb 9c d2 51
b5 61 cb ff 7c ee c7 bc 5e 15 a3 f2 52 0f bb 32
pre master secret[48]:
03 00 ff 84 56 6d a0 fb cc fd c6 c8 20 d5 f0 65
18 87 b0 44 45 9c e3 92 f0 4d 32 cd 41 85 10 24
cb 7a b3 01 36 3d 93 27 12 a4 7e 00 29 96 59 d8
master secret[48]:
1e db 35 95 b8 18 b3 52 58 f3 07 3f e6 af 8a a6
ab c3 a4 ed 66 3a 46 86 b6 e5 49 2a 7c f7 8c c2
ac 22 bb 13 15 0f d8 62 a2 39 23 7b c2 ff 28 fb
key expansion[136]:
11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7
b3 f7 33 aa b2 42 d0 1c a6 4e fb e9 9b 13 dd 29
63 aa 17 1f 47 71 95 71 08 e0 4b 8e e1 da 7b 4a
5a f3 c2 32 bd e0 a5 82 6d 14 44 3a d6 cb 2d c0
7d 57 be a8 37 de 5d d9 a1 07 fd 1b 22 71 b9 4b
7a 1e 0f 70 37 14 97 0a f0 db 98 3b 7b 74 e3 2d
51 66 2e 31 68 90 ac 6f e6 53 3c c9 5e 48 0c 05
bc 9f 92 e7 f9 91 98 f5 95 1c c4 bf d9 cb 26 ef
35 70 5e ad 21 22 3e f6
Client MAC key[20]:
11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7
b3 f7 33 aa
Server MAC key[20]:
b2 42 d0 1c a6 4e fb e9 9b 13 dd 29 63 aa 17 1f
47 71 95 71
Client Write key[32]:
08 e0 4b 8e e1 da 7b 4a 5a f3 c2 32 bd e0 a5 82
6d 14 44 3a d6 cb 2d c0 7d 57 be a8 37 de 5d d9
Server Write key[32]:
a1 07 fd 1b 22 71 b9 4b 7a 1e 0f 70 37 14 97 0a
f0 db 98 3b 7b 74 e3 2d 51 66 2e 31 68 90 ac 6f
Client Write IV[16]:
e6 53 3c c9 5e 48 0c 05 bc 9f 92 e7 f9 91 98 f5
Server Write IV[16]:
95 1c c4 bf d9 cb 26 ef 35 70 5e ad 21 22 3e f6
Until recently the dissection of the ClientKeyExchange was like this(version 1.6 and below):
TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 134
Handshake Protocol: Client Key Exchange
Handshake Type: Client Key Exchange (16)
Length: 130
But if you use this verison(1.7.2 upwards) the key dissection will be like this:
TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 134
Handshake Protocol: Client Key Exchange
Handshake Type: Client Key Exchange (16)
Length: 130
RSA Encrypted PreMaster Secret
Encrypted PreMaster length: 128
Encrypted PreMaster: 761b1beac35e59de9a3bb9f74ebf9109b738e8ad346
You can see the encrypted pre-master:)
Awesome write up here explaining how SSL works, notice at no time during this handshake is the private key ever sent over the wire.
http://4orensics.wordpress.com/2011/10/21/ssl-in-a-nutshell/
Long story short there is no way to decrypt SSL streams without the server's private key (unless you work for the NSA or something), however you may want to look into getting in between the server and client during the handshake and if the user does not check the validity of the certificate that is presented you are in business.
Here is a tool that can do that for you among many others
http://mitmproxy.org/
Of note I highly recommend the sans reading room article on SSL Mitm(Man in the Middle) attacks.
I have a RSA 1024 key pair generated using standard call from PKCS#11.
I need to generate a PKCS#10 CSR for the public key.
MS has the IEnroll4 dll which will allow to raise a CSR using createRequestWStr. The samples indicate that you need to generate a new key pair(a container with 2 objects in MS CAPI) and MS automatically gives the the public key context for csr generation.
In my case, I already have a key pair generated using pkcs#11(as 2 objects but no key container). MS dll is not allowing me to proceed further.
QUERY 1:
Can some body point out how I can resolve this issue.
----------------------------------------------------------------------------
Alternatively, I was thinking to write my own code for CSR generation based on RSA standards. I am having the ASN 1.0 format
The ASN.1 syntax for a Certification Request is:
CertificationRequest ::= SEQUENCE {
certificationRequestInfo CertificationRequestInfo,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature
}
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
Signature ::= BIT STRING
CertificationRequestInfo ::= SEQUENCE {
version Version,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
attributes [0] IMPLICIT Attributes
}
Attributes ::= SET OF Attribute
QUERY 2:
How do I use the above syntaxes? I am totally new to this syntax? Which resources should I need to look at to write my own code?
If you need to generate your certificate-request with the PKCS#11-interface (i.e. you cannot use a CSP-interface instead) your best bet is to avoid IEnroll.
For C++ your (free and open source) options seems to be to look into OpenSSL or Botan. I am not terribly fond of OpenSSL's API, but it works. I have never used Botan, but it seems pretty nice. There are also many excellent choices if you are willing to pay for them.
Alternatively, if you want to write the ASN.1 yourself you probably want to read A Layman's Guide to a Subset of ASN.1, BER, and DER. The formal specifications are in X.208 and X.209, but those are hard reading.
You want to generate a DER encoding of the ASN.1 (that is described in the link).
Here is an example encoding:
308201493081b3020100300e310c300a06035504031303666f6f30819d300d06092a864886f70d01
0101050003818b00308187028181009c921beeef551bcb051518f0c48bfe72cb1d5609a64a005e0c
008580bb81b3a43cea280d5bffa4e777733845fc2f485f1c8ccc0b2914f30d1e41369fd4a6758a3c
c887834c4d6177bd96b9f341232b00d453f28f2ae5ad5e3b0324d0b5b440a0901968fd556470dd4d
2ea2e99dd99c580703c042853265374cd3622f6c3369e5020103300d06092a864886f70d01010505
000381810068c0266a16117b37fb15ad143e2941ff8b8f082daf4ec02789db01636f51c739f199fb
19c56228cc12b9e482b966f8650fa3fdb24e31e97eef15f61aabc91dc194aeba4ebce5eab0c5e3db
36cc090a0e4b2c7d3ac27eeb0d3900d73bd88172464b890a8f9a58a0d34c0f5e226b6173cc92a316
4bbbf1d12f29d1e2ad3f36c977
or translated with the excellent dumpasn1 utility:
0 30 329: SEQUENCE {
4 30 179: SEQUENCE {
7 02 1: INTEGER 0
10 30 14: SEQUENCE {
12 31 12: SET {
14 30 10: SEQUENCE {
16 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
21 13 3: PrintableString 'foo'
: }
: }
: }
26 30 157: SEQUENCE {
29 30 13: SEQUENCE {
31 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
42 05 0: NULL
: }
44 03 139: BIT STRING 0 unused bits, encapsulates {
48 30 135: SEQUENCE {
51 02 129: INTEGER
: 00 9C 92 1B EE EF 55 1B CB 05 15 18 F0 C4 8B FE
: 72 CB 1D 56 09 A6 4A 00 5E 0C 00 85 80 BB 81 B3
: A4 3C EA 28 0D 5B FF A4 E7 77 73 38 45 FC 2F 48
: 5F 1C 8C CC 0B 29 14 F3 0D 1E 41 36 9F D4 A6 75
: 8A 3C C8 87 83 4C 4D 61 77 BD 96 B9 F3 41 23 2B
: 00 D4 53 F2 8F 2A E5 AD 5E 3B 03 24 D0 B5 B4 40
: A0 90 19 68 FD 55 64 70 DD 4D 2E A2 E9 9D D9 9C
: 58 07 03 C0 42 85 32 65 37 4C D3 62 2F 6C 33 69
: [ Another 1 bytes skipped ]
183 02 1: INTEGER 3
: }
: }
: }
: }
186 30 13: SEQUENCE {
188 06 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
199 05 0: NULL
: }
201 03 129: BIT STRING 0 unused bits
: 68 C0 26 6A 16 11 7B 37 FB 15 AD 14 3E 29 41 FF
: 8B 8F 08 2D AF 4E C0 27 89 DB 01 63 6F 51 C7 39
: F1 99 FB 19 C5 62 28 CC 12 B9 E4 82 B9 66 F8 65
: 0F A3 FD B2 4E 31 E9 7E EF 15 F6 1A AB C9 1D C1
: 94 AE BA 4E BC E5 EA B0 C5 E3 DB 36 CC 09 0A 0E
: 4B 2C 7D 3A C2 7E EB 0D 39 00 D7 3B D8 81 72 46
: 4B 89 0A 8F 9A 58 A0 D3 4C 0F 5E 22 6B 61 73 CC
: 92 A3 16 4B BB F1 D1 2F 29 D1 E2 AD 3F 36 C9 77
: }