This question already has answers here:
Encrypt a string using openssl command line
(5 answers)
Closed 6 years ago.
I read this article about the Pirate Bay's secret AES encrypted message being solved. (this is old news)
The solver used this command in his linux terminal to decrypt the message.
echo "JyO7wNzc8xht47QKWohfDVj6Sc2qH+X5tBCT+uetocIJcjQnp/2f1ViEBR+ty0Cz" | openssl aes-128-cbc -K $(printf wearetpb | sha256sum | head -c 32 | tr '[:lower:]' '[:upper:]') -nosalt -nopad -iv 0 -base64 -d -p
The decrpyted message was a link: https://www.youtube.com/watch?v=-YEG9DgRHhA
I want to encrpyt my own custom message the same way the Pirate Bay did. I assume I would need to change the encrypted text to my custom message and change the command to encrypt, rather than decrypt. But how do I do this?
It should be as simple as:
echo -n "https://stackoverflow.com/q/39197703/5128464" | openssl aes-128-cbc -K $(printf wearetpb | sha256sum | head -c 32 | tr '[:lower:]' '[:upper:]') -nosalt -iv 0 -e -base64
Giving ciphertext:
l3iwQZrEe8R55MQMu13Hn2S+MvKs46fLT6rVP3yiJqvCPwAzJLrnZph1fYX1qDkk
Which then can be decrypted (using the same technique, key, etc.):
echo "l3iwQZrEe8R55MQMu13Hn2S+MvKs46fLT6rVP3yiJqvCPwAzJLrnZph1fYX1qDkk" | openssl aes-128-cbc -K $(printf wearetpb | sha256sum | head -c 32 | tr '[:lower:]' '[:upper:]') -nosalt -nopad -iv 0 -base64 -d
Giving back the plaintext:
https://stackoverflow.com/q/39197703/5128464
But if you look carefully at the original decrypted text (i.e. dump the actual message bytes):
echo "JyO7wNzc8xht47QKWohfDVj6Sc2qH+X5tBCT+uetocIJcjQnp/2f1ViEBR+ty0Cz" | openssl aes-128-cbc -K $(printf wearetpb | sha256sum | head -c 32 | tr '[:lower:]' '[:upper:]') -nosalt -nopad -iv 0 -base64 -d | xxd -g1
You get this (please note the five '00' bytes at the end of output):
0000000: 68 74 74 70 73 3a 2f 2f 77 77 77 2e 79 6f 75 74 https://www.yout
0000010: 75 62 65 2e 63 6f 6d 2f 77 61 74 63 68 3f 76 3d ube.com/watch?v=
0000020: 2d 59 45 47 39 44 67 52 48 68 41 00 00 00 00 00 -YEG9DgRHhA.....
And if you repeat the same for the previous result:
echo "l3iwQZrEe8R55MQMu13Hn2S+MvKs46fLT6rVP3yiJqvCPwAzJLrnZph1fYX1qDkk" | openssl aes-128-cbc -K $(printf wearetpb | sha256sum | head -c 32 | tr '[:lower:]' '[:upper:]') -nosalt -nopad -iv 0 -base64 -d | xxd -g1
You get a different ending (this time there are five '05' bytes):
0000000: 68 74 74 70 3a 2f 2f 73 74 61 63 6b 6f 76 65 72 http://stackover
0000010: 66 6c 6f 77 2e 63 6f 6d 2f 71 2f 33 39 31 39 37 flow.com/q/39197
0000020: 37 30 33 2f 35 31 32 38 34 36 34 05 05 05 05 05 703/5128464.....
Those bytes are called padding bytes and must be added as AES cipher in CBC mode can not process messages whose length is not N*128 bits (i.e. which can not be divided into 16-byte blocks)
The padding used in the original plaintext (i.e. 00 00 00 00 00) is a zero padding, but the second one (04 04 04 04) is a PKCS7 padding.
Unfortunately zero padding is not directly supported in the openssl command line utilities, so you have to add it manually (note the added zero bytes and an additional -nopad option):
echo -ne "https://stackoverflow.com/q/39197703/5128464\0\0\0\0\0" | openssl aes-128-cbc -K $(printf wearetpb | sha256sum | head -c 32 | tr '[:lower:]' '[:upper:]') -nosalt -nopad -iv 0 -e -base64
Giving:
l3iwQZrEe8R55MQMu13Hn2S+MvKs46fLT6rVP3yiJquYbIGPlGOBxJxJmU/bXocR
You can check the padding of the new plaintext with:
echo "l3iwQZrEe8R55MQMu13Hn2S+MvKs46fLT6rVP3yiJquYbIGPlGOBxJxJmU/bXocR" | openssl aes-128-cbc -K $(printf wearetpb | sha256sum | head -c 32 | tr '[:lower:]' '[:upper:]') -nosalt -nopad -iv 0 -base64 -d | xxd -g1
To see that the padding is correct now:
0000000: 68 74 74 70 3a 2f 2f 73 74 61 63 6b 6f 76 65 72 http://stackover
0000010: 66 6c 6f 77 2e 63 6f 6d 2f 71 2f 33 39 31 39 37 flow.com/q/39197
0000020: 37 30 33 2f 35 31 32 38 34 36 34 00 00 00 00 00 703/5128464.....
If you wanted to generate the padding in the shell, see e.g. here (under EDIT3).
Good luck!
Related
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'm developing a C project to read/write Desfire Contactless Cards.
Right now I achieved to authenticate and I'm able to read data from the card, but it's encrypted with 3DES.
I want to decrypt next message:
EB 54 DF DD 07 6D 7C 0F BD D6 D1 D1 90 C6 C7 80 92 F3 89 4D 6F 16 7C BF AA 3E 7C 48 A8 71 CF A2 BD D0 43 07 1D 65 B8 7F
My SessionKey (generated in Authentication step) is:
44 E6 30 21 4A 89 57 38 61 7A B8 7C A9 91 B2 C0
I know the IV={ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }
With this information, I can go here and choosing 3DES, CBC mode, I can decrypt the message and I have means to know that it's right.
It should be, decrypted:
10 1a 01 31 32 ae 03 de 39 b0 00 97 7f 65 e9 43 93 89 53 5c 9e 04 a9 3f 95 71 24 0f 0a 9b f7 ee d4 5b 1b c6 78 7a f4 36
Anyhow, I tried to implement the C code using OpenSSL des library and I find the next difficulty:
I need 3 Keys of 8 bytes each, but I have 1 SessionKey of 16 bytes
long.
I tried to split SessionKey into Key1/Key2/Key1 without success.
I have read so much about it, the only clue i found is that I have to generate those 3 keys from my 16byte SessionKey (taking it as a password) but I feel it is too advanced for me.
If this is the only way, is there any tutorial about ossl key derivation (evp_bytestokey)? Is there any other way?
Thanks
Edit:
So, right now I'm in a very weird spot. As noted by many of you, I had already taken first 8 bytes from Session Key as Key 3 (that's what I referred to with Key1/Key2/Key1). Anyway it seemed to not work, but slightly it did, which is what puzzles me.
I get:
Decrypted : 11 1B 00 30 33 AF 02 DF DE 01 00 00 00 01 01 00 14 C1 26 8F 03 20 20 41 00 30 39 01 00 00 00 00 00 00 00 00 00 00 75 B1
When
Expected : 10 1a 01 31 32 ae 03 de de 01 00 00 00 01 01 00 14 c1 26 8f 03 20 20 41 00 30 39 01 00 00 00 00 00 00 00 00 00 00 75 b1
So I get the expected result XORing first 8 bytes with 01. Does that make any sense?? As in OSSL docu it says: Note that there is both a DES_cbc_encrypt() and a DES_ncbc_encrypt() in libcrypto. I recommend you only use the ncbc version (n stands for new). See the BUGS section of the OpenSSL DES manpage and the source code for these functions.
But I have access only to older version... Could it be the problem??
Perhaps the encryption is two-key 3DES, in that case repeat the first 8-bytes , bytes 0-7 as bytes 16-23: 44 E6 30 21 4A 89 57 38 61 7A B8 7C A9 91 B2 C0 44 E6 30 21 4A 89 57 38.
Some 3DES implementations will do this automatically, some you must do it yourself.
If this does not work you will need to provide more information in the question.
Size of session key
Since you refer to MIFARE DESFire and you are using a 16 byte session key, you probably use 2-key triple DES. This means that the 16 byte session key is actually two keys (8 bytes, or actually 56 bits, each with 8 unused "parity" bits).
In order to map this to 3DES with 3 keys, you simply need to append the first 8 bytes to the end of your session key, so that you get
+-------------------------+-------------------------+
16 byte session key: | 8 bytes | 8 bytes |
| 44 E6 30 21 4A 89 57 38 | 61 7A B8 7C A9 91 B2 C0 |
+-------------------------+-------------------------+-------------------------+
24 byte 3DES key: | 8 bytes | 8 bytes | 8 bytes |
| 44 E6 30 21 4A 89 57 38 | 61 7A B8 7C A9 91 B2 C0 | 44 E6 30 21 4A 89 57 38 |
+-------------------------+-------------------------+-------------------------+
First block of decrypted plaintext
If the first 8 bytes of the decrypted plaintext differ from the expected value but the remaining bytes match, this is a clear indication that you are using an incorrect initialization vector for CBC mode.
Have a look at how CBC mode works:
So for the first block, the plaintext is calculated as
P0 = DecK(C0) XOR IV
For the remaining blocks, the plaintext is calculated as
Pn = DecK(Cn) XOR Cn-1
This means that only the decryption of the first block depends on the IV. The decryption of the remaining blocks depends on the preceding ciphertext instead.
Since you assumed the IV to be all zeros, the XOR operation does nothing. Hence, in your case, the plaintext of the first block is calculated as
P0 = DecK(C0) XOR {0} = DecK(C0) = '10 1A 01 31 32 AE 03 DE'
As this expected value deviates from the actual value that you get ('11 1B 00 30 33 AF 02 DF'). This most likely means that you used an incorrect IV for decryption:
P0 = DecK(C0) = '10 1A 01 31 32 AE 03 DE'
P'0 = DecK(C0) XOR IV = '11 1B 00 30 33 AF 02 DF'
You can calculate the IV that you used by XORing the two values:
P'0 = P0 XOR IV
P'0 XOR P0 = IV
IV = '11 1B 00 30 33 AF 02 DF' XOR '10 1A 01 31 32 AE 03 DE'
= '01 01 01 01 01 01 01 01'
As this IV differs in exactly the LSB of each byte being set to one, I wonder if you accidentally used the method DES_set_odd_parity() on the IV. This would explain why the LSB (i.e. the parity bit if the value was a DES key) was changed.
It's possible that you don't need 3 keys of 32bits, but only one of 3*32bits, with the bytes in the good order
Best regards
I have a file, in which I have to find and change strings by specific pattern (phone number). The regex is:
^\+[0-9]{3} \([0-9]{2}\) [0-9]{7}$
When I use it in command:
grep "^\+[0-9]{3} \([0-9]{2}\) [0-9]{7}$" -E filename
It works. But when I try to use it in sed to replace all parenthesis by spaces and add spaces in 13 and 15 position, it doesn't works and I don't have ideas why.
My variants are:
sed '/^\+[0-9]{3} \([0-9]{2}\) [0-9]{7}$/s/[()]//' filename
(only for replacing parenthesis)
sed -e '/^\+[0-9]{3} \([0-9]{2}\) [0-9]{7}$/s/[()]//' -e '/^+[0-9]{2} ([0-9]{2}) [0-9]{7}/s/./& /11;s/./& /14' filename
file structure:
+380 44 123 45 67
+380 (44) 1234567
+350 (56) 1454557
+330 (76) 1255557
+380 44 3534 45 67
+320 (45) 1237887
+310 (54) 1939997
adasd
asdddddddddddd
sssdad
expected output:
+380 44 123 45 67
+380 44 123 45 67
+350 56 145 45 57
+330 76 125 55 57
+380 44 3534 45 67
+320 45 123 78 87
+310 54 193 99 97
adasd
asdddddddddddd
sssdad
Here's one way to do it:
$ cat ip.txt
+380 44 123 45 67
+380 (44) 1234567
+350 (56) 1454557
+330 (76) 1255557
+380 44 3534 45 67
+320 (45) 1237887
+310 (54) 1939997
adasd
asdddddddddddd
sssdad
$ sed -E 's/^(\+[0-9]{3}) \(([0-9]{2})\) ([0-9]{3})([0-9]{2})([0-9]{2})$/\1 \2 \3 \4 \5/' ip.txt
+380 44 123 45 67
+380 44 123 45 67
+350 56 145 45 57
+330 76 125 55 57
+380 44 3534 45 67
+320 45 123 78 87
+310 54 193 99 97
adasd
asdddddddddddd
sssdad
() can be used to surround a pattern so that the matched text inside them can be backreferenced in replacement section
\1 corresponds to first such captured group, \2 to second and so on
To match ( or ) themselves, we need to use escape them like \( and \)
So, here the numbers are captured as per required output, excluding the () present in input line so that they are not part of output
Your sed command is wrong.
My way:
sed -E 's/^\+[0-9]{3} \([0-9]{2}\) [0-9]{7}$/[()]/'
Use:
sed -e 's|[()]||g' so-tel.txt | sed -E 's|([0-9]{3})([0-9]{2})([0-9]{2})|\1 \2 \3|'
to transform so-tel.txt:
+380 44 123 45 67
+380 (44) 1234567
+350 (56) 1454557
+330 (76) 1255557
+380 44 3534 45 67
+320 (45) 1237887
+310 (54) 1939997
adasd
asdddddddddddd
sssdad
into:
+380 44 123 45 67
+380 44 123 45 67
+350 56 145 45 57
+330 76 125 55 57
+380 44 3534 45 67
+320 45 123 78 87
+310 54 193 99 97
adasd
asdddddddddddd
sssdad
Explanation:
's|[()]||g'
substitute any ( and ) with nothing, globally
's|([0-9]{3})([0-9]{2})([0-9]{2})|\1 \2 \3|'
substitute and capture seven successive digits in lengths 3, 2, and 2, with the captured digit groups separated by a space.
An SHA1 digest should be 160 bits long. Still it is normally represented as a string with 40 characters. Considering 8-bits-bytes and that 1 char corresponds to 1 byte, it seems to me the SHA1 digest should have 20 bytes and it's hex representation 40 bytes.
For example, using OpenSSL I could get the following results (after manually removing extra information added):
PLAIN MESSAGE: The only possible revolution is inside us
openssl dgst -sha1 -hex dgsttxt &> sha1_hex
32 64 66 61 33 35 66 62 35 37 34 65 36 62 65 36 32 33 62 37 63 36 31 61 63 61 32 63 61 31 65 66 39 30 36 62 39 63 38 34
openssl dgst -sha1 -binary dgsttxt &> sha1_binary
2D FA 35 FB 57 4E 6B E6 23 B7 C6 1A CA 2C A1 EF 90 6B 9C 84
Applying a wc in each file I get
wc sha1_binary sha1_hex
0 1 20 sha1_binary
0 1 40 sha1_hex
0 2 60 total
So I have two questions:
Why are there 20 more characters in the hex dump?
How are those extra bits inserted? I could note each byte in the hex dump starts with either 3 or 6. Is there a particular reason for that?
I have already seen a similar question here but I am not sure if I am too stupid to understand the answers or if they are really poor. Any help is appreciated.
160 bits / 8 = 20 bytes; a byte in hex is 2 characters (00 to FF) and 2 * 20 = 40 hex characters.
The longer output is the hexadecimally encoded version of the hexadecimal encoded hash.
Quite what the point of that is, who knows.
var s = "32 64 66 61 33 35 66 62 35 37 34 65 36 62 65 36 32 33 62 37 63 36 31 61 63 61 32 63 61 31 65 66 39 30 36 62 39 63 38 34".split(" ");
for (var i = 0; i < s.length; i++)
{
document.write( String.fromCharCode(parseInt(s[i], 16)) );
}
Where can i find some documentation on the format of an RSA public key?
An RSA public key formatted by OpenSSH:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQB/nAmOjTmezNUDKYvEeIRf2YnwM9/uUG1d0BYsc8/tRtx+RGi7N2lUbp728MXGwdnL9od4cItzky/zVdLZE2cycOa18xBK9cOWmcKS0A8FYBxEQWJ/q9YVUgZbFKfYGaGQxsER+A0w/fX8ALuk78ktP31K69LcQgxIsl7rNzxsoOQKJ/CIxOGMMxczYTiEoLvQhapFQMs3FL96didKr/QbrfB1WT6s3838SEaXfgZvLef1YB2xmfhbT9OXFE3FXvh2UPBfN+ffE7iiayQf/2XR+8j4N4bW30DiPtOQLGUrH1y5X/rpNZNlWW2+jGIxqZtgWg7lTy3mXy5x836Sj/6L
The same public key formatted for use in Secure Shell (RFC 4716 - The Secure Shell (SSH) Public Key File Format):
---- BEGIN SSH2 PUBLIC KEY ----
AAAAB3NzaC1yc2EAAAABJQAAAQB/nAmOjTmezNUDKYvEeIRf2YnwM9/uUG1d0BYs
c8/tRtx+RGi7N2lUbp728MXGwdnL9od4cItzky/zVdLZE2cycOa18xBK9cOWmcKS
0A8FYBxEQWJ/q9YVUgZbFKfYGaGQxsER+A0w/fX8ALuk78ktP31K69LcQgxIsl7r
NzxsoOQKJ/CIxOGMMxczYTiEoLvQhapFQMs3FL96didKr/QbrfB1WT6s3838SEaX
fgZvLef1YB2xmfhbT9OXFE3FXvh2UPBfN+ffE7iiayQf/2XR+8j4N4bW30DiPtOQ
LGUrH1y5X/rpNZNlWW2+jGIxqZtgWg7lTy3mXy5x836Sj/6L
---- END SSH2 PUBLIC KEY ----
The same public key formatted as an RSA public key (note the five -, and no space):
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEA+xGZ/wcz9ugFpP07Nspo6U17l0YhFiFpxxU4pTk3Lifz9R3zsIsu
ERwta7+fWIfxOo208ett/jhskiVodSEt3QBGh4XBipyWopKwZ93HHaDVZAALi/2A
+xTBtWdEo7XGUujKDvC2/aZKukfjpOiUI8AhLAfjmlcD/UZ1QPh0mHsglRNCmpCw
mwSXA9VNmhz+PiB+Dml4WWnKW/VHo2ujTXxq7+efMU4H2fny3Se3KYOsFPFGZ1TN
QSYlFuShWrHPtiLmUdPoP6CV2mML1tk+l7DIIqXrQhLUKDACeM5roMx0kLhUWB8P
+0uj1CNlNN4JRZlC7xFfqiMbFRU9Z4N6YwIDAQAB
-----END RSA PUBLIC KEY-----
The hex dump of the base-64 encoded data:
00 00 00 07 73 73 68 2d 72 73 61 00 00 00 01 25 00 00 01 00 7f 9c 09
8e 8d 39 9e cc d5 03 29 8b c4 78 84 5f d9 89 f0 33 df ee 50 6d 5d d0
16 2c 73 cf ed 46 dc 7e 44 68 bb 37 69 54 6e 9e f6 f0 c5 c6 c1 d9 cb
f6 87 78 70 8b 73 93 2f f3 55 d2 d9 13 67 32 70 e6 b5 f3 10 4a f5 c3
96 99 c2 92 d0 0f 05 60 1c 44 41 62 7f ab d6 15 52 06 5b 14 a7 d8 19
a1 90 c6 c1 11 f8 0d 30 fd f5 fc 00 bb a4 ef c9 2d 3f 7d 4a eb d2 dc
42 0c 48 b2 5e eb 37 3c 6c a0 e4 0a 27 f0 88 c4 e1 8c 33 17 33 61 38
84 a0 bb d0 85 aa 45 40 cb 37 14 bf 7a 76 27 4a af f4 1b ad f0 75 59
3e ac df cd fc 48 46 97 7e 06 6f 2d e7 f5 60 1d b1 99 f8 5b 4f d3 97
14 4d c5 5e f8 76 50 f0 5f 37 e7 df 13 b8 a2 6b 24 1f ff 65 d1 fb c8
f8 37 86 d6 df 40 e2 3e d3 90 2c 65 2b 1f 5c b9 5f fa e9 35 93 65 59
6d be 8c 62 31 a9 9b 60 5a 0e e5 4f 2d e6 5f 2e 71 f3 7e 92 8f fe 8b
i've read that there are a couple of formats🕗:
Key data may be encoded in three general ways:
Binary DER-encoded format. This is sometimes called ASN.1 BER-encoded
PEM or base64 format. This is the same data as the DER-encoded file but it is encoded in base64 with additional header and footer lines
XML format.
If it's ASN.1, the hex certainly doesn't look like it.
What's the format of an RSA public key?
See also
RSA Key Formats
Abstract Syntax Notation One
Convert Base64 Public Key to XML Signature 🕗
Decode PEM formats
You can't just change the delimiters from ---- BEGIN SSH2 PUBLIC KEY ---- to -----BEGIN RSA PUBLIC KEY----- and expect that it will be sufficient to convert from one format to another (which is what you've done in your example).
This article has a good explanation about both formats.
What you get in an RSA PUBLIC KEY is closer to the content of a PUBLIC KEY, but you need to offset the start of your ASN.1 structure to reflect the fact that PUBLIC KEY also has an indicator saying which type of key it is (see RFC 3447). You can see this using openssl asn1parse and -strparse 19, as described in this answer.
EDIT: Following your edit, your can get the details of your RSA PUBLIC KEY structure using grep -v -- ----- | tr -d '\n' | base64 -d | openssl asn1parse -inform DER:
0:d=0 hl=4 l= 266 cons: SEQUENCE
4:d=1 hl=4 l= 257 prim: INTEGER :FB1199FF0733F6E805A4FD3B36CA68E94D7B974621162169C71538A539372E27F3F51DF3B08B2E111C2D6BBF9F5887F13A8DB4F1EB6DFE386C92256875212DDD00468785C18A9C96A292B067DDC71DA0D564000B8BFD80FB14C1B56744A3B5C652E8CA0EF0B6FDA64ABA47E3A4E89423C0212C07E39A5703FD467540F874987B209513429A90B09B049703D54D9A1CFE3E207E0E69785969CA5BF547A36BA34D7C6AEFE79F314E07D9F9F2DD27B72983AC14F1466754CD41262516E4A15AB1CFB622E651D3E83FA095DA630BD6D93E97B0C822A5EB4212D428300278CE6BA0CC7490B854581F0FFB4BA3D4236534DE09459942EF115FAA231B15153D67837A63
265:d=1 hl=2 l= 3 prim: INTEGER :010001
To decode the SSH key format, you need to use the data format specification in RFC 4251 too, in conjunction with RFC 4253:
The "ssh-rsa" key format has the following specific encoding:
string "ssh-rsa"
mpint e
mpint n
For example, at the beginning, you get 00 00 00 07 73 73 68 2d 72 73 61. The first four bytes (00 00 00 07) give you the length. The rest is the string itself: 73=s, 68=h, ... -> 73 73 68 2d 72 73 61=ssh-rsa, followed by the exponent of length 1 (00 00 00 01 25) and the modulus of length 256 (00 00 01 00 7f ...).
Starting from the decoded base64 data of an OpenSSL rsa-ssh Key, i've been able to guess a format:
00 00 00 07: four byte length prefix (7 bytes)
73 73 68 2d 72 73 61: "ssh-rsa"
00 00 00 01: four byte length prefix (1 byte)
25: RSA Exponent (e): 25
00 00 01 00: four byte length prefix (256 bytes)
RSA Modulus (n):
7f 9c 09 8e 8d 39 9e cc d5 03 29 8b c4 78 84 5f
d9 89 f0 33 df ee 50 6d 5d d0 16 2c 73 cf ed 46
dc 7e 44 68 bb 37 69 54 6e 9e f6 f0 c5 c6 c1 d9
cb f6 87 78 70 8b 73 93 2f f3 55 d2 d9 13 67 32
70 e6 b5 f3 10 4a f5 c3 96 99 c2 92 d0 0f 05 60
1c 44 41 62 7f ab d6 15 52 06 5b 14 a7 d8 19 a1
90 c6 c1 11 f8 0d 30 fd f5 fc 00 bb a4 ef c9 2d
3f 7d 4a eb d2 dc 42 0c 48 b2 5e eb 37 3c 6c a0
e4 0a 27 f0 88 c4 e1 8c 33 17 33 61 38 84 a0 bb
d0 85 aa 45 40 cb 37 14 bf 7a 76 27 4a af f4 1b
ad f0 75 59 3e ac df cd fc 48 46 97 7e 06 6f 2d
e7 f5 60 1d b1 99 f8 5b 4f d3 97 14 4d c5 5e f8
76 50 f0 5f 37 e7 df 13 b8 a2 6b 24 1f ff 65 d1
fb c8 f8 37 86 d6 df 40 e2 3e d3 90 2c 65 2b 1f
5c b9 5f fa e9 35 93 65 59 6d be 8c 62 31 a9 9b
60 5a 0e e5 4f 2d e6 5f 2e 71 f3 7e 92 8f fe 8b
The closest validation of my theory i can find it from RFC 4253:
The "ssh-rsa" key format has the following specific encoding:
string "ssh-rsa"
mpint e
mpint n
Here the 'e' and 'n' parameters form the signature key blob.
But it doesn't explain the length prefixes.
Taking the random RSA PUBLIC KEY i found (in the question), and decoding the base64 into hex:
30 82 01 0a 02 82 01 01 00 fb 11 99 ff 07 33 f6 e8 05 a4 fd 3b 36 ca 68
e9 4d 7b 97 46 21 16 21 69 c7 15 38 a5 39 37 2e 27 f3 f5 1d f3 b0 8b 2e
11 1c 2d 6b bf 9f 58 87 f1 3a 8d b4 f1 eb 6d fe 38 6c 92 25 68 75 21 2d
dd 00 46 87 85 c1 8a 9c 96 a2 92 b0 67 dd c7 1d a0 d5 64 00 0b 8b fd 80
fb 14 c1 b5 67 44 a3 b5 c6 52 e8 ca 0e f0 b6 fd a6 4a ba 47 e3 a4 e8 94
23 c0 21 2c 07 e3 9a 57 03 fd 46 75 40 f8 74 98 7b 20 95 13 42 9a 90 b0
9b 04 97 03 d5 4d 9a 1c fe 3e 20 7e 0e 69 78 59 69 ca 5b f5 47 a3 6b a3
4d 7c 6a ef e7 9f 31 4e 07 d9 f9 f2 dd 27 b7 29 83 ac 14 f1 46 67 54 cd
41 26 25 16 e4 a1 5a b1 cf b6 22 e6 51 d3 e8 3f a0 95 da 63 0b d6 d9 3e
97 b0 c8 22 a5 eb 42 12 d4 28 30 02 78 ce 6b a0 cc 74 90 b8 54 58 1f 0f
fb 4b a3 d4 23 65 34 de 09 45 99 42 ef 11 5f aa 23 1b 15 15 3d 67 83 7a
63 02 03 01 00 01
From RFC3447 - Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1:
A.1.1 RSA public key syntax
An RSA public key should be represented with the ASN.1 type RSAPublicKey:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
The fields of type RSAPublicKey have the following meanings:
modulus is the RSA modulus n.
publicExponent is the RSA public exponent e.
Using Microsoft's excellent (and the only real) ASN.1 documentation:
30 82 01 0a ;SEQUENCE (0x010A bytes: 266 bytes)
| 02 82 01 01 ;INTEGER (0x0101 bytes: 257 bytes)
| | 00 ;leading zero because high-bit, but number is positive
| | fb 11 99 ff 07 33 f6 e8 05 a4 fd 3b 36 ca 68
| | e9 4d 7b 97 46 21 16 21 69 c7 15 38 a5 39 37 2e 27 f3 f5 1d f3 b0 8b 2e
| | 11 1c 2d 6b bf 9f 58 87 f1 3a 8d b4 f1 eb 6d fe 38 6c 92 25 68 75 21 2d
| | dd 00 46 87 85 c1 8a 9c 96 a2 92 b0 67 dd c7 1d a0 d5 64 00 0b 8b fd 80
| | fb 14 c1 b5 67 44 a3 b5 c6 52 e8 ca 0e f0 b6 fd a6 4a ba 47 e3 a4 e8 94
| | 23 c0 21 2c 07 e3 9a 57 03 fd 46 75 40 f8 74 98 7b 20 95 13 42 9a 90 b0
| | 9b 04 97 03 d5 4d 9a 1c fe 3e 20 7e 0e 69 78 59 69 ca 5b f5 47 a3 6b a3
| | 4d 7c 6a ef e7 9f 31 4e 07 d9 f9 f2 dd 27 b7 29 83 ac 14 f1 46 67 54 cd
| | 41 26 25 16 e4 a1 5a b1 cf b6 22 e6 51 d3 e8 3f a0 95 da 63 0b d6 d9 3e
| | 97 b0 c8 22 a5 eb 42 12 d4 28 30 02 78 ce 6b a0 cc 74 90 b8 54 58 1f 0f
| | fb 4b a3 d4 23 65 34 de 09 45 99 42 ef 11 5f aa 23 1b 15 15 3d 67 83 7a
| | 63
| 02 03 ;INTEGER (3 bytes)
| 01 00 01
giving the public key modulus and exponent:
modulus = 0xfb1199ff0733f6e805a4fd3b36ca68...837a63
exponent = 65,537
Update: My expanded form of this answer in another question
Reference Decoder of CRL,CRT,CSR,NEW CSR,PRIVATE KEY, PUBLIC KEY,RSA,RSA Public Key Parser
RSA Public Key
-----BEGIN RSA PUBLIC KEY-----
-----END RSA PUBLIC KEY-----
Encrypted Private Key
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
-----END RSA PRIVATE KEY-----
CRL
-----BEGIN X509 CRL-----
-----END X509 CRL-----
CRT
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
CSR
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
NEW CSR
-----BEGIN NEW CERTIFICATE REQUEST-----
-----END NEW CERTIFICATE REQUEST-----
PEM
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
PKCS7
-----BEGIN PKCS7-----
-----END PKCS7-----
PRIVATE KEY
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
DSA KEY
-----BEGIN DSA PRIVATE KEY-----
-----END DSA PRIVATE KEY-----
Elliptic Curve
-----BEGIN EC PRIVATE KEY-----
-----END EC PRIVATE KEY-----
PGP Private Key
-----BEGIN PGP PRIVATE KEY BLOCK-----
-----END PGP PRIVATE KEY BLOCK-----
PGP Public Key
-----BEGIN PGP PUBLIC KEY BLOCK-----
-----END PGP PUBLIC KEY BLOCK-----