From 436c1fac1dc9daed033ca78719031b687b984c29 Mon Sep 17 00:00:00 2001 From: Adam Ierymenko Date: Mon, 21 Dec 2015 16:15:39 -0800 Subject: Selectively move over changes from "edge" to "dev" excluding netcon. --- node/Packet.hpp | 66 +++++++-------------------------------------------------- 1 file changed, 8 insertions(+), 58 deletions(-) (limited to 'node/Packet.hpp') diff --git a/node/Packet.hpp b/node/Packet.hpp index ef0251e3..6c1b2984 100644 --- a/node/Packet.hpp +++ b/node/Packet.hpp @@ -678,7 +678,14 @@ public: * <[...] arbitrary payload to be echoed back> * * This generates OK with a copy of the transmitted payload. No ERROR - * is generated. Response to ECHO requests is optional. + * is generated. Response to ECHO requests is optional and ECHO may be + * ignored if a node detects a possible flood. + * + * There is a de-facto standard for ECHO payload. No payload indicates an + * ECHO used for path confirmation. Otherwise the first byte contains + * flags, in which currently the only flag is 0x01 for a user-requested + * echo. For user-requested echoes the result may be reported back through + * the API. Otherwise the payload is for internal use. * * Support for fragmented echo packets is optional and their use is not * recommended. @@ -844,63 +851,6 @@ public: */ VERB_MULTICAST_FRAME = 14, - /** - * Ephemeral (PFS) key push: (UNFINISHED, NOT IMPLEMENTED YET) - * <[2] flags (unused and reserved, must be 0)> - * <[2] length of padding / extra field section> - * <[...] padding / extra field section> - * <[8] 64-bit PFS key set ID sender holds for recipient (0==none)> - * <[8] 64-bit PFS key set ID of this key set> - * [... begin PFS key record ...] - * <[1] flags> - * <[1] symmetric cipher ID> - * <[1] public key type ID> - * <[2] public key length in bytes> - * <[...] public key> - * [... additional records may follow up to max packet length ...] - * - * This message is sent to negotiate an ephemeral key. If the recipient's - * current key pair for the sender does not match the one the sender - * claims to have on file, it must respond with its own SET_EPHEMERAL_KEY. - * - * PFS key IDs are random and must not be zero, since zero indicates that - * the sender does not have an ephemeral key on file for the recipient. - * - * One or more records may be sent. If multiple records are present, - * the first record with common symmetric cipher, public key type, - * and relevant flags must be used. - * - * The padding section may be filled with an arbitrary amount of random - * or empty payload. This may be used as a countermeasure to prevent PFS - * key pushes from being recognized by packet size vs. other packets in - * the stream. This also provides potential space for additional fields - * that might be indicated in the future by flags. - * - * Flags (all unspecified flags must be zero): - * 0x01 - FIPS mode, only use record if FIPS compliant crypto in use - * - * Symmetric cipher IDs: - * 0x01 - Salsa20/12 with Poly1305 authentication (ZT default) - * 0x02 - AES256-GCM combined crypto and authentication - * - * Public key types: - * 0x01 - Curve25519 ECDH with SHA-512 KDF - * 0x02 - NIST P-256 ECDH with SHA-512 KDF - * - * Once both peers have a PFS key, they will attempt to send PFS key - * encrypted messages with the PFS flag set using the negotiated - * cipher/auth type. - * - * Note: most of these features such as FIPS and other cipher suites are - * not implemented yet. They're just specified in the protocol for future - * use to support e.g. FIPS requirements. - * - * OK response payload: - * <[8] PFS key set ID of received key set> - * <[1] index in record list of chosen key record> - */ - VERB_SET_EPHEMERAL_KEY = 15, - /** * Push of potential endpoints for direct communication: * <[2] 16-bit number of paths> -- cgit v1.2.3