Browse Source

Remove unimplemented SET_EPHEMERAL_KEY for now.

Adam Ierymenko 9 years ago
parent
commit
c0df1169ee
2 changed files with 0 additions and 58 deletions
  1. 0 1
      node/Packet.cpp
  2. 0 57
      node/Packet.hpp

+ 0 - 1
node/Packet.cpp

@@ -52,7 +52,6 @@ const char *Packet::verbString(Verb v)
 		case VERB_NETWORK_CONFIG_REFRESH: return "NETWORK_CONFIG_REFRESH";
 		case VERB_MULTICAST_GATHER: return "MULTICAST_GATHER";
 		case VERB_MULTICAST_FRAME: return "MULTICAST_FRAME";
-		case VERB_SET_EPHEMERAL_KEY: return "SET_EPHEMERAL_KEY";
 		case VERB_PUSH_DIRECT_PATHS: return "PUSH_DIRECT_PATHS";
 		case VERB_CIRCUIT_TEST: return "CIRCUIT_TEST";
 		case VERB_CIRCUIT_TEST_REPORT: return "CIRCUIT_TEST_REPORT";

+ 0 - 57
node/Packet.hpp

@@ -844,63 +844,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>