This page sets out the common rules of the Naptify Client Protocol (NCP), the extension that Naptify adds to the OpenNap protocol between clients and servers, together with the number allocation for all of the Naptify extensions. Its purpose is to let authors of other clients and servers support the extensions while remaining compatible with Naptify. The detailed format of each feature, such as the order of the fields in each message, is outside the scope of this page.

1. Basic Principles

• The extensions conform to the original OpenNap protocol specification [NAP]. The frame format (a header of a 2-byte length and a 2-byte type, both little-endian, followed by the payload) and the string format are as in [NAP] §2.
• The meaning of existing messages is not changed.
• The default behavior remains that of [NAP]. A feature of the extension is used only on a connection where the capability exchange (§3) has confirmed that both sides support it.
• No extension message is sent to a legacy client or server (one that does not implement this extension). The only exception is the capability offer (9200) that a client sends first.
• A feature of the extension MUST NOT be enabled on the basis of a self-reported identity, such as a client name or a server version string. Such identities can be forged, so they are not used to decide privileges or features.
• Using the extension does not exempt anyone from the server’s rules (such as limits on the number of transfer requests and the handling of Leeches).
• No custom cryptography is used. Encrypted connections use standard TLS.

2. Number Allocation

The Naptify extensions use the numbers 9000–9499. NCP uses 9200–9389, divided into blocks of 10 numbers per feature. To keep other clients and servers compatible, every number in use is listed in this section. In the direction column, C stands for the client and S for the server.

2.1 Ranges

Range	Use
9000–9199	Naptify Guild Protocol (server-to-server connections)
9200–9209	Capability exchange (including peer capability notification, client certificate fingerprints, and server setting queries)
9210–9219	Switching to an encrypted connection (TLS)
9220–9229	Authentication (challenge-response)
9230–9239	Connection compression
9240–9249	Bulk share registration and completion notice
9250–9259	Bulk sending of search and browse lists
9260–9269	Carrying shares over a reconnection
9270–9279	Extensions to transfer relaying
9280–9289	Structured notifications
9290–9299	UTF-8 character encoding; same-name users in a Guild
9300–9309	Structured administrative requests
9310–9319	Reserved
9320–9329	IM synchronization across multiple logins
9330–9389	NAP Global Mesh Backup (9380–9389 are spare)
9390–9399	For testing by NCP implementers
9400–9489	Naptify Peer Protocol (client-to-client connections)
9490–9499	For testing by Naptify Peer Protocol implementers

The individual numbers in 9000–9199 are listed in the Naptify Guild Protocol specification (see References).

2.2 Status Values

Status	Meaning
In use	The use and the procedure are defined
In design	Only the use and the number are defined; the messages are not yet defined
Deferred	Only the use and the number are defined; the design has been put off
Reserved	Not used, and not reused for any other purpose
Not a message	Used only as a feature number, never as a message type

• Messages with numbers that are in design, deferred, or reserved MUST NOT be sent. When one is received, it is handled as an unknown number (§4).
• A number not listed in the tables (a gap within a range) is unallocated and MUST NOT be sent.
• The testing ranges (9390–9399 and 9490–9499) are for implementers’ own tests and are not used between published implementations.

2.3 NCP Feature Numbers

Feature numbers are exchanged inside 9200 and 9201 in the capability exchange (§3).

