The query format is described using Binary Data Serialization and the TL Language. All large numbers are transmitted as strings containing the required sequence of bytes in big endian order. Hash functions, such as SHA1, return strings (of 20 bytes) which can also be interpreted as big endian numbers. Small numbers (int, long, int128, int256) are normally little endian; however, if they are part of SHA1, the bytes are not rearranged. This way, if long x is the 64 lower-order bits of SHA1 of string s, then the final 8 bytes of 20-byte string SHA1(s) are taken and interpreted as a 64-bit integer.
Prior to sending off unencrypted messages (required in this instance to generate an authorization key), the client must undergo (p,q) authorization as follows.
-1) Client sends query to server
-req_pq_multi#be7e8ef1 nonce:int128 = ResPQ;Client sends query to server
+req_pq_multi#be7e8ef1 nonce:int128 = ResPQ;
+The value of nonce is selected randomly by the client (random number) and identifies the client within this communication. Following this step, it is known to all.
-2) Server sends response of the form
-resPQ#05162463 nonce:int128 server_nonce:int128 pq:string server_public_key_fingerprints:Vector long = ResPQ;Server sends response of the form
+resPQ#05162463 nonce:int128 server_nonce:int128 pq:string server_public_key_fingerprints:Vector long = ResPQ;
+Here, string pq is a representation of a natural number (in binary big endian format). This number is the product of two different odd prime numbers. Normally, pq is less than or equal to 2^63-1. The value of server_nonce is selected randomly by the server; following this step, it is known to all.
server_public_key_fingerprints is a list of public RSA key fingerprints (64 lower-order bits of SHA1 (server_public_key); the public key is represented as a bare type rsa_public_key n:string e:string = RSAPublicKey, where, as usual, n and e are numbers in big endian format serialized as strings of bytes, following which SHA1 is computed) received by the server.
All subsequent messages contain the pair (nonce, server_nonce) both in the plain-text, and the encrypted portions which makes it possible to identify a “temporary session” — one run of the key generation protocol described on this page that uses the same (nonce, server_nonce) pair. An intruder could not create a parallel session with the server with the same parameters and reuse parts of server- or client-encrypted messages for its own purposes in such a parallel session, because a different server_nonce would be selected by the server for any new “temporary session”.
-3) Client decomposes pq into prime factors such that p < q.
+This starts a round of Diffie-Hellman key exchanges.
-4) Client sends query to server
-req_DH_params#d712e4be nonce:int128 server_nonce:int128 p:string q:string public_key_fingerprint:long encrypted_data:string = Server_DH_ParamsClient sends query to server
+req_DH_params#d712e4be nonce:int128 server_nonce:int128 p:string q:string public_key_fingerprint:long encrypted_data:string = Server_DH_Params
+Here, encrypted_data is obtained as follows:
data := a serialization of
+new_nonce := another (good) random number generated by the client; after this query, it is known to both client and server;
+data := a serialization of
p_q_inner_data_dc#a9f55f95 pq:string p:string q:string nonce:int128 server_nonce:int128 new_nonce:int256 dc:int = P_Q_inner_data;or of
p_q_inner_data_temp_dc#56fddf88 pq:string p:string q:string nonce:int128 server_nonce:int128 new_nonce:int256 dc:int expires_in:int = P_Q_inner_data;encrypted_data := RSA_PAD (data, server_public_key), where RSA_PAD is a version of RSA with a variant of OAEP+ padding explained below in 4.1).
+encrypted_data := RSA_PAD (data, server_public_key), where RSA_PAD is a version of RSA with a variant of OAEP+ padding explained below in 4.1).
Someone might intercept the query and replace it with their own, independently decomposing pq into factors instead of the client. The only field that it makes sense to modify is new_nonce which would be the one an intruder would have to re-generate (because an intruder cannot decrypt the encrypted data sent by the client). Since all subsequent messages are encrypted using new_nonce or contain new_nonce_hash, they will not be processed by the client (an intruder would not be able to make it look as though they had been generated by the server because they would not contain new_nonce). Therefore, this intercept will only result in the intruder's completing the authorization key generation protocol in place of the client and creating a new key (that has nothing to do with the client); however, the same effect could be achieved simply by creating a new key in one's own name.
+Someone might intercept the query and replace it with their own, independently decomposing pq into factors instead of the client. The only field that it makes sense to modify is new_nonce which would be the one an intruder would have to re-generate (because an intruder cannot decrypt the encrypted data sent by the client). Since all subsequent messages are encrypted using new_nonce or contain new_nonce_hash, they will not be processed by the client (an intruder would not be able to make it look as though they had been generated by the server because they would not contain new_nonce). Therefore, this intercept will only result in the intruder's completing the authorization key generation protocol in place of the client and creating a new key (that has nothing to do with the client); however, the same effect could be achieved simply by creating a new key in one's own name.
An alternative form of inner data (p_q_inner_data_temp_dc) is used to create temporary keys, that are only stored in the server RAM and are discarded after at most expires_in seconds. The server is free to discard its copy earlier. In all other respects the temporary key generation protocol is the same. After a temporary key is created, the client usually binds it to its principal authorisation key by means of the auth.bindTempAuthKey method, and uses it for all client-server communication until it expires; then a new temporary key is generated. Thus Perfect Forward Secrecy (PFS) in client-server communication is achieved. Read more about PFS »
4.1) RSA_PAD(data, server_public_key) mentioned above is implemented as follows:
5) Server responds with:
-server_DH_params_ok#d0e8075c nonce:int128 server_nonce:int128 encrypted_answer:string = Server_DH_Params;Server responds with:
+server_DH_params_ok#d0e8075c nonce:int128 server_nonce:int128 encrypted_answer:string = Server_DH_Params;
+If the query is incorrect, the server returns a
-404error and the handshake must be restarted (any subsequent request also returns-404, even if it is correct).
Here, encrypted_answer is obtained as follows:
answer := serialization
+new_nonce_hash := 128 lower-order bits of SHA1 (new_nonce);
+answer := serialization
server_DH_inner_data#b5890dba nonce:int128 server_nonce:int128 g:int dh_prime:string g_a:string server_time:int = Server_DH_inner_data;answer_with_hash := SHA1(answer) + answer + (0-15 random bytes); such that the length be divisible by 16;
+answer_with_hash := SHA1(answer) + answer + (0-15 random bytes); such that the length be divisible by 16;
+tmp_aes_key := SHA1(new_nonce + server_nonce) + substr (SHA1(server_nonce + new_nonce), 0, 12);
+tmp_aes_iv := substr (SHA1(server_nonce + new_nonce), 12, 8) + SHA1(new_nonce + new_nonce) + substr (new_nonce, 0, 4);
+encrypted_answer := AES256_ige_encrypt (answer_with_hash, tmp_aes_key, tmp_aes_iv); here, tmp_aes_key is a 256-bit key, and tmp_aes_iv is a 256-bit initialization vector. The same as in all the other instances that use AES encryption, the encrypted data is padded with random bytes to a length divisible by 16 immediately prior to encryption.
Following this step, new_nonce is still known to client and server only. The client is certain that it is the server that responded and that the response was generated specifically in response to client query req_DH_params, since the response data are encrypted using new_nonce.
-Client is expected to check whether p = dh_prime is a safe 2048-bit prime (meaning that both p and (p-1)/2 are prime, and that 22047 < p < 22048), and that g generates a cyclic subgroup of prime order (p-1)/2, i.e. is a quadratic residue mod p. Since g is always equal to 2, 3, 4, 5, 6 or 7, this is easily done using quadratic reciprocity law, yielding a simple condition on p mod 4g — namely, p mod 8 = 7 for g = 2; p mod 3 = 2 for g = 3; no extra condition for g = 4; p mod 5 = 1 or 4 for g = 5; p mod 24 = 19 or 23 for g = 6; and p mod 7 = 3, 5 or 6 for g = 7. After g and p have been checked by the client, it makes sense to cache the result, so as not to repeat lengthy computations in future.
-If the verification takes too long time (which is the case for older mobile devices), one might initially run only 15 Miller—Rabin iterations for verifying primeness of p and (p - 1)/2 with error probability not exceeding one billionth, and do more iterations later in the background.
-Another optimization is to embed into the client application code a small table with some known “good” couples (g,p) (or just known safe primes p, since the condition on g is easily verified during execution), checked during code generation phase, so as to avoid doing such verification during runtime altogether. Server changes these values rarely, thus one usually has to put the current value of server's dh_prime into such a table. For example, current value of dh_prime equals (in big-endian byte order)
+Client is expected to check whether p = dh_prime is a safe 2048-bit prime (meaning that both p and (p-1)/2 are prime, and that 2^2047 < p < 2^2048), and that g generates a cyclic subgroup of prime order (p-1)/2, i.e. is a quadratic residue mod p. Since g is always equal to 2, 3, 4, 5, 6 or 7, this is easily done using quadratic reciprocity law, yielding a simple condition on p mod 4g -- namely, p mod 8 = 7 for g = 2; p mod 3 = 2 for g = 3; no extra condition for g = 4; p mod 5 = 1 or 4 for g = 5; p mod 24 = 19 or 23 for g = 6; and p mod 7 = 3, 5 or 6 for g = 7. After g and p have been checked by the client, it makes sense to cache the result, so as not to repeat lengthy computations in future.
+If the verification takes too long time (which is the case for older mobile devices), one might initially run only 15 Miller--Rabin iterations for verifying primeness of p and (p - 1)/2 with error probability not exceeding one billionth, and do more iterations later in the background.
+Another optimization is to embed into the client application code a small table with some known "good" couples (g,p) (or just known safe primes p, since the condition on g is easily verified during execution), checked during code generation phase, so as to avoid doing such verification during runtime altogether. Server changes these values rarely, thus one usually has to put the current value of server's dh_prime into such a table. For example, current value of dh_prime equals (in big-endian byte order)
C7 1C AE B9 C6 B1 C9 04 8E 6C 52 2F 70 F1 3F 73 98 0D 40 23 8E 3E 21 C1 49 34 D0 37 56 3D 93 0F 48 19 8A 0A A7 C1 40 58 22 94 93 D2 25 30 F4 DB FA 33 6F 6E 0A C9 25 13 95 43 AE D4 4C CE 7C 37 20 FD 51 F6 94 58 70 5A C6 8C D4 FE 6B 6B 13 AB DC 97 46 51 29 69 32 84 54 F1 8F AF 8C 59 5F 64 24 77 FE 96 BB 2A 94 1D 5B CD 1D 4A C8 CC 49 88 07 08 FA 9B 37 8E 3C 4F 3A 90 60 BE E6 7C F9 A4 A4 A6 95 81 10 51 90 7E 16 27 53 B5 6B 0F 6B 41 0D BA 74 D8 A8 4B 2A 14 B3 14 4E 0E F1 28 47 54 FD 17 ED 95 0D 59 65 B4 B9 DD 46 58 2D B1 17 8D 16 9C 6B C4 65 B0 D6 FF 9C A3 92 8F EF 5B 9A E4 E4 18 FC 15 E8 3E BE A0 F8 7F A9 FF 5E ED 70 05 0D ED 28 49 F4 7B F9 59 D9 56 85 0C E9 29 85 1F 0D 81 15 F6 35 B1 05 EE 2E 4E 15 D0 4B 24 54 BF 6F 4F AD F0 34 B1 04 03 11 9C D8 E3 B9 2F CC 5B6) Client computes random 2048-bit number b (using a sufficient amount of entropy) and sends the server a message
-set_client_DH_params#f5045f1f nonce:int128 server_nonce:int128 encrypted_data:string = Set_client_DH_params_answer;Client computes random 2048-bit number b (using a sufficient amount of entropy) and sends the server a message
+set_client_DH_params#f5045f1f nonce:int128 server_nonce:int128 encrypted_data:string = Set_client_DH_params_answer;
+Here, encrypted_data is obtained thus:
data := serialization
+g_b := pow(g, b) mod dh_prime;
+data := serialization
client_DH_inner_data#6643b654 nonce:int128 server_nonce:int128 retry_id:long g_b:string = Client_DH_Inner_Datadata_with_hash := SHA1(data) + data + (0-15 random bytes); such that length be divisible by 16;
+data_with_hash := SHA1(data) + data + (0-15 random bytes); such that length be divisible by 16;
+encrypted_data := AES256_ige_encrypt (data_with_hash, tmp_aes_key, tmp_aes_iv);
The retry_id field is equal to zero at the time of the first attempt; otherwise, it is equal to auth_key_aux_hash from the previous failed attempt (see Item 9).
-7) Thereafter, auth_key equals pow(g, {ab}) mod dh_prime; on the server, it is computed as pow(g_b, a) mod dh_prime, and on the client as (g_a)^b mod dh_prime.
8) auth_key_hash is computed := 64 lower-order bits of SHA1 (auth_key). The server checks whether there already is another key with the same auth_key_hash and responds in one of the following ways.
-9) Server responds in one of three ways:
-dh_gen_ok#3bcbf734 nonce:int128 server_nonce:int128 new_nonce_hash1:int128 = Set_client_DH_params_answer;
+
+-
+
Thereafter, auth_key equals pow(g, {ab}) mod dh_prime; on the server, it is computed as pow(g_b, a) mod dh_prime, and on the client as (g_a)^b mod dh_prime.
+
+-
+
auth_key_hash is computed := 64 lower-order bits of SHA1 (auth_key). The server checks whether there already is another key with the same auth_key_hash and responds in one of the following ways.
+
+
+DH key exchange complete
+
+-
+
Server responds in one of three ways:
+dh_gen_ok#3bcbf734 nonce:int128 server_nonce:int128 new_nonce_hash1:int128 = Set_client_DH_params_answer;
dh_gen_retry#46dc1fb9 nonce:int128 server_nonce:int128 new_nonce_hash2:int128 = Set_client_DH_params_answer;
-dh_gen_fail#a69dae02 nonce:int128 server_nonce:int128 new_nonce_hash3:int128 = Set_client_DH_params_answer;
In the other case, the client goes to Item 6) generating a new b.
In the first case, the client and the server have negotiated auth_key, following which they forget all other temporary data, and the client creates another encrypted session using auth_key. At the same time, server_salt is initially set to substr(new_nonce, 0, 8) XOR substr(server_nonce, 0, 8). If required, the client stores the difference between server_time received in 5) and its local time, to be able always to have a good approximation of server time which is required to generate correct message identifiers.
In the other case, the client goes to Item 6) generating a new b.
+In the first case, the client and the server have negotiated auth_key, following which they forget all other temporary data, and the client creates another encrypted session using auth_key. At the same time, server_salt is initially set to substr(new_nonce, 0, 8) XOR substr(server_nonce, 0, 8). If required, the client stores the difference between server_time received in 5) and its local time, to be able always to have a good approximation of server time which is required to generate correct message identifiers.
IMPORTANT: Apart from the conditions on the Diffie-Hellman prime dh_prime and generator g, both sides are to check that g, g_a and g_b are greater than 1 and less than dh_prime - 1. We recommend checking that g_a and g_b are between 2^{2048-64} and dh_prime - 2^{2048-64} as well.
-If the client fails to receive any response to its query from the server within a certain time interval, it may simply re-send the query. If the server has already sent a response to this query (exactly the same request and not just similar: all the parameters during the repeat request must take on the same values) but it did not get to the client, the server will simply re-send the same response. The server remembers the response for up to 10 minutes after having received the query in 1). If the server has already forgotten the response or the requisite temporary data, the client will have to start from the beginning.
-The server may consider that if the client has already sent in the next query using the data from the previous server response to the specific client, the response is known to have been received by the client and may be forgotten by the server.
-An example of a complete list of queries required to generate an authorization key is shown on a separate page.
-The server may consider that if the client has already sent in the next query using the data from the previous server response to the specific client, the response is known to have been received by the client and may be forgotten by the server.
diff --git a/data/web/corefork.telegram.org/mtproto/samples-auth_key.html b/data/web/corefork.telegram.org/mtproto/samples-auth_key.html index 09c928b793..7458dfb7c2 100644 --- a/data/web/corefork.telegram.org/mtproto/samples-auth_key.html +++ b/data/web/corefork.telegram.org/mtproto/samples-auth_key.html @@ -47,7 +47,7 @@In the examples below, the transport headers are omitted:
-For example, for an abridged version of the transport the client sends
+0xefas the first byte (important: only prior to the very first data packet), then packet length is encoded by a single byte (0x01-0x7e= data length divided by 4; or0x7ffollowed by 3 bytes (little endian) divided by 4) followed by the data themselves. In this case, server responses have the same form (although the server does not send0xefas the first byte).For example, for the abridged version of the transport », the client sends
0xefas the first byte (important: only prior to the very first data packet), then the packet length is encoded with a single byte (0x01-0x7e= data length divided by 4; or0x7ffollowed by 3 bytes (little endian) divided by 4) followed by the data itself. In this case, server responses have the same structure (although the server does not send0xefas the first byte).
Detailed documentation on creating authorization keys is available here ».
0000000000000000051e57ac42770964aaf12fb209c1112642014000000 (20 in decimal)be7e8ef1f18e7ebe3E0549828CCA27E966B301A48FECE2FCC10F3EA71170B031C2EC7365EAFA6D0EThe header is 20 bytes long, the message body is 20 bytes long, and the entire message is 40 bytes in length.
-0000 | 00 00 00 00 00 00 00 00 4A 96 70 27 C4 7A E5 51
-0010 | 14 00 00 00 f1 8e 7e be 3E 05 49 82 8C CA 27 E9
-0020 | 66 B3 01 A4 8F EC E2 FC0000 | 00 00 00 00 00 00 00 00 00 00 00 00 9c 11 12 64
+0010 | 14 00 00 00 f1 8e 7e be C1 0F 3E A7 11 70 B0 31
+0020 | C2 EC 73 65 EA FA 6D 0E0000 | 00 00 00 00 00 00 00 00 01 C8 83 1E C9 7A E5 51
-0010 | 40 00 00 00 63 24 16 05 3E 05 49 82 8C CA 27 E9
-0020 | 66 B3 01 A4 8F EC E2 FC A5 CF 4D 33 F4 A1 1E A8
-0030 | 77 BA 4A A5 73 90 73 30 08 17 ED 48 94 1A 08 F9
-0040 | 81 00 00 00 15 C4 B5 1C 01 00 00 00 21 6B E8 6C
-0050 | 02 2B B4 C30000 | 00 00 00 00 00 00 00 00 01 ac 7d 9a 76 13 12 64
+0010 | 50 00 00 00 63 24 16 05 C1 0F 3E A7 11 70 B0 31
+0020 | C2 EC 73 65 EA FA 6D 0E bc 9a 0b 35 61 1c a3 78
+0030 | 0c 78 c0 17 d2 9d e0 04 08 2a d4 7f de 84 c2 34
+0040 | 9b 00 00 00 15 c4 b5 1c 03 00 00 00 a5 b7 f7 09
+0050 | 35 5f c3 0b 21 6b e8 6c 02 2b b4 c3 85 fd 64 de
+0060 | 85 1d 9d d0resPQ#05162463 nonce:int128 server_nonce:int128 pq:string server_public_key_fingerprints:Vector long = ResPQ | Parameter | Offset, Length in bytes | -Value | +Value (hex) | Description | |
|---|---|---|---|---|---|
| auth_key_id | 0, 8 | -0 |
+0000000000000000 |
Since message is in plain text | |
| message_id | 8, 8 | -51E57AC91E83C801 |
+01ac7d9a76131264 |
Server message ID | |
| message_length | 16, 4 | -64 |
+50000000 (80 in decimal) |
Message body length | |
| %(resPQ) | 20, 4 | -05162463 |
+63241605 |
resPQ constructor number from TL schema | |
| nonce | 24, 16 | -3E0549828CCA27E966B301A48FECE2FC |
+C10F3EA71170B031C2EC7365EAFA6D0E |
Value generated by client in Step 1 | |
| server_nonce | 40, 16 | -A5CF4D33F4A11EA877BA4AA573907330 |
+bc9a0b35611ca3780c78c017d29de004 |
Server-generated random number | |
| pq | 56, 12 | -17ED48941A08F981 |
+082ad47fde84c2340b000000 |
Single-byte prefix denoting length, an 8-byte string, and three bytes of padding | |
| %(Vector long) | 68, 4 | -1cb5c415 |
+15c4b51c |
Vector long constructor number from TL schema | |
| count | 72, 4 | -1 |
+03000000 |
Number of elements in key fingerprint list | |
| fingerprints[] | +fingerprints[0] | 76, 8 | -c3b42b026ce86b21 |
+a5b7f709355fc30b |
+64 lower-order bits of SHA1 (server_public_key) | +
| fingerprints[1] | +76, 8 | +216be86c022bb4c3 |
+64 lower-order bits of SHA1 (server_public_key) | +||
| fingerprints[2] | +76, 8 | +85fd64de851d9dd0 |
64 lower-order bits of SHA1 (server_public_key) |
The server_public_key public key has been selected whose fingerprint corresponds to the only one received from the server: c3b42b026ce86b21.
p = 494C553B
-q = 53911073In our case, the client only has the following public keys, with the following fingerprints:
+03268d20df9858b285fd64de851d9dd0Let's choose the only matching key, the one with fingerprint equal to 85fd64de851d9dd0.
p = 1743948187 (bigendian hex 67f2899b)
+q = 1769681153 (bigendian hex 697b3101)p_q_inner_data#83c95aec pq:string p:string q:string nonce:int128 server_nonce:int128 new_nonce:int256 = P_Q_inner_datap_q_inner_data_dc#a9f55f95 pq:bytes p:bytes q:bytes nonce:int128 server_nonce:int128 new_nonce:int256 dc:int = P_Q_inner_data;| %(p_q_inner_data) | 0, 4 | -83c95aec |
-p_q_inner_data constructor number from TL schema | +955ff5a9 |
+p_q_inner_data_dc constructor number from TL schema |
| pq | 4, 12 | -17ED48941A08F981 |
+082ad47fde84c2340b000000 |
Single-byte prefix denoting length, 8-byte string, and three bytes of padding | |
| p | 16, 8 | -494C553B |
+0467f2899b000000 |
First prime cofactor: single-byte prefix denoting length, 4-byte string, and three bytes of padding | |
| q | 24, 8 | -53911073 |
+04697b3101000000 |
Second prime cofactor: single-byte prefix denoting length, 4-byte string, and three bytes of padding | |
| nonce | 32, 16 | -3E0549828CCA27E966B301A48FECE2FC |
+C10F3EA71170B031C2EC7365EAFA6D0E |
Value generated by client in Step 1 | |
| server_nonce | 48, 16 | -A5CF4D33F4A11EA877BA4AA573907330 |
+bc9a0b35611ca3780c78c017d29de004 |
Value received from server in Step 2 | |
| new_nonce | 64, 32 | -311C85DB234AA2640AFC4A76A735CF5B 1F0FD68BD17FA181E1229AD867CC024D |
+311C85DB234AA2640AFC4A76A735CF5B1F0FD68BD17FA181E1229AD867CC024D |
Client-generated random number | |
| dc | +96, 4 | +02000000 |
+DC ID: 10000 (decimal) has to be added to the DC ID to connect to the test servers; it has to be made negative if the DC we're connecting to is a media (not CDN) DC. |
+
The serialization of P_Q_inner_data produces some string data. This is followed by encrypted_data:
SHA1 (data) = DB761C27718A2305044F71F2AD951629D78B2449
RSA (data_with_hash, server_public_key) = 7BB0100A523161904D9C69FA04BC60DECFC5DD74B99995C768EB60D8716E2109BAF2D4601DAB6B09610DC11067BB89021E09471FCFA52DBD0F23204AD8CA8B012BF40A112F44695AB6C266955386114EF5211E6372227ADBD34995D3E0E5FF02EC63A43F9926878962F7C570E6A6E78BF8366AF917A5272675C46064BE62E3E202EFA8B1ADFB1C32A898C2987BE27B5F31D57C9BB963ABCB734B16F652CEDB4293CBB7C878A3A3FFAC9DBEA9DF7C67BC9E9508E111C78FC46E057F5C65ADE381D91FEE430A6B576A99BDF8551FDB1BE2B57069B1A45730618F27427E8A04720B4971EF4A9215983D68F2830C3EAA6E40385562F970D38A05C9F1246DC33438E6The length of the final string was 256 bytes.
+The length of the final string is 256 bytes.
req_DH_params#d712e4be nonce:int128 server_nonce:int128 p:string q:string public_key_fingerprint:long encrypted_data:string = Server_DH_Params| message_id | 8, 8 | -51e57ac917717a27 |
+fa1bc56176131264 |
Exact unixtime * 2^32 |
| message_length | 16, 4 | -320 |
+40010000 (decimal 320) |
Message body length |
| %(req_DH_params) | 20, 4 | -d712e4be |
+bee412d7 |
req_DH_params constructor number from TL schema |
| nonce | 24, 16 | -3E0549828CCA27E966B301A48FECE2FC |
+C10F3EA71170B031C2EC7365EAFA6D0E |
Value generated by client in Step 1 |
| server_nonce | 40, 16 | -A5CF4D33F4A11EA877BA4AA573907330 |
+bc9a0b35611ca3780c78c017d29de004 |
Value received from server in Step 2 |
| p | 56, 8 | -494C553B |
+0467f2899b000000 |
First prime cofactor: single-byte prefix denoting length, 4-byte string, and three bytes of padding |
| q | 64, 8 | -53911073 |
+04697b3101000000 |
Second prime cofactor: single-byte prefix denoting length, 4-byte string, and three bytes of padding |
| public_key_fingerprint | 72, 8 | -c3b42b026ce86b21 |
+85fd64de851d9dd0 |
Fingerprint of public key used |
0000 | 00 00 00 00 00 00 00 00 27 7A 71 17 C9 7A E5 51
-0010 | 40 01 00 00 BE E4 12 D7 3E 05 49 82 8C CA 27 E9
-0020 | 66 B3 01 A4 8F EC E2 FC A5 CF 4D 33 F4 A1 1E A8
-0030 | 77 BA 4A A5 73 90 73 30 04 49 4C 55 3B 00 00 00
-0040 | 04 53 91 10 73 00 00 00 21 6B E8 6C 02 2B B4 C3
-0050 | FE 00 01 00 7B B0 10 0A 52 31 61 90 4D 9C 69 FA
-0060 | 04 BC 60 DE CF C5 DD 74 B9 99 95 C7 68 EB 60 D8
-0070 | 71 6E 21 09 BA F2 D4 60 1D AB 6B 09 61 0D C1 10
-0080 | 67 BB 89 02 1E 09 47 1F CF A5 2D BD 0F 23 20 4A
-0090 | D8 CA 8B 01 2B F4 0A 11 2F 44 69 5A B6 C2 66 95
-00A0 | 53 86 11 4E F5 21 1E 63 72 22 7A DB D3 49 95 D3
-00B0 | E0 E5 FF 02 EC 63 A4 3F 99 26 87 89 62 F7 C5 70
-00C0 | E6 A6 E7 8B F8 36 6A F9 17 A5 27 26 75 C4 60 64
-00D0 | BE 62 E3 E2 02 EF A8 B1 AD FB 1C 32 A8 98 C2 98
-00E0 | 7B E2 7B 5F 31 D5 7C 9B B9 63 AB CB 73 4B 16 F6
-00F0 | 52 CE DB 42 93 CB B7 C8 78 A3 A3 FF AC 9D BE A9
-0100 | DF 7C 67 BC 9E 95 08 E1 11 C7 8F C4 6E 05 7F 5C
-0110 | 65 AD E3 81 D9 1F EE 43 0A 6B 57 6A 99 BD F8 55
-0120 | 1F DB 1B E2 B5 70 69 B1 A4 57 30 61 8F 27 42 7E
-0130 | 8A 04 72 0B 49 71 EF 4A 92 15 98 3D 68 F2 83 0C
-0140 | 3E AA 6E 40 38 55 62 F9 70 D3 8A 05 C9 F1 24 6D
-0150 | C3 34 38 E60000 | 00 00 00 00 00 00 00 00 fa 1b c5 61 76 13 12 64
+0010 | 40 01 00 00 BE E4 12 D7 C1 0F 3E A7 11 70 B0 31
+0020 | C2 EC 73 65 EA FA 6D 0E bc 9a 0b 35 61 1c a3 78
+0030 | 0c 78 c0 17 d2 9d e0 040000 | 00 00 00 00 00 00 00 00 01 54 43 36 CB 7A E5 51
0010 | 78 02 00 00 5C 07 E8 D0 3E 05 49 82 8C CA 27 E9