Feature number	Name	Use	Status
9203	Large payload	Frames with payloads of up to 65535 bytes in both directions (no messages)	In use
9204	Peer capability notification	The server reports which client-to-client features the other party of a transfer or direct browse supports	In use
9205	Client certificate fingerprint	The server passes on certificate fingerprints that clients use to verify each other over client-to-client encrypted connections (agreed only inside an encrypted connection, and only together with 9204)	In use
9207	Server setting query	Queries the values of the rules that apply to the client on that server (§5.6)	In use
9210	Switching to an encrypted connection (TLS)	Switches the connection to an encrypted connection partway through	In use
9220	Authentication (challenge-response)	Logs in without sending the password itself, even on a path without an encrypted connection	In design
9230	Connection compression (zlib)	Sends frames after login compressed with zlib	In use
9231	Connection compression (zstd)	Compression with zstd; servers do not agree to it	Reserved
9240	Bulk share registration and completion notice	Reports the end of a share registration and receives the confirmed count	In use
9250	Bulk sending of search and browse lists	Sends search and browse results in batches	Deferred
9260	Carrying shares over a reconnection	Avoids resending the share list after a short disconnection	Deferred
9270	Relaying transfers when both ports are 0	Makes a transfer possible, with instructions from the server, when neither side can accept incoming connections	In design
9272	IPv6 address	Exchanges IPv6 addresses for client-to-client transfers	In use
9274	Hash search and possession check	Attaches hashes to shared files to find identical content; the server checks possession (agreed only together with 9203)	In use
9278	Grouping of multi-source downloads	Reports transfers of the same file from several parties as one group (will not be built)	Reserved
9280	Structured notifications	Receives as values information that is currently only in message text	In design
9290	UTF-8 character encoding	Uses UTF-8 for the messages on an agreed connection	In use
9295	Same-name users in a Guild	Carries users as a pair of name and originating server	In design
9300	Structured administrative requests	Performs administrative operations such as bans with messages instead of chat commands	In design
9310	Reserved	Not used, because [NAP] 751 and 752 are used for liveness checks	Reserved
9320	IM synchronization across multiple logins	Receives IMs sent from the same user’s other devices as IMs the user sent	In use
9330	NAP Global Mesh Backup	Combines users’ Mesh Storage to back up files (agreed only inside an encrypted connection, only together with 9203 and 9274, and only when enabled on the server)	In use
9400	Naptify Peer Protocol support	The client declares that it supports the Peer Protocol; the server reports this to the other party of a transfer with 9204	In use

2.4 NCP Message Numbers (9200–9329)

Number	Name	Direction	Use	Status
9200	Capability offer	C→S	Offers the feature numbers the client wants to use	In use
9201	Capability response	S→C	Returns the offered feature numbers that the server also supports	In use
9202	Capability exchange error	S→C	Reports that there is no common protocol version	In use
9203	Large payload	—	Feature number only; never sent as a message type	Not a message
9204	Peer capabilities	S→C	Reports the client-to-client features agreed by the other party of a transfer or direct browse	In use
9205	Certificate fingerprint registration	C→S	Registers or withdraws the client’s own certificate fingerprint	In use
9206	Peer fingerprint	S→C	Passes on the certificate fingerprint of the other party of a transfer	In use
9207	Setting query	C→S	Queries rule values	In use
9208	Settings	S→C	Returns item names and values	In use
9209	End of settings	S→C	Marks the end of the answer	In use
9210	Switch request	C→S	Requests a switch to an encrypted connection	In use
9211	Switch acceptance	S→C	Accepts the switch; the TLS handshake follows	In use
9212	Switch refusal	S→C	Reports that an encrypted connection cannot be used now	In use
9230	zlib compressed frames	Both	Carries several frames together, compressed with zlib	In use
9231	zstd compressed frames	—	Not used	Reserved
9240	End of registration	C→S	Reports that a set of share changes has been sent	In use
9241	Registration complete	S→C	Returns the confirmed number and size of shares	In use
9242	Registration completion error	S→C	Reports that the share and search functions are currently unavailable	In use
9272	IPv6 address registration	C→S	Registers, withdraws, or verifies an IPv6 address	In use
9273	IPv6 address notification	S→C	Sends the verification token, the verification result, or the IPv6 address of the other party of a transfer	In use
9274	Hash registration and search	C→S	Attaches hashes to shared files, or searches by hash	In use
9275	Hash notification	S→C	Sends a registration refusal, the hash of a search result line, hash search results, or a notice that a hash was removed	In use
9276	Possession check request	S→C	Checks whether the client has a file it attached a hash to	In use
9277	Possession check response	C→S	Returns part of the file and the hashes to check it against, or reports that the file is not held	In use
9278	Multi-source download group notice	C→S	Will not be built	Reserved
9279	Multi-source download group error	S→C	Will not be built	Reserved
9310–9319	Reserved	—	Not used	Reserved
9320	Copy of a sent IM	S→C	Reports an IM sent from the same user’s other device	In use

The message numbers 9220–9229, 9250–9269, 9270–9271, and 9280–9309 are held for features that are in design or deferred. The individual numbers are not yet defined.

2.5 NAP Global Mesh Backup Numbers (9330–9389)

Number	Name	Direction	Use	Status
9330	Participation registration	C→S	Registers the PC and its Mesh Storage Size to participate	In use
9331	Status	S→C	Reports usage, the Contribution Score, the Backup Allowance, and so on	In use
9332	Status query	C→S	Queries the status of storage units	In use
9333	Storage unit status	S→C	Returns the status of a storage unit’s Seeds and their Keepers	In use
9334	Shared file registration	C→S	Registers a shared file as a backup target	In use
9335	Holders	S→C	Returns the number of Holders of the same content and their availability	In use
9336	Owner proof request	S→C	Requests a signature with the passkey’s key	In use
9337	Owner proof	C→S	Returns the signature to show ownership	In use
9338	Reserved	—	A withdrawn number; not reused	Reserved
9339	Error	S→C	Returns an error for a NAP Global Mesh Backup message	In use
9340	Placement request	C→S	Requests Keepers for Seeds	In use
9341	Placement candidates	S→C	Returns candidate Keepers and permits	In use
9342	Acceptance instruction	S→C	Instructs a Keeper to accept a Seed	In use
9343	Placement offer	C→S	The owner offers the Seed to place under a permit	In use
9344	Receipt report	C→S	The Keeper reports that it has received a Seed	In use
9345	Placement confirmation	S→C	Reports the result of a placement to the owner	In use
9346	Storage unit confirmation	C→S	Confirms the placement of a storage unit’s Seeds	In use
9347	Storage unit deletion	C→S	Deletes a storage unit	In use
9348	Seed withdrawal	C→S	Withdraws one Seed	In use
9349	Seed upload	C→S	Sends a Seed to the Server Mesh Storage	In use
9350	Check request	S→C	Checks whether a Keeper has a Seed	In use
9351	Check response	C→S	Returns part of the Seed and the hashes to check it against, or reports that the Seed is not held	In use
9352	Inventory list	S→C	Sends the list of Seeds the Keeper should have	In use
9353	Local Seed list	C→S	Sends the list of Seeds the Keeper actually has	In use
9354–9359	Reserved	—	Not used	Reserved
9360	Restore request	C→S	Requests the restoration of a storage unit	In use
9361	Restore permit	S→C	Returns the parties holding Seeds and the permits	In use
9362	Provision instruction	S→C	Instructs a party holding a Seed to provide it	In use
9363	Restore completion report	C→S	Reports that a restoration has finished	In use
9364	Server Seed range request	C→S	Requests part of a Seed in the Server Mesh Storage	In use
9365	Server Seed range	S→C	Sends part of a Seed in the Server Mesh Storage	In use
9366–9369	Reserved	—	Not used	Reserved
9370	Backup Ledger save	C→S	Stores the encrypted Backup Ledger on the server	In use
9371	Backup Ledger save result	S→C	Returns the version of the stored Backup Ledger	In use
9372	Backup Ledger request	C→S	Requests the stored Backup Ledger	In use
9373	Backup Ledger	S→C	Returns the stored Backup Ledger	In use
9374	Split Key (Server) save	C→S	Stores the Split Key (Server) on the server	In use
9375	Split Key (Server)	S→C	Returns the stored Split Key (Server)	In use
9376	Previous pair clear	C→S	Sent instead of 9337 after a lost passkey, to request clearing the records of the previous pair of user name and key. The records are cleared after a grace period of 10 days, and the request is cancelled if an owner proof with the previous key succeeds in the meantime	In use
9377	End of participation	C→S	Reports that NAP Global Mesh Backup has been disabled	In use
9378	Clear cancelled	S→C	Reports that a previous pair clear was cancelled, with the time it was requested	In use
9379	Reserved	—	Not used	Reserved
9380–9389	Spare	—	Not used	Reserved

2.6 Naptify Peer Protocol Numbers (9400–9489)

The Naptify Peer Protocol is the extension that clients use with each other on the data port. The server reports that the other party supports it with 9204 (NCP feature number 9400). Feature numbers within the Peer Protocol are exchanged inside 9400 and 9401. In addition, the Peer Protocol uses the NCP feature number 9290 (UTF-8 character encoding; no messages) for names and file names. Only a connection where 9290 has been agreed uses UTF-8 for names and file names; any other connection uses CP932 (§5.2).

Number	Name	Direction	Use	Status
9400	Capability offer	Client to client	The connecting side offers the feature numbers it wants to use	In use
9401	Capability response	Client to client	Returns the offered feature numbers that the accepting side also supports	In use
9402	Capability exchange error	Client to client	Reports that there is no common protocol version	In use
9410	Switch request	Client to client	Requests a switch to an encrypted connection (TLS) (feature number)	In use
9411	Switch acceptance	Client to client	Accepts the switch	In use
9420	Range request	Client to client	Requests a given range of a file (feature number)	In use
9421	Range response	Client to client	Returns the requested range; the file content follows	In use
9422	Range refusal	Client to client	Refuses a range request	In use
9423	Push offer	Client to client	Identifies the file to send when the sending side connects	In use
9424	End of receipt	Client to client	Reports that receiving has finished	In use
9430	Compression	—	Sends file content compressed with zstd (feature number; no messages)	In use
9440	Hash tree request	Client to client	Requests the hash tree for verifying received content (feature number)	In use
9441	Hash tree response	Client to client	Returns the hash tree	In use
9442	No hash tree	Client to client	Reports that the hash tree cannot be returned	In use
9450	Multiple connections to the same party	—	Opens several connections to the same party and receives different ranges in parallel (feature number; no messages)	In use
9460	Received range request	Client to client	For a file still being received, asks which ranges the other party has (feature number)	In use
9461	Received ranges	Client to client	Returns the ranges held	In use
9470	Direct browse list request	Client to client	Requests the share list in compressed form (feature number)	In use
9471	Direct browse list	Client to client	Returns the compressed share list	In use
9480	Permit presentation	Client to client	Presents the permit issued by the server for a NAP Global Mesh Backup Seed transfer (feature number)	In use
9481	Seed range request	Client to client	Requests a given range of a Seed	In use
9482	Seed range response	Client to client	Returns the requested range; the Seed content follows	In use
9483	Seed transfer refusal	Client to client	Refuses a Seed transfer	In use
9484	Seed hash tree request	Client to client	Requests the hash tree for verifying a Seed	In use
9485	Seed hash tree response	Client to client	Returns the hash tree	In use
9486	End of Seed receipt	Client to client	Reports that receiving a Seed has finished or been abandoned	In use
9487–9489	Reserved	—	Not used	Reserved

3. Capability Exchange (9200, 9201)

3.1 Feature Numbers

Each feature of the extension is identified by the number of its first message (its feature number). For example, switching to an encrypted connection (TLS) is 9210, and bulk share registration and completion notice is 9240. Some features have no messages and take effect through agreement alone (9203, the large payload; §5.1). The feature numbers are listed in §2.3.

3.2 Messages

The capability exchange uses 9200 (capability offer), 9201 (capability response), and 9202 (capability exchange error) (§2.4). 9200 and 9201 carry a protocol version (1 for NCP) and a list of feature numbers.

3.3 Offer and Agreement Procedure

1. The client sends 9200 as the first message on the TCP connection, listing the feature numbers it wants to use. The client sends first because a message sent first by the server would reach legacy clients that do not know the extension.
2. The server returns 9201 before any other message. – For the protocol version, the server returns the highest version it supports that is not greater than the offered one. – For the feature numbers, the server returns only those offered that it also supports. Unknown feature numbers are silently dropped. The order has no meaning. A number offered more than once is returned once. – The list of feature numbers may be empty (no feature is used).
3. When there is no common protocol version, the server returns 9202 instead of 9201. The connection continues, and proceeds as in [NAP] with no feature agreed.
4. A server that receives a malformed 9200 disconnects.
5. Only the features included in 9201 are agreed, and they remain valid only for the duration of that connection.
6. When switching to an encrypted connection (TLS, 9210) is agreed, 9200 and 9201 are exchanged again after the switch, as the first messages inside the encrypted connection. Because the response before the encrypted connection can be tampered with, only the agreement in the 9201 inside the encrypted connection is valid, and the earlier agreement is discarded.
7. A 9200 received other than as the first message is ignored by the server (it returns no response and the agreement does not change). The only exception is the repeated exchange inside the encrypted connection in item 6.
8. Some features can be agreed only when offered together with other features, or only inside an encrypted connection. When the conditions are not met, the server does not include the feature in 9201.
9. The redirect port (metaserver) does not accept 9200. Clients MUST NOT send 9200 to it.
10. The client then proceeds to login ([NAP] message 2). The capability exchange is completed before any password is sent.

3.4 Handling Parties That Do Not Agree

Legacy servers

Some legacy servers ignore an unknown number received before login, and others disconnect. The client lets the user choose whether to use the extension from “Automatic”, “Always”, and “Never” (the default is “Automatic”).

• Automatic: The client sends 9200 as the first message and waits for a response for a time set in the client.
• If 9201 arrives, the client remembers the server as supporting the extension and proceeds as in §3.3.
• If no response arrives, the client remembers the server as not supporting the extension and logs in on the same connection without 9200.
• If the server disconnects, the client remembers the server as not supporting the extension, reconnects, and logs in without 9200.
• If a server that has returned 9201 even once does not respond to 9200 or disconnects, the client does not remember it as not supporting the extension, and instead treats this as a connection failure and reconnects (to prevent an attacker from forcing an unencrypted connection by suppressing the response).
• Always: The client always sends 9200. If there is no response or the server disconnects, the client treats this as a connection failure and reconnects.
• Never: The client does not send 9200 and logs in as in [NAP].

When a server to which the client has previously connected over an encrypted connection responds but declines to use an encrypted connection (9201 does not include 9210, or the switch is refused), the client SHOULD warn the user instead of silently continuing unencrypted. For a server the client connected to after the user approved its certificate fingerprint, the client MUST ask for the user’s approval before login. Without approval, the client does not send the login.

Legacy clients

• A legacy client does not send 9200, so the server agrees to no feature on that connection and sends no extension message. The client is handled as in [NAP].
• Messages of features not agreed in 9201 are not sent, even if the other party supports the extension.

4. Receiving Unknown Numbers

• An unknown number received after login MUST be ignored.
• An unknown number received before login MAY cause disconnection.
• However, numbers in the NCP range (9200–9389) MUST be ignored without disconnecting, whether received before or after login, even when unknown. This keeps compatibility with future features.
• A message of a feature that has not been agreed is also ignored as an unknown number.
• On a Naptify Peer Protocol connection, unknown numbers in 9400–9499 MUST be ignored. A number outside that range MAY cause disconnection.

5. Common Rules

5.1 Frame Size

• On a connection where the large payload (feature number 9203) has been agreed, frames with payloads of up to 65535 bytes MAY be sent in both directions, and the receiver MUST accept them.
• On a connection where it has not been agreed, frames with payloads larger than 8192 bytes are not sent (the limit of legacy clients and servers).
• 9203 is not used as a message type.

5.2 Character Encoding

• The default is the same as [NAP]; in Japanese deployments it is CP932.
• UTF-8 is used only on a connection where 9290 has been agreed in the capability exchange. On such a connection, messages are in UTF-8.
• On a connection without that agreement, a character that CP932 cannot represent is sent as “?” in human-readable text. Strings that the peer sends back in a request, such as file names, are not sent.
• Server-to-server links use UTF-8 between Naptify servers and CP932 with FaceNap and SlavaNap.

5.3 Fields and Errors

• Integers are written in decimal ASCII. Names and file names use the same format as [NAP].
• Content that is not text, such as compressed data, is placed in the message payload as is.
• Errors are returned with each feature’s error message. The reason is expressed as a number, and any display text is supplementary only. Receivers do not parse the text mechanically.

5.4 Liveness Checks

• Liveness checks use [NAP] 751 and 752, not extension messages.
• A client that conforms to this extension MUST answer 751 server from the server promptly with 752 server.

5.5 Using Numbers

• Before using a number, check the tables in §2 to make sure it does not overlap with a number allocated to another use.
• Reserved numbers are not used. Numbers that are in design or deferred, and numbers not listed in the tables, are not sent either (§2.2).
• Numbers in the testing ranges are not used outside one’s own tests.

5.6 Server Setting Query (9207–9209)

This mechanism lets a client learn, as values rather than by parsing text, the values of the rules that apply to it on a server (such as chat flood limits and search rate limits). It is treated as part of the rules of the extension.

• It is used only after login, on a connection where 9207 has been agreed in the capability exchange.
• The client queries with 9207, the server returns item names and values with 9208, and ends the answer with 9209. The server does not send these on its own initiative.
• Item names are fixed spellings made up only of lowercase letters, digits, underscores (_), and periods.
• A value is a boolean (0 or 1), a decimal integer, or a lowercase word defined for each item. When a value cannot be returned, one of the following words is returned instead.
• none: The server does not have that function.
• exempt: It does not apply to the querying user.
• unknown: The item name is unknown to the server.
• A value is not the server’s setting as such, but the value that actually applies to the querying connection.
• Clients skip lines with unknown item names. 9209 marks the end of the answer; clients do not judge by the number of items returned (items may be added in revisions).
• To add an item or change its meaning, the specification is revised first. Servers MUST NOT add items of their own.

6. Rules for Adding Extensions

• Each feature of the extension is defined as numbered messages. Requests, responses, ends, and errors are each separate numbered messages (the same pattern as the [NAP] search: 200 → 201 … 202).
• Numbers follow the allocation in §2 and are taken from the feature’s block of 10. Before using a number, check the tables in §2 for overlaps, and do not use reserved numbers (§5.5).
• Each feature is given a feature number and is used only on connections where it has been agreed in the capability exchange.
• The meaning of existing [NAP] messages is not changed.
• Error reasons are expressed as numbers (§5.3).
• No feature is designed to bypass the server’s rules (§1).
• When adding a feature, number, or item, or changing its meaning, the specification is revised first, and then implemented.

Appendix A. Compatibility: UTS1 Encrypted Connection

UTS1 is an encrypted connection scheme defined independently by some OpenNap-compatible clients. It is not part of the NAPTIFY extension protocol, and no numbers are allocated to it (as stated in §1, NAPTIFY uses standard TLS, 9210, for encrypted connections). This appendix is a compatibility description for servers that accept UTS1 clients. naptify-server accepts UTS1 while encrypted connections are enabled in the settings (enabled by default).

A.1 Position

• UTS1 is a preliminary exchange before the [NAP] connection begins. After the handshake, all [NAP] messages, including login (2), flow inside encrypted frames.
• After the handshake, the capability exchange (9200, 9201) takes place as the first message, as on any other connection (§3.3), under the same conditions. Switching to TLS (9210) is not agreed, nor are the features that can be agreed only inside TLS (9205, 9330).
• UTS1 is not used for client-to-client communication.

A.2 Handshake

1. At the start of the connection, the client sends a 53-byte greeting: UTS1 (55 54 53 31), C (43), a 32-byte X25519 public key, and 16 random bytes, in that order.
2. The server treats the connection as UTS1 when its first 4 bytes are UTS1 and the 5th byte is C. If the 5th byte is not C, the bytes are read as an ordinary [NAP] message.
3. The server generates an ephemeral X25519 key and returns a 53-byte greeting: UTS1, A (41), a 32-byte public key, and 16 random bytes, in that order. The client waits 5 seconds.
4. Both sides compute the X25519 shared value. If the shared value is all zeros, the connection is closed.
5. salt = SHA-256(client greeting, 53 bytes ‖ server greeting, 53 bytes). okm = HKDF-SHA256(IKM = shared value, salt, info = utatane-go/server/v1, length 72 bytes).
6. Client to server uses key okm[0:32] and nonce prefix okm[64:68]. Server to client uses key okm[32:64] and nonce prefix okm[68:72].
7. If the handshake fails, the connection is closed. It does not fall back to unencrypted communication.

A.3 Frames

• Format: BE32(L) + AES-256-GCM ciphertext (including the 16-byte authentication tag). L is the plaintext length + 16. The AAD is the 4 length bytes.
• nonce = 4-byte prefix ‖ BE64(sequence number). The sequence number starts at 0 in each direction and increases by 1 per frame.
• Plaintext is at most 32768 bytes per frame. On receipt, a frame with L less than 16, or with L − 16 greater than 32768, is invalid.
• A frame with 0 bytes of plaintext (L = 16) marks the end. The side closing the connection sends the end frame before closing.
• If a frame fails authentication or has a length out of range, nothing further is read and the connection is closed. Invalid frames are not skipped to read later frames.
• Frame contents are a byte stream. [NAP] messages are reassembled across frames.

A.4 Security

• UTS1 protects the contents from a third party who only eavesdrops on the communication.
• It has no procedure to verify the authenticity of the server (such as a certificate, a pre-shared key, or a challenge-response). It therefore cannot prevent an attack in which a party on the network path impersonates the server (a man-in-the-middle attack). The impersonating party can also read the login password.
• Because the client defines the procedure, the server alone cannot add a verification step. Where protection against man-in-the-middle attacks is required, use standard TLS (9210).

A.5 Test Values

Computed with the keys of RFC 7748 §6.1 (server = Alice, client = Bob), client random bytes 00–0f, and server random bytes 10–1f.

okm    5609cbcd01f5882306614d168b2feeb8da2c45c12d29991659b568b00fe4dc6c74f5213bc17a9991853d8c689f325b8ccf050c1420f885fb6f4c8fed1fc7e75d679730b2c6b7e173
C→S seq 0 'hello'   0000001557b0401a0c4bad261d77760dfecc7bc1a3a8685a65
C→S seq 1 end       00000010abbf8d2ae136071c1cdcc4e35397b5bf
S→C seq 0 'world'   0000001534e4cf01fedb5ddc45880171f9b6a11f2cb986021b
S→C seq 1 end       00000010a36f93a38b92eb56ccd7e96289a9c9fb

References

• [NAP] drscholl@users.sourceforge.net (OpenNap project), “napster messages”. Original dated 2000-04-07; change log through 2001-04-07. https://opennap.sourceforge.net/napster.txt
• Naptify Guild Protocol: https://naptify.net/en/docs-en/guild-protocol-en/