idnits 2.17.1 draft-gwerder-messagevortexmain-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 58 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2020) is 1505 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Gwerder 3 Internet-Draft FHNW 4 Intended status: Experimental March 12, 2020 5 Expires: September 13, 2020 7 MessageVortex Protocol 8 draft-gwerder-messagevortexmain-04 10 Abstract 12 The MessageVortex (referred to as Vortex) protocol achieves different 13 degrees of anonymity, including sender, receiver, and third-party 14 anonymity, by specifying messages embedded within existing transfer 15 protocols, such as SMTP or XMPP, sent via peer nodes to one or more 16 recipients. 18 The protocol outperforms others by decoupling the transport from the 19 final transmitter and receiver. No trust is placed into any 20 infrastructure except for that of the sending and receiving parties 21 of the message. The creator of the routing block has full control 22 over the message flow. Routing nodes gain no non-obvious knowledge 23 about the messages even when collaborating. While third-party 24 anonymity is always achieved, the protocol also allows for either 25 sender or receiver anonymity. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 13, 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 63 1.2. Protocol Specification . . . . . . . . . . . . . . . . . 5 64 1.3. Number Specification . . . . . . . . . . . . . . . . . . 5 65 2. Entities Overview . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Node . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1.1. Blocks . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1.2. NodeSpec . . . . . . . . . . . . . . . . . . . . . . 6 69 2.1.2.1. NodeSpec for SMTP nodes . . . . . . . . . . . . . 6 70 2.1.2.2. NodeSpec for XMPP nodes . . . . . . . . . . . . . 6 71 2.2. Peer Partners . . . . . . . . . . . . . . . . . . . . . . 7 72 2.3. Encryption keys . . . . . . . . . . . . . . . . . . . . . 7 73 2.3.1. Identity Keys . . . . . . . . . . . . . . . . . . . . 7 74 2.3.2. Peer Key . . . . . . . . . . . . . . . . . . . . . . 7 75 2.3.3. Sender Key . . . . . . . . . . . . . . . . . . . . . 7 76 2.4. Vortex Message . . . . . . . . . . . . . . . . . . . . . 8 77 2.5. Message . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 2.6. Key and MAC specifications and usage . . . . . . . . . . 9 79 2.6.1. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 9 80 2.6.2. Symmetric Keys . . . . . . . . . . . . . . . . . . . 9 81 2.7. Transport Address . . . . . . . . . . . . . . . . . . . . 10 82 2.8. Identity . . . . . . . . . . . . . . . . . . . . . . . . 10 83 2.8.1. Peer Identity . . . . . . . . . . . . . . . . . . . . 10 84 2.8.2. Ephemeral Identity . . . . . . . . . . . . . . . . . 10 85 2.8.3. Official Identity . . . . . . . . . . . . . . . . . . 10 86 2.9. Workspace . . . . . . . . . . . . . . . . . . . . . . . . 11 87 2.10. Multi-use Reply Blocks . . . . . . . . . . . . . . . . . 11 88 2.11. Protocol Version . . . . . . . . . . . . . . . . . . . . 11 89 3. Layer Overview . . . . . . . . . . . . . . . . . . . . . . . 11 90 3.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 12 91 3.2. Blending Layer . . . . . . . . . . . . . . . . . . . . . 12 92 3.3. Routing Layer . . . . . . . . . . . . . . . . . . . . . . 12 93 3.4. Accounting Layer . . . . . . . . . . . . . . . . . . . . 13 94 4. Vortex Message . . . . . . . . . . . . . . . . . . . . . . . 13 95 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 96 4.2. Message Prefix Block (MPREFIX) . . . . . . . . . . . . . 13 97 4.3. Inner Message Block . . . . . . . . . . . . . . . . . . . 14 98 4.3.1. Control Prefix Block . . . . . . . . . . . . . . . . 14 99 4.3.2. Control Blocks . . . . . . . . . . . . . . . . . . . 14 100 4.3.2.1. Header Block . . . . . . . . . . . . . . . . . . 14 101 4.3.2.2. Routing Block . . . . . . . . . . . . . . . . . . 15 102 4.3.3. Payload Block . . . . . . . . . . . . . . . . . . . . 15 103 5. General notes . . . . . . . . . . . . . . . . . . . . . . . . 15 104 5.1. Supported Symmetric Ciphers . . . . . . . . . . . . . . . 16 105 5.2. Supported Asymmetric Ciphers . . . . . . . . . . . . . . 16 106 5.3. Supported MACs . . . . . . . . . . . . . . . . . . . . . 16 107 5.4. Supported Paddings . . . . . . . . . . . . . . . . . . . 16 108 5.5. Supported Modes . . . . . . . . . . . . . . . . . . . . . 17 109 6. Blending . . . . . . . . . . . . . . . . . . . . . . . . . . 17 110 6.1. Blending in Attachments . . . . . . . . . . . . . . . . . 17 111 6.1.1. PLAIN embedding into attachments . . . . . . . . . . 18 112 6.1.2. F5 embedding into attachments . . . . . . . . . . . . 19 113 6.2. Blending into an SMTP layer . . . . . . . . . . . . . . . 19 114 6.3. Blending into an XMPP layer . . . . . . . . . . . . . . . 19 115 7. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 116 7.1. Vortex Message Processing . . . . . . . . . . . . . . . . 20 117 7.1.1. Processing of incoming Vortex Messages . . . . . . . 20 118 7.1.2. Processing of Routing Blocks in the Workspace . . . . 22 119 7.1.3. Processing of Outgoing Vortex Messages . . . . . . . 23 120 7.2. Header Requests . . . . . . . . . . . . . . . . . . . . . 23 121 7.2.1. Request New Ephemeral Identity . . . . . . . . . . . 23 122 7.2.2. Request Message Quota . . . . . . . . . . . . . . . . 24 123 7.2.3. Request Increase of Message Quota . . . . . . . . . . 24 124 7.2.4. Request Transfer Quota . . . . . . . . . . . . . . . 24 125 7.2.5. Query Quota . . . . . . . . . . . . . . . . . . . . . 25 126 7.2.6. Request Capabilities . . . . . . . . . . . . . . . . 25 127 7.2.7. Request Nodes . . . . . . . . . . . . . . . . . . . . 25 128 7.2.8. Request Identity Replace . . . . . . . . . . . . . . 26 129 7.2.9. Request Upgrade . . . . . . . . . . . . . . . . . . . 26 130 7.3. Special Blocks . . . . . . . . . . . . . . . . . . . . . 26 131 7.3.1. Error Block . . . . . . . . . . . . . . . . . . . . . 26 132 7.3.2. Requirement Block . . . . . . . . . . . . . . . . . . 26 133 7.3.2.1. Puzzle Requirement . . . . . . . . . . . . . . . 27 134 7.3.2.2. Payment Requirement . . . . . . . . . . . . . . . 27 135 7.3.2.3. Upgrade . . . . . . . . . . . . . . . . . . . . . 27 136 7.4. Routing Operations . . . . . . . . . . . . . . . . . . . 27 137 7.4.1. Mapping Operation . . . . . . . . . . . . . . . . . . 28 138 7.4.2. Split and Merge Operations . . . . . . . . . . . . . 28 139 7.4.3. Encrypt and Decrypt Operations . . . . . . . . . . . 28 140 7.4.4. Add and Remove Redundancy Operations . . . . . . . . 29 141 7.4.4.1. Padding Operation . . . . . . . . . . . . . . . . 29 142 7.4.4.2. Apply Matrix . . . . . . . . . . . . . . . . . . 30 143 7.4.4.3. Encrypt Target Block . . . . . . . . . . . . . . 30 144 7.5. Processing of Vortex Messages . . . . . . . . . . . . . . 30 146 8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 30 147 8.1. Accounting Operations . . . . . . . . . . . . . . . . . . 31 148 8.1.1. Time-Based Garbage Collection . . . . . . . . . . . . 31 149 8.1.2. Time-Based Routing Initiation . . . . . . . . . . . . 31 150 8.1.3. Routing Based Quota Updates . . . . . . . . . . . . . 31 151 8.1.4. Routing Based Authorization . . . . . . . . . . . . . 31 152 8.1.5. Ephemeral Identity Creation . . . . . . . . . . . . . 31 153 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 154 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 155 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 156 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 157 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 158 12.2. Informative References . . . . . . . . . . . . . . . . . 36 159 Appendix A. The ASN.1 schema for Vortex messages . . . . . . . . 37 160 A.1. The main VortexMessageBlocks . . . . . . . . . . . . . . 37 161 A.2. The VortexMessage Ciphers Structures . . . . . . . . . . 37 162 A.3. The VortexMessage Request Structures . . . . . . . . . . 37 163 A.4. The VortexMessage Replies Structures . . . . . . . . . . 37 164 A.5. The VortexMessage Requirements Structures . . . . . . . . 37 165 A.6. The VortexMessage Helpers Structures . . . . . . . . . . 37 166 A.7. The VortexMessage Additional Structures . . . . . . . . . 37 167 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 169 1. Introduction 171 Anonymisation is hard to achieve. Most previous attempts relied on 172 either trust in a dedicated infrastructure or a specialized 173 networking protocol. 175 Instead of defining a transport layer, Vortex piggybacks on other 176 transport protocols. A blending layer embeds Vortex messages 177 (VortexMessage) into ordinary messages of the respective transport 178 protocol. This layer picks up the messages, passes them to a routing 179 layer, which applies local operations to the messages, and resends 180 the new message chunks to the next recipients. 182 A processing node learns as little as possible from the message or 183 the network utilized. The operations have been designed to be 184 sensible in any context. The 'onionized' structure of the protocol 185 makes it impossible to follow the trace of a message without having 186 control over the processing node. 188 MessageVortex is a protocol which allows sending and receiving 189 messages by using a routing block instead of a destination address. 190 With this approach, the sender has full control over all parameters 191 of the message flow. 193 A message is split and reassembled during transmission. Chunks of 194 the message may carry redundant information to avoid service 195 interruptions during transit. Decoy and message traffic are not 196 differentiable as the nature of the addRedundancy operation allows 197 each generated portion to be either message or decoy. Therefore, any 198 routing node is unable to distinguish between message and decoy 199 traffic. 201 After processing, a potential receiver node knows if the message is 202 destined for it (by creating a chunk with ID 0) or other nodes. Due 203 to missing keys, no other node may perform this processing. 205 This RFC begins with general terminology (see Section 2) followed by 206 an overview of the process (see Section 3). The subsequent sections 207 describe the details of the protocol. 209 1.1. Requirements Language 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [RFC2119]. 215 1.2. Protocol Specification 217 Appendix A specifies all relevant parts of the protocol in ASN.1 (see 218 [CCITT.X680.2002] and [CCITT.X208.1988]). The blocks are DER 219 encoded, if not otherwise specified. 221 1.3. Number Specification 223 All numbers within this document are, if not suffixed, decimal 224 numbers. Numbers suffixed with a small letter 'h' followed by two 225 hexadecimal digits are octets written in hexadecimal. For example, a 226 blank ASCII character (' ') is written as 20h and a capital 'K' in 227 ASCII as 4Bh. 229 2. Entities Overview 231 The following entities used in this document are defined below. 233 2.1. Node 235 The term 'node' describes any computer system connected to other 236 nodes, which support the MessageVortex Protocol. A 'node address' is 237 typically an email address, an XMPP address or other transport 238 protocol identity supporting the MessageVortex protocol. Any address 239 SHOULD include a public part of an 'identity key' to allow messages 240 to transmit safely. One or more addresses MAY belong to the same 241 node. 243 2.1.1. Blocks 245 A 'block' represents an ASN.1 sequence in a transmitted message. We 246 embed messages in the transport protocol, and these messages may be 247 of any size. 249 2.1.2. NodeSpec 251 A nodeSpec block, as specified in Appendix A.6, expresses an 252 addressable node in a unified format. The nodeSpec contains a 253 reference to the routing protocol, the routing address within this 254 protocol, and the keys required for addressing the node. This RFC 255 specifies transport layers for XMPP and SMTP. Additional transport 256 layers will require an extension to this RFC. 258 2.1.2.1. NodeSpec for SMTP nodes 260 An alternative address representation is defined that allows a 261 standard email client to address a Vortex node. A node SHOULD 262 support the smtpAlternateSpec (its specification is noted in ABNF as 263 in [RFC5234]). For applications with QR code support, an 264 implementation SHOULD use the smtpUrl representation. 266 localPart = 267 domain = 268 email = localPart "@" domain 269 keySpec = 270 smtpAlternateSpec = localPart ".." keySpec ".." domain "@localhost" 271 smtpUrl = "vortexsmtp://" smtpAlternateSpec 273 This representation does not support quoted local part SMTP 274 addresses. 276 2.1.2.2. NodeSpec for XMPP nodes 278 Typically, a node specification follows the ASN.1 block NodeSpec. 279 For support of XMPP clients, an implementation SHOULD support the 280 jidAlternateSpec (its specification is noted in ABNF as in 281 [RFC5234]). 283 localPart = 284 domain = 285 resourcePart = 286 jid = localPart "@" domain [ "/" resourcePart ] 287 keySpec = ; 288 jidAlternateSpec = localPart ".." keySpec ".." 289 domain "@localhost" [ "/" resourcePart ] 290 jidUrl = "vortexxmpp://" jidAlternateSpec 292 2.2. Peer Partners 294 This document refers to two or more message sending or receiving 295 entities as peer partners. One partner sends a message, and all 296 others receive one or more messages. Peer partners are message 297 specific, and each partner always connects directly to a node. 299 2.3. Encryption keys 301 Several keys are required for a Vortex message. For identities and 302 ephemeral identities (see below), we use asymmetric keys, while 303 symmetric keys are used for message encryption. 305 2.3.1. Identity Keys 307 Every participant of the network includes an asymmetric key, which 308 SHOULD be either an EC key with a minimum length of 384 bits or an 309 RSA key with a minimum length of 2048 bits. 311 The public key must be known by all parties writing to or through the 312 node. 314 2.3.2. Peer Key 316 Peer keys are symmetrical keys transmitted with a Vortex message and 317 are always known to the node sending the message, the node receiving 318 the message, and the creator of the routing block. 320 A peer key is included in the Vortex message as well as the building 321 instructions for subsequent Vortex messages (see RoutingCombo in 322 Appendix A). 324 2.3.3. Sender Key 326 The sender key is a symmetrical key protecting the identity and 327 routing block of a Vortex message. It is encrypted with the 328 receiving peer key and prefixed to the identity block. This key 329 further decouples the identity and processing information from the 330 previous key. 332 A sender key is known to only one peer of a Vortex message and the 333 creator of the routing block. 335 2.4. Vortex Message 337 The term 'Vortex message' represents a single transmission between 338 two routing layers. A message adapted to the transport layer by the 339 blending layer is called a 'blended Vortex message' (see Section 3). 341 A complete Vortex message contains the following items: 343 o The peer key, which is encrypted with the host key of the node and 344 stored in a prefixBlock, protects the inner Vortex message 345 (innerMessageBlock). 347 o The sender key, also encrypted with the host key of the node, 348 protects the identity and routing block. 350 o The identity block, protected by the sender key, contains 351 information about the ephemeral identity of the sender, replay 352 protection information, header requests (optional), and a 353 requirement reply (optional). 355 o The routing block, protected by the sender key, contains 356 information on how subsequent messages are processed, assembled, 357 and blended. 359 o The payload block, protected by the peer key, contains payload 360 chunks for processing. 362 2.5. Message 364 A message is content to be transmitted from a single sender to a 365 recipient. The sender uses a routing block either built itself or 366 provided by the receiver to perform the transmission. While a 367 message may be anonymous, there are different degrees of anonymity as 368 described by the following. 370 o If the sender of a message is not known to anyone else except the 371 sender, then this degree is referred to as 'sender anonymity.' 373 o If the receiver of a message is not known to anyone else except 374 the receiver, then the degree is 'receiver anonymity.' 376 o If an attacker is unable to determine the content, original 377 sender, and final receiver, then the degree is considered 'third- 378 party anonymity.' 380 o If a sender or a receiver may be determined as one of a set of 381 entities, then it is referred to as k-anonymity[KAnon]. 383 A message is always MIME encoded as specified in [RFC2045]. 385 2.6. Key and MAC specifications and usage 387 MessageVortex uses a unique encoding for keys. This encoding is 388 designed to be small and flexible while maintaining a specific base 389 structure. 391 The following key structures are available: 393 o SymmetricKey 395 o AsymmetricKey 397 MAC does not require a complete structure containing specs and 398 values, and only a MacAlgorithmSpec is available. The following 399 sections outline the constraints for specifying parameters of these 400 structures where a node MUST NOT specify any parameter more than 401 once. 403 If a crypto mode is specified requiring an IV, then a node MUST 404 provide the IV when specifying the key. 406 2.6.1. Asymmetric Keys 408 Nodes use asymmetric keys for identifying peer nodes (i.e., 409 identities) and encrypting symmetric keys (for subsequent 410 de-/encryption of the payload or blocks). All asymmetric keys MUST 411 contain a key type specifying a strictly-normed key. Also, they MUST 412 contain a public part of the key encoded as an X.509 container and a 413 private key specified in PKCS#8 wherever possible. 415 RSA and EC keys MUST contain a keySize parameter. All asymmetric 416 keys SHOULD contain a padding parameter, and a node SHOULD assume 417 PKCS#1 if no padding is specified. 419 NTRU specification MUST provide the parameters "n", "p", and "q". 421 2.6.2. Symmetric Keys 423 Nodes use symmetric keys for encrypting payloads and control blocks. 424 These symmetric keys MUST contain a key type specifying a key, which 425 MUST be in an encoded form. 427 A node MUST provide a keySize parameter if the key (or, equivalently, 428 the block) size is not standardized or encoded in the name. All 429 symmetric key specifications MUST contain a mode and padding 430 parameter. A node MAY list multiple padding or mode parameters in a 431 ReplyCapability block to offer the recipient a free choice. 433 2.7. Transport Address 435 The term 'transport address' represents the token required to address 436 the next immediate node on the transport layer. An email transport 437 layer would have SMTP addresses, such as 'vortex@example.com,' as the 438 transport address. 440 2.8. Identity 442 2.8.1. Peer Identity 444 The peer identity may contain the following information of a peer 445 partner: 447 o A transport address (always) and the public key of this identity, 448 given there is no recipient anonymity. 450 o A routing block, which may be used to contact the sender. If 451 striving for recipient anonymity, then this block is required. 453 o The private key, which is only known by the owner of the identity. 455 2.8.2. Ephemeral Identity 457 Ephemeral identities are temporary identities created on a single 458 node. These identities MUST NOT relate to another identity on any 459 other node so that they allow bookkeeping for a node. Each ephemeral 460 identity has a workspace assigned, and may also have the following 461 items assigned. 463 o An asymmetric key pair to represent the identity. 465 o A validity time of the identity. 467 2.8.3. Official Identity 469 An official identity may have the following items assigned. 471 o Routing blocks used to reply to the node. 473 o A list of assigned ephemeral identities on all other nodes and 474 their projected quotas. 476 o A list of known nodes with the respective node identity. 478 2.9. Workspace 480 Every official or ephemeral identity has a workspace, which consists 481 of the following elements. 483 o Zero or more routing blocks to be processed. 485 o Slots for a payload block sequentially numbered. Every slot: 487 * MUST contain a numerical ID identifying the slot. 489 * MAY contain payload content. 491 * If a block contains a payload, then it MUST contain a validity 492 period. 494 2.10. Multi-use Reply Blocks 496 'Multi-use reply blocks' (MURB) are a special type routing block sent 497 to a receiver of a message or request. A sender may use such a block 498 one or several times to reply to the sender linked to the ephemeral 499 identity, and it is possible to achieve sender anonymity using MURBs. 501 A vortex node MAY deny the use of MURBs by indicating a maxReplay 502 equal to zero when sending a ReplyCapability block. An unobservable 503 node SHOULD deny the use of MURBs. 505 2.11. Protocol Version 507 This Document describes the version 1 of the protocol. The message 508 PrefixBlock contains an optional version indicator. If absent 509 protocol version 1 should be assumed. 511 3. Layer Overview 513 The protocol is designed in four layers as shown in Figure 1. 515 +------------------------------------------------------------------+ 516 | Vortex Node | 517 | +--------------------------------------------------------------+ | 518 | | Accounting | | 519 | |______________________________________________________________| | 520 | | 521 | +--------------------------------------------------------------+ | 522 | | Routing | | 523 | |______________________________________________________________| | 524 | | 525 | +---------------------------+ +--------------------------------+ | 526 | | Blending | | Blending | | 527 | |___________________________| |________________________________| | 528 |__________________________________________________________________| 529 +---------------------------+ +--------------+ +---------------+ 530 | Transport | | Transport in | | Transport out | 531 |___________________________| |______________| |_______________| 533 Figure 1: Layer overview 535 Every participating node MUST implement the layer's blending, 536 routing, and accounting. There MUST be at least one incoming and one 537 outgoing transport layer available to a node. All blending layers 538 SHOULD connect to the respective transport layers for sending and 539 receiving packets. 541 3.1. Transport Layer 543 The transport layer transfers the blended Vortex messages to the next 544 vortex node and stores it until the next blending layer picks up the 545 message. 547 The transport layer infrastructure SHOULD NOT be specific to 548 anonymous communication and should contain significant portions of 549 non-Vortex traffic. 551 3.2. Blending Layer 553 The blending layer embeds blended Vortex Message into the transport 554 layer data stream and extracts the packets from the transport layer. 556 3.3. Routing Layer 558 The routing layer expands the information contained in MessageVortex 559 packets, processes them, and passes generated packets to the 560 respective blending layer. 562 3.4. Accounting Layer 564 The accounting layer tracks all ephemeral identities authorized to 565 use a MessageVortex node and verifies the available quotas to an 566 ephemeral identity. 568 4. Vortex Message 570 4.1. Overview 572 Figure 2 shows a Vortex message. The enclosed sections denote 573 encrypted blocks, and the three or four-letter abbreviations denote 574 the key required for decryption. The abbreviation k_h stands for the 575 asymmetric host key, and sk_p is the symmetric peer key. The 576 receiving node obtains this key by decrypting MPREFIX with its host 577 key k_h. Then, sk_s is the symmetric sender key. When decrypting 578 the MPREFIX block, the node obtains this key. The sender key 579 protects the header and routing blocks by guaranteeing the node 580 assembling the message does not know about upcoming identities, 581 operations, and requests. The peer key protects the message, 582 including its structure, from third-party observers. 584 +-+---+-+-+---+-+---+-+-+---+-+-+---+-+-------+-+ 585 | | | | | | C | | | | | | R | | | | 586 | | | | | | P | | | H | | | O | | | | 587 | | M | | | | R | | | E | | | U | | P | | 588 | | P | | | | E | | | A | | | T | | A | | 589 | | R | | | | F | | | D | | | I | | Y | | 590 | | E | | | | I | | | E | | | N | | L | | 591 | | F | | | | X | | | R | | | G | | O | | 592 | | I | | | +---+ | |___| | |___| | A | | 593 | | X | | | k_h | sk_s | sk_s | D | | 594 | |___| | |_______|_______|_______|_______| | 595 | k_h | sk_p | 596 |_______|___________________________________| 598 Figure 2: Vortex message overview 600 4.2. Message Prefix Block (MPREFIX) 602 The PrefixBlock contains a symmetrical key as defined in Appendix A.1 603 and is encrypted using the host key of the receiving peer host. The 604 symmetric key utilized MUST be from the set advertised by a 605 CapabilitiesReplyBlock (see Section 7.2.6). A node MAY choose any 606 parameters omitted in the CapabilitiesReplyBlock freely unless stated 607 otherwise in Section 7.2.6. A node SHOULD avoid sending unencrypted 608 PrefixBlocks, and a prefix block MUST contain the same forward-secret 609 as the other prefix as well as the routing and header blocks. A host 610 MAY reply to a message with an unencrypted message block, but any 611 reply to a message SHOULD be encrypted. 613 The sender MUST choose a key which may be encrypted with the host key 614 in the respective PrefixBlock using the padding advertised by the 615 CapabilitiesReplyBlock. 617 4.3. Inner Message Block 619 A node MUST always encrypt an InnerMessageBlock with the symmetric 620 key of the PrefixBlock to hide the inner structure of the message. 621 The InnerMessageBlock SHOULD always accommodate four or more payload 622 chunks. 624 An InnerMessageBlock contains so-called forwardSecrets, a random 625 number that MUST be the same in the PrefixBlock, HeaderBlock, 626 RoutingBlock, and PrefixBlock. Nodes receiving messages containing 627 non-matching forwardSecrets MUST discard these messages and SHOULD 628 NOT send an error message. If a node receives too many messages with 629 illegal forward secrets, then the node SHOULD delete this identity. 630 A node receiving a message with a broken forwardSecret SHOULD treat 631 the block as a replayed block and discard it regardless of a valid 632 forwardSecret. Any replay within the replay protection time MUST be 633 discarded regardless of a correct forward secret. 635 4.3.1. Control Prefix Block 637 Control prefix (CPREFIX) and MPREFIX blocks share the same structure 638 and logic as well as containing the sender key sk_s. If an MPREFIX 639 block is unencrypted, a node MAY omit the CPREFIX block. An omitted 640 CPREFIX block results in unencrypted control blocks (e.g., the 641 HeaderBlock and RoutingBlock). 643 A prefix block MUST contain the same forwardSecret as the other 644 prefix, the routing block, and the header block. 646 4.3.2. Control Blocks 648 The control blocks of the HeaderBlock and a RoutingBlock contain the 649 core information to process the payload. 651 4.3.2.1. Header Block 653 The header block (see HeaderBlock in Appendix A) contains the 654 following information. 656 o It MUST contain the local ephemeral identity of the routing block 657 builder. 659 o It MAY contain header requests. 661 o It MAY contain the solution to a PuzzleRequired block previously 662 opposed in a header request. 664 The list of header requests MAY be one of the following. 666 o Empty. 668 o Contain a single identity create request (HeaderRequestIdentity). 670 o Contain a single increase quota request. 672 If a header block violates these rules, then a node MUST NOT reply to 673 any header request. The payload and routing blocks SHOULD still be 674 added to the workspace and processed if the message quota is not 675 exceeded. 677 4.3.2.2. Routing Block 679 The routing block (see RoutingBlock in Appendix A) contains the 680 following information. 682 o It MUST contain a serial number uniquely identifying the routing 683 block of this user. The serial number MUST be unique during the 684 lifetime of the routing block. 686 o It MUST contain the same forward secret as the two prefix blocks 687 and the header block. 689 o It MAY contain assembly and processing instructions for subsequent 690 messages. 692 o It MAY contain a reply block for messages assigned to the owner of 693 the identity. 695 4.3.3. Payload Block 697 Each InnerMessageBlock with routing information SHOULD contain at 698 least four PayloadChunks. 700 5. General notes 702 The MessageVortex protocol is a modular protocol that allows the use 703 of different encryption algorithms. For its operation, a Vortex node 704 SHOULD always support at least two distinct types of algorithms, 705 paddings or modes such that they rely on two mathematical problems. 707 5.1. Supported Symmetric Ciphers 709 A node MUST support the following symmetric ciphers. 711 o AES128 (see [FIPS-AES] for AES implementation details). 713 o AES256. 715 o CAMELLIA128 (see [RFC3657] Chapter 3 for Camellia implementation 716 details). 718 o CAMELLIA256. 720 A node SHOULD support any standardized key larger than the smallest 721 key size. 723 A node MAY support Twofish ciphers (see [TWOFISH]). 725 5.2. Supported Asymmetric Ciphers 727 A node MUST support the following asymmetric ciphers. 729 o RSA with key sizes greater or equal to 2048 ([RFC8017]). 731 o ECC with named curves secp384r1, sect409k1 or secp521r1 (see 732 [SEC1]). 734 5.3. Supported MACs 736 A node MUST support the following Message Authentication Codes (MAC). 738 o SHA3-256 (see [ISO-10118-3] for SHA implementation details). 740 o RipeMD160 (see [ISO-10118-3] for RIPEMD implementation details). 742 A node SHOULD support the following MACs. 744 o SHA3-512. 746 o RipeMD256. 748 o RipeMD512. 750 5.4. Supported Paddings 752 A node MUST support the following paddings specified in [RFC8017]. 754 o PKCS1 (see [RFC8017]). 756 o PKCS7 (see [RFC5958]). 758 5.5. Supported Modes 760 A node MUST support the following modes. 762 o CBC (see [RFC1423]) such that the utilized IV must be of equal 763 length as the key. 765 o EAX (see [EAX]). 767 o GCM (see [RFC5288]). 769 o NONE (only used in special cases, see Section 11). 771 A node SHOULD NOT use the following modes. 773 o NONE (except as stated when using the addRedundancy function). 775 o ECB. 777 A node SHOULD support the following modes. 779 o CTR ([RFC3686]). 781 o CCM ([RFC3610]). 783 o OCB ([RFC7253]). 785 o OFB ([MODES]). 787 6. Blending 789 Each node supports a fixed set of blending capabilities, which may be 790 different for incoming and outgoing messages. 792 The following sections describe the blending mechanism. There are 793 currently two blending layers specified with one for the Simple Mail 794 Transfer Protocol (SMTP, see [RFC5321]) and the second for the 795 Extensible Messaging and Presence Protocol (XMPP, see [RFC6120]). 796 All nodes MUST at least support "encoding=plain:0,256". 798 6.1. Blending in Attachments 800 There are two types of blending supported when using attachments. 802 o Plain binary encoding with offset (PLAIN). 804 o Embedding with F5 in an image (F5). 806 A node MUST support PLAIN blending for reasons of interoperability 807 whereas a node MAY support blending using F5. 809 6.1.1. PLAIN embedding into attachments 811 A blending layer embeds a VortexMessage in a carrier file with an 812 offset for PLAIN blending. For replacing a file start, a node MUST 813 use the offset 0. The routing node MUST choose the payload file for 814 the message, and SHOULD use a credible payload type (e.g., MIME type) 815 with high entropy. Furthermore, it SHOULD prefix a valid header 816 structure to avoid easy detection of the Vortex message. Finally, a 817 routing node SHOULD use a valid footer, if any, to a payload file to 818 improve blending. 820 The blended Vortex message is embedded in one or more message chunks, 821 each starting with two unsigned integers of variable length. The 822 integer starts with the LSB, and if bit 7 is set, then there is 823 another byte following. There cannot be more than four bytes where 824 the last, fourth byte is always 8 bit. The three preceding bytes 825 have a payload of seven bits each, which results in a maximum number 826 of 2^29 bits. The first of the extracted numbers reflect the number 827 of bytes in the chunk after the length descriptors. The second 828 contains the number of bytes to be skipped to reach the next chunk. 829 There exists no "last chunk" indicator. A chunk or the gap MAY 830 surpass the end of the file. 832 position:00h 02h 04h 06h 08h ... 400h 402h 404h 406h 408h 40Ah 833 value: 01 02 03 04 05 06 07 08 09 ... 01 05 0A 0B 0C 0D 0E 0F f0 03 12 13 835 Embedding: "(plain:1024)" 837 Result: 0A 13 (+ 494 omitted bytes; then skip 12 bytes to next chunk) 839 A node SHOULD offer at least one PLAIN blending method and MAY offer 840 multiple offsets for incoming Vortex messages. 842 A plain blending is specified as the following. 844 plainEncoding = "("plain:" 845 [ "," ]* ")" 847 6.1.2. F5 embedding into attachments 849 For F5, a blending layer embeds a Vortex message into a jpeg file 850 according to [F5]. The password for blending may be public, and a 851 routing node MAY advertise multiple passwords. The use of F5 adds 852 approximately tenfold transfer volume to the message. A routing 853 block building node SHOULD only use F5 blending where appropriate. 855 A blending in F5 is specified as the following. 857 f5Encoding = "(F5:" [ "," ]* ")" 859 Commas and backslashes in passwords MUST be escaped with a backslash 860 whereas closing brackets are treated as normal password characters 861 unless they are the final character of the encoding specification 862 string. 864 6.2. Blending into an SMTP layer 866 Email messages with content MUST be encoded with Multipurpose 867 Internet Mail Extensions (MIME) as specified in [RFC2045]. All nodes 868 MUST support BASE64 encoding and MUST test all sections of a MIME 869 message for the presence of a VortexMessage. 871 A vortex message is present if a block containing the peer key at the 872 known offset of any MIME part decodes correctly. 874 A node SHOULD support SMTP blending for sending and receiving. For 875 sending SMTP, the specification in [RFC5321] must be used. TLS 876 layers MUST always be applied when obtaining messages using POP3 (as 877 specified in [RFC1939] and [RFC2595]) or IMAP (as specified in 878 [RFC3501]). Any SMTP connection MUST employ a TLS encryption when 879 passing credentials. 881 6.3. Blending into an XMPP layer 883 For interoperability, an implementation SHOULD provide XMPP blending. 885 Blending into XMPP traffic is performed using the [XEP-0231] 886 extension of the XMPP protocol. 888 PLAIN and F5 blending are acceptable for this transport layer. 890 7. Routing 891 7.1. Vortex Message Processing 893 7.1.1. Processing of incoming Vortex Messages 895 An incoming message is considered initially unauthenticated. A node 896 should consider a VortexMessage as authenticated as soon as the 897 ephemeral identity is known and is not temporary. 899 For an unauthenticated message, the following rules apply. 901 o A node MUST ignore all Routing blocks. 903 o A node MUST ignore all Payload blocks. 905 o A node SHOULD accept identity creation requests in unauthenticated 906 messages. 908 o A node MUST ignore all other header requests except identity 909 creation requests. 911 o A node MUST ignore all identity creation requests belonging to an 912 existing identity. 914 A message is considered authenticated as soon as the identity used in 915 the header block is known and not temporary. A node MUST NOT treat a 916 message as authenticated if the specified maximum number of replays 917 is reached. For authenticated messages, the following rules apply. 919 o A node MUST ignore identity creation requests. 921 o A node MUST replace the current reply block with the reply block 922 provided in the routing block (if any). The node MUST keep the 923 reply block if none is provided. 925 o A node SHOULD process all header requests. 927 o A node SHOULD add all routing blocks to the workspace. 929 o A node SHOULD add all payload blocks to the workspace. 931 A routing node MUST decrement the message quota by one if a received 932 message is authenticated, valid, and contains at least one payload 933 block. If a message is identified as duplicate according to the 934 reply protection, then a node MUST NOT decrement the message quota. 936 The message processing works according pseudo-code shown below. 938 function incomming_message(VortexMessage blendedMessage) { 940 try{ 941 msg = unblend( blendedMessage ); 942 if( not msg ) { 943 // Abort processing 944 throw exception( "no embedded message found" ) 945 } else { 946 hdr = get_header( msg ) 947 if( not known_identity( hdr.identity ) { 948 if( get_requests( hdr ) contains HeaderRequestIdentity ) { 949 create_new_identity( hdr ).set_temporary( true ) 950 send_message( create_requirement( hdr ) ) 951 } else { 952 // Abort processing 953 throw exception( "identity unknown" ) 954 } 955 } else { 956 if( is_duplicate_or_replayed( msg ) ) { 957 // Abort processing 958 throw exception "duplicate or replayed message" ) 959 } else { 960 if( get_accounting( hdr.identity ).is_temporary() ) { 961 if( not verify_requirement( hdr.identity, msg ) ) { 962 get_accounting( hdr.identity ).set_temporary( false ) 963 } 964 } 965 if( get_accounting( hdr ).is_temporary() ) { 966 throw exception( "no processing on temporary identity" ) 967 } 969 // Message authenticated 970 get_accounting( hdr.identity ).register_for_replay_protection( msg ) 971 if( not verify_mtching_forward_secrets( msg ) ) { 972 throw exception( "forward secret missmatch" ) 973 } 974 if( contains_payload( msg ) ) { 975 if( get_accounting( hdr.identity ).decrement_message_quota() ) { 976 while index,nextPayloadBlock = get_next_payload_block( msg ) { 977 add_workspace( header.identity, index, nextPayloadBlock ) 978 } 979 while nextRoutingBlock = get_next_routing_block( msg ) { 980 add_workspace( hdr.identity, add_routing( nextRoutingBlock ) ) 981 } 982 process_reserved_mapping_space( msg ) 983 while nextRequirement = get_next_requirement( hdr ) { 984 add_workspace( hdr.identity, nextRequirement ) 985 } 986 } else { 987 throw exception( "Message quota exceeded" ) 989 } 990 } 991 } 992 } 993 } catch( exception e ) { 994 // Message processing failed 995 throw e; 996 } 997 } 999 7.1.2. Processing of Routing Blocks in the Workspace 1001 A routing workspace consists of the following items. 1003 o The identity linked to, which determines the lifetime of the 1004 workspace. 1006 o The linked routing combos (RoutingCombo). 1008 o A payload chunk space with the following multiple subspaces 1009 available: 1011 * ID 0 represents a message to be embedded (when reading) or a 1012 message to be extracted to the user (when written). 1014 * ID 1 to ID maxPayloadBlocks represent the payload chunk slots 1015 in the target message. 1017 * All blocks between ID maxPayloadBlocks + 1 to ID 32767 belong 1018 to a temporary routing block-specific space. 1020 * All blocks between ID 32768 to ID 65535 belong to a shared 1021 space available to all operations of the identity. 1023 The accounting layer typically triggers processing and represents 1024 either a cleanup action or a routing event. A cleanup event deletes 1025 the following information from all workspaces. 1027 o All processed routing combos. 1029 o All routing combos with expired usagePeriod. 1031 o All payload chunks exceeding the maxProcess time. 1033 o All expired objects. 1035 o All expired puzzles. 1037 o All expired identities. 1039 o All expired replay protections. 1041 Note that maxProcessTime reflects the number of seconds since the 1042 arrival of the last octet of the message at the transport layer 1043 facility. A node SHOULD NOT take additional processing time (e.g., 1044 for anti-UBE or anti-virus) into account. 1046 The accounting layer triggers routing events occurring at least the 1047 minProcessTime after the last octet of the message arrived at the 1048 routing layer. A node SHOULD choose the latest possible moment at 1049 which the peer node receives the last octet of the assembled message 1050 before the maxProcessTime is reached. The calculation of this last 1051 point in time where a message may be set SHOULD always assume that 1052 the target node is working. A sending node SHOULD choose the time 1053 within these bounds randomly. An accounting layer MAY trigger 1054 multiple routing combos in bulk to further obfuscate the identity of 1055 a single transport message. 1057 First, the processing node escapes the payload chunk at ID 0 if 1058 needed (e.g., a non-special block is starting with a backslash). 1059 Next, it executes all processing instructions of the routing combo in 1060 the specified sequence. If an instruction fails, then the block at 1061 the target ID of the operation remains unchanged. The routing layer 1062 proceeds with the subsequent processing instructions by ignoring the 1063 error. For a detailed description of the operations, see 1064 Section 7.4. If a node succeeds in building at least one payload 1065 chunk, then a VortexMessage is composed and passed to the blending 1066 layer. 1068 7.1.3. Processing of Outgoing Vortex Messages 1070 The blending layer MUST compose a transport layer message according 1071 to the specification provided in the routing combo. It SHOULD choose 1072 any decoy message or steganographic carrier in such a way that the 1073 dead parrot syndrome, as specified in [DeadParrot], is avoided. 1075 7.2. Header Requests 1077 Header requests are control requests for the anonymization system. 1078 Messages with requests or replies only MUST NOT affect any quota. 1080 7.2.1. Request New Ephemeral Identity 1082 Requesting a new ephemeral identity is performed by sending a message 1083 containing a header block with the new identity and an identity 1084 creation request (HeaderRequestIdentity) to a node. The node MAY 1085 send an error block (see Section 7.3.1) if it rejects the request. 1087 If a node accepts an identity creation request, then it MUST send a 1088 reply. A node accepting a request without a requirement MUST send 1089 back a special block containing "no error". A node accepting a 1090 request under the precondition of a requirement to be fulfilled MUST 1091 send a special block containing a requirement block. 1093 A node SHOULD NOT reply to any clear-text requests if the node does 1094 not want to disclose its identity as a Vortex node officially. A 1095 node MUST reply with an error block if a valid identity is used for 1096 the request. 1098 7.2.2. Request Message Quota 1100 Any valid ephemeral identity may request an increase of the current 1101 message quota to a specific value at any time. The request MUST 1102 include a reply block in the header and may contain other parts. If 1103 a requested value is lower than the current quota, then the node 1104 SHOULD NOT refuse the quota request and SHOULD send a "no error" 1105 status. 1107 A node SHOULD reply to a HeaderRequestIncreaseMessageQuota request 1108 (see Appendix A) of a valid ephemeral identity. The reply MUST 1109 include a requirement, an error message or a "no error" status 1110 message. 1112 7.2.3. Request Increase of Message Quota 1114 A node may request to increase the current message quota by sending a 1115 HeaderRequestIncreaseMessageQuota request to the routing node. The 1116 value specified within the node is the new quota. 1117 HeaderRequestIncreaseMessageQuota requests MUST include a reply 1118 block, and a node SHOULD NOT use a previously sent MURB to reply. 1120 If the requested quota is higher than the current quota, then the 1121 node SHOULD send a "no error" reply. If the requested quota is not 1122 accepted, then the node SHOULD send a requestedQuotaOutOfBand reply. 1124 A node accepting the request MUST send a RequirementBlock or a "no 1125 error block." 1127 7.2.4. Request Transfer Quota 1129 Any valid ephemeral identity may request to increase the current 1130 transfer quota to a specific value at any time. The request MUST 1131 include a reply block in the header and may contain other parts. If 1132 a requested value is lower than the current quota, then the node 1133 SHOULD NOT refuse the quota request and SHOULD send a "no error" 1134 status. 1136 A node SHOULD reply to a HeaderRequestIncreaseTransferQuota request 1137 (see Appendix A) of a valid ephemeral identity. The reply MUST 1138 include a requirement, an error message or a "no error" status 1139 message. 1141 7.2.5. Query Quota 1143 Any valid ephemeral identity may request the current message and 1144 transfer quota. The request MUST include a reply block in the header 1145 and may contain other parts. 1147 A node MUST reply to a HeaderRequestQueryQuota request (see 1148 Appendix A), which MUST include the current message quota and the 1149 current message transfer quota. The reply to this request MUST NOT 1150 include a requirement. 1152 7.2.6. Request Capabilities 1154 Any node MAY request the capabilities of another node, which include 1155 all information necessary to create a parseable VortexMessage. Any 1156 node SHOULD reply to any encrypted HeaderRequestCapability. 1158 A node SHOULD NOT reply to clear-text requests if the node does not 1159 want to disclose its identity as a Vortex node officially. A node 1160 MUST reply if a valid identity is used for the request, and it MAY 1161 reply to unknown identities. 1163 7.2.7. Request Nodes 1165 A node may ask another node for a list of routing node addresses and 1166 keys, which may be used to bootstrap a new node and add routing nodes 1167 to increase the anonymization of a node. The receiving node of such 1168 a request SHOULD reply with a requirement (e.g., 1169 RequirementPuzzleRequired). 1171 A node MAY reply to a HeaderRequest request (see Appendix A) of a 1172 valid ephemeral identity, and the reply MUST include a requirement, 1173 an error message or a "no error" status message. A node MUST NOT 1174 reply to an unknown identity, and SHOULD always reply with the same 1175 result set to the same identity. 1177 7.2.8. Request Identity Replace 1179 This request type allows a receiving node to replace an existing 1180 identity with the identity provided in the message, and is required 1181 if an adversary manages to deny the usage of a node (e.g., by 1182 deleting the corresponding transport account). Any sending node may 1183 recover from such an attack by sending a valid authenticated message 1184 to another identity to provide the new transport and key details. 1186 A node SHOULD reply to such a request from a valid known identity, 1187 and the reply MUST include an error message or a "no error" status 1188 message. 1190 7.2.9. Request Upgrade 1192 This request type allows a node to request a new version of the 1193 software in an anonymous, unliked manor. The identifier MUST 1194 identify the software product uniquely. The version MUST reflect the 1195 version tag of the currently installed version or a similarly usable 1196 tag. 1198 7.3. Special Blocks 1200 Special blocks are payload messages that reflect messages from one 1201 node to another and are not visible to the user. A special block 1202 starts with the character sequence '\special' (or 5Ch 73h 70h 65h 63h 1203 69h 61h 6Ch) followed by a DER encoded special block (SpecialBlock). 1204 Any non-special message decoding to ID 0 in a workspace starting with 1205 this character sequence MUST escape all backslashes within the 1206 payload chunk with an additional backslash. 1208 7.3.1. Error Block 1210 An error block may be sent as a reply contained in the payload 1211 section. The error block is embedded in a special block and sent 1212 with any provided reply block. Error messages SHOULD contain the 1213 serial number of the offending header block and MAY contain human- 1214 readable text providing additional messages about the error. 1216 7.3.2. Requirement Block 1218 If a node is receiving a requirement block, then it MUST assume that 1219 the request block is accepted, is not yet processed, and is to be 1220 processed if it meets the contained requirement. A node MUST process 1221 a request as soon as the requirement is fulfilled, and MUST resend 1222 the request as soon as it meets the requirement. 1224 A node MAY reject a request, accept a request without a requirement, 1225 accept a request upon payment (RequirementPaymentRequired), or accept 1226 a request upon solving a proof of work puzzle 1227 (RequirementPuzzleRequired). 1229 7.3.2.1. Puzzle Requirement 1231 If a node requests a puzzle, then it MUST send a 1232 RequirementPuzzleRequired block. The puzzle requirement is solved if 1233 the node receiving the puzzle is replying with a header block that 1234 contains the puzzle block, and the hash of the encoded block begins 1235 with the bit sequence mentioned in the puzzle within the period 1236 specified in the field 'valid.' 1238 A node solving a puzzle requires sending a VortexMessage to the 1239 requesting node, which MUST contain a header block that includes the 1240 puzzle block and MUST have a MAC fingerprint starting with the bit 1241 sequence as specified in the challenge. The receiving node 1242 calculates the MAC from the unencrypted DER encoded HeaderBlock with 1243 the algorithm specified by the node. The sending node may achieve 1244 the requirement by adding a proofOfWork field to the HeaderBlock 1245 containing any content fulfilling the criteria. The sending node 1246 SHOULD keep the proofOfWork field as short as possible. 1248 7.3.2.2. Payment Requirement 1250 If a node requests a payment, then it MUST send a 1251 RequirementPaymentRequired block. As soon as the requested fee is 1252 paid and confirmed, the requesting node MUST send a "no error" status 1253 message. The usage period 'valid' describes the period during which 1254 the payment may be carried out. A node MUST accept the payment if 1255 occurring within the 'valid' period but confirmed later. A node 1256 SHOULD return all unsolicited payments to the sending address. 1258 7.3.2.3. Upgrade 1260 If a node requests an upgrade a ReplyUpgrade block MAY be sent. The 1261 block must contain the identifier and version of the most recent 1262 software version. The blob MAY contain the software if there is a 1263 newer one available. 1265 7.4. Routing Operations 1267 Routing operations are contained in a routing block and processed 1268 upon arrival of a message or when compiling a new message. All 1269 operations are reversible, and no operation is available for 1270 generating decoy traffic, which may be used through encryption of an 1271 unpadded block or the addRedundancy operation. 1273 All payload chunk blocks inherit the validity time from the message 1274 routing combos as arrival time + max(maxProcessTime). 1276 When applying an operation to a source block, the resulting target 1277 block inherits the expiration of the source block. When multiple 1278 expiration times exist, the one furthest in the future is applied to 1279 the target block. If the operation fails, then the target expiration 1280 remains unchanged. 1282 7.4.1. Mapping Operation 1284 The straightforward mapping operation is used in inOperations of a 1285 routing block to map the routing block's specific blocks to a 1286 permanent workspace. 1288 7.4.2. Split and Merge Operations 1290 The split and merge operations allow splitting and recombining 1291 message chunks. A node MUST adhere to the following constraints. 1293 o The operation must be applied at an absolute (measuring in bytes) 1294 or relative (measured as a float value in the range 0>value>100) 1295 position. 1297 o All calculations must be performed according to IEEE 754 [IEEE754] 1298 and in 64-bit precision. 1300 o If a relative value is a non-integer result, then a floor 1301 operation (i.e., cutting off all non-integer parts) determines the 1302 number of bytes. 1304 o If an absolute value is negative, then the size represents the 1305 number of bytes counted from the end of the message chunk. 1307 o If an absolute value is greater than the number of bytes in a 1308 block, then all bytes are mapped to the respective target block, 1309 and the other target block becomes a zero byte-sized block. 1311 An operation MUST fail if relative values are equal to, or less than, 1312 zero. An operation MUST fail if a relative value is equal to, or 1313 greater than, 100. All floating-point operations must be performed 1314 according to [IEEE754] and in 64-bit precision. 1316 7.4.3. Encrypt and Decrypt Operations 1318 Encryption and decryption are executed according to the standards 1319 mentioned above. An encryption operation encrypts a block 1320 symmetrically and places the result in the target block. The 1321 parameters MUST contain IV, padding, and cipher modes. An encryption 1322 operation without a valid parameter set MUST fail. 1324 7.4.4. Add and Remove Redundancy Operations 1326 The addRedundancy and removeRedundancy operations are core to the 1327 protocol. They may be used to split messages and distribute message 1328 content across multiple routing nodes. The operation is separated 1329 into three steps. 1331 1. Pad the input block to a multiple of the key block size in the 1332 resulting output blocks. 1334 2. Apply a Vandermonde matrix with the given sizes. 1336 3. Encrypt each resulting block with a separate key. 1338 The following sections describe the order of the operations within an 1339 addRedundancy operation. For a removeRedundancy operation, invert 1340 the functions and order. If the removeRedundancy has more than the 1341 required blocks to recover the information, then it should take only 1342 the required number beginning from the smallest. If a seed and PRNG 1343 are provided, then the removeRedundancy operation MAY test any 1344 combination until recovery is successful. 1346 7.4.4.1. Padding Operation 1348 A processing node calculates the final length of all payload blocks, 1349 including redundancy. This is done by L=roof((+4)/)*. The block is prepended with a 32-bit unit length indicator 1352 in bytes (little-endian). This length indicator, i, is calculated by 1353 i=*randominteger\cdot L. The remainder of 1354 the input block, up to length L, is padded with random data. A 1355 routing block builder should specify the value of the 1356 $randomInteger$. If not specified the routing node may choose a 1357 random positive integer value. A routing block builder SHOULD 1358 specify a PRNG and a seed used for this padding. If GF(16) is 1359 applied, then all numbers are treated as little-endian 1360 representations. Only GF(8) and GF(16) are allowed fields. 1362 For padding removal, the padding i at the start is first removed as a 1363 little-endian integer. Second, the length of the output block is 1364 calculated by applying =i mod 1366 This padding guarantees that each resulting block matches the block 1367 size of the subsequent encryption operation and does not require 1368 further padding. 1370 7.4.4.2. Apply Matrix 1372 Next, the input block is organized in a data matrix D of dimensions 1373 (inrows, incols) where incols=(-) and inrows=L/(-). The input block data is first distributed in 1376 this matrix across, and then down. 1378 Next, the data matrix D is multiplied by a Vandermonde matrix V with 1379 its number of rows equal to the incols calculated and columns equal 1380 to the . The content of the matrix is formed 1381 by v(i,j)=pow(i,j), where i reflects the row number starting at 0, 1382 and j reflects the column number starting at 0. The calculations 1383 described must be carried out in the GF noted in the respective 1384 operation to be successful. The completed operation results in 1385 matrix A. 1387 7.4.4.3. Encrypt Target Block 1389 Each row vector of A is a new data block encrypted with the 1390 corresponding encryption key noted in the keys of the 1391 addRedundancyOperation. If there are not enough keys available, then 1392 the keys used for encryption are reused from the beginning after the 1393 final key is used. A routing block builder SHOULD provide enough 1394 keys so that all target blocks may be encrypted with a unique key. 1395 All encryptions SHOULD NOT use padding. 1397 7.5. Processing of Vortex Messages 1399 The accounting layer triggers processing according to the information 1400 contained in a routing block in the workspace. All operations MUST 1401 be executed in the sequence provided in the routing block, and any 1402 failing operation must leave the result block unmodified. 1404 All workspace blocks resulting in IDs of 1 to maxPayloadBlock are 1405 then added to the message and passed to the blending layer with 1406 appropriate instructions. 1408 8. Accounting 1409 8.1. Accounting Operations 1411 The accounting layer has two types of operations. 1413 o Time-based (e.g., cleanup jobs and initiation of routing). 1415 o Routing triggered (e.g., updating quotas, authorizing operations, 1416 and pickup of incoming messages). 1418 Implementations MUST provide sufficient locking mechanisms to 1419 guarantee the integrity of accounting information and the workspace 1420 at any time. 1422 8.1.1. Time-Based Garbage Collection 1424 The accounting layer SHOULD keep a list of expiration times. As soon 1425 as an entry (e.g., payload block or identity) expires, the respective 1426 structure should be removed from the workspace. An implementation 1427 MAY choose to remove expired items periodically or when encountering 1428 them during normal operation. 1430 8.1.2. Time-Based Routing Initiation 1432 The accounting layer MAY keep a list of when a routing block is 1433 activated. For improved privacy, the accounting layer should use a 1434 slotted model where, whenever possible, multiple routing blocks are 1435 handled in the same period, and the requests to the blending layers 1436 are mixed between the transactions. 1438 8.1.3. Routing Based Quota Updates 1440 A node MUST update quotas on the respective operations. For example, 1441 a node MUST decrease the message quota before processing routing 1442 blocks in the workspace and after the processing of header requests. 1444 8.1.4. Routing Based Authorization 1446 The transfer quota MUST be checked and decreased by the number of 1447 data bytes in the payload chunks after an outgoing message is 1448 processed and fully assembled. The message quota MUST be decreased 1449 by one on each routing block triggering the assembly of an outgoing 1450 message. 1452 8.1.5. Ephemeral Identity Creation 1454 Any packet may request the creation of an ephemeral identity. A node 1455 SHOULD NOT accept such a request without a costly requirement since 1456 the request includes a lifetime of the ephemeral identity. The costs 1457 for creating the ephemeral identity SHOULD increase if a longer 1458 lifetime is requested. 1460 9. Acknowledgments 1462 Thanks go to my family who supported me with patience and countless 1463 hours as well as to Mark Zeman for his feedback challenging my 1464 thoughts and peace. 1466 10. IANA Considerations 1468 This memo includes no request to IANA. 1470 Additional encryption algorithms, paddings, modes, blending layers or 1471 puzzles MUST be added by writing an extension to this or a subsequent 1472 RFC. For testing purposes, IDs above 1,000,000 should be used. 1474 11. Security Considerations 1476 The MessageVortex protocol should be understood as a toolset instead 1477 of a fixed product. Depending on the usage of the toolset, anonymity 1478 and security are affected. For a detailed analysis, see 1479 [MVAnalysis]. 1481 The primary goals for security within this protocol rely on the 1482 following focus areas. 1484 o Confidentiality 1486 o Integrity 1488 o Availability 1490 o Anonymity 1492 * Third-party anonymity 1494 * Sender anonymity 1496 * Receiver anonymity 1498 These aspects are affected by the usage of the protocol, and the 1499 following sections provide additional information on how they impact 1500 the primary goals. 1502 The Vortex protocol does not rely on any encryption of the transport 1503 layer since Vortex messages are already encrypted. Also, 1504 confidentiality is not affected by the protection mechanisms of the 1505 transport layer. 1507 If a transport layer supports encryption, then a Vortex node SHOULD 1508 use it to improve the privacy of the message. 1510 Anonymity is affected by the inner workings of the blending layer in 1511 many ways. A Vortex message cannot be read by anyone except the peer 1512 nodes and routing block builder. The presence of a Vortex node 1513 message may be detected through the typical high entropy of an 1514 encrypted file, broken structures of a carrier file, a meaningless 1515 content of a carrier file or the contextless communication of the 1516 transport layer with its peer partner. A blending layer SHOULD 1517 minimize the possibility of simply detection by minimizing these 1518 effects. 1520 A blending layer SHOULD use carrier files with high compression or 1521 encryption. Carrier files SHOULD NOT have inner structures such that 1522 the payload is comparable to valid content. To achieve 1523 undetectability by a human reviewer, a routing block builder should 1524 use F5 instead of PLAIN blending. This approach, however, increases 1525 the protocol overhead by approximately tenfold. 1527 The two layers of 'routing' and 'accounting' have the deepest insight 1528 into a Vortex message's inner working. Each knows the immediate peer 1529 sender and the peer recipients of all payload chunks. As decoy 1530 traffic is generated by combining chunks and applying redundancy 1531 calculations, a node can never know if a malfunction (e.g., during a 1532 recovery calculation) was intended. Therefore, a node is unable to 1533 distinguish a failed transaction from a terminated transaction as 1534 well as content from decoy traffic. 1536 A routing block builder SHOULD follow the following rules not to 1537 compromise a Vortex message's anonymity. 1539 o All operations applied SHOULD be credibly involved in a message 1540 transfer. 1542 o A sufficient subset of the result of an addRedundancy operation 1543 should always be sent to peers to allow recovery of the data 1544 built. 1546 o The anonymity set of a message should be sufficiently large to 1547 avoid legal prosecution of all jurisdictional entities involved, 1548 even if a certain amount of the anonymity set cooperates with an 1549 adversary. 1551 o Encryption and decryption SHOULD follow normal usage whenever 1552 possible by avoiding the encryption of a block on a node with one 1553 key and decrypting it with a different key on the same or adjacent 1554 node. 1556 o Traffic peaks SHOULD be uniformly distributed within the entire 1557 anonymity set. 1559 o A routing block SHOULD be used for a limited number of messages. 1560 If used as a message block for the node, then it should be used 1561 only once. A block builder SHOULD use the 1562 HeaderRequestReplaceIdentity block to update the reply to routing 1563 blocks regularly. Implementers should always remember that the 1564 same routing block is identifiable by its structure. 1566 An active adversary cannot use blocks from other routing block 1567 builders. While the adversary may falsify the result by injecting an 1568 incorrect message chunk or not sending a message, such message 1569 disruptions may be detected by intentionally routing information to 1570 the routing block builder (RBB) node. If the Vortex message does not 1571 carry the information expected, then the node may safely assume that 1572 one of the involved nodes is misbehaving. A block building node MAY 1573 calculate reputation for involved nodes over time and MAY build 1574 redundancy paths into a routing block to withstand such malicious 1575 nodes. 1577 Receiver anonymity is at risk if the handling of the message header 1578 and content is not done with care. An attacker might send a bugged 1579 message (e.g., with a DKIM or DMARC header) to deanonymize a 1580 recipient. Careful attention is required when handling anything 1581 other than local references when processing, verifying, or rendering 1582 a message. 1584 12. References 1586 12.1. Normative References 1588 [CCITT.X208.1988] 1589 International Telephone and Telegraph Consultative 1590 Committee, "Specification of Abstract Syntax Notation One 1591 (ASN.1)", CCITT Recommendation X.208, 11 1998. 1593 [CCITT.X680.2002] 1594 International Telephone and Telegraph Consultative 1595 Committee, "Abstract Syntax Notation One (ASN.1): 1596 Specification of basic notation", 11 2002. 1598 [EAX] Bellare, M., Rogaway, P., and D. Wagner, "The EAX mode of 1599 operation", 2011. 1601 [F5] Westfeld, A., "F5 - A Steganographic Algorithm - High 1602 Capacity Despite Better Steganalysis", 10 2001. 1604 [FIPS-AES] 1605 Federal Information Processing Standard (FIPS), 1606 "Specification for the ADVANCED ENCRYPTION STANDARD 1607 (AES)", 11 2011. 1609 [IEEE754] IEEE, "754-2008 - IEEE Standard for Floating-Point 1610 Arithmetic", 08 2008. 1612 [ISO-10118-3] 1613 International Organization for Standardization, "ISO/IEC 1614 10118-3:2004 -- Information technology -- Security 1615 techniques -- Hash-functions -- Part 3: Dedicated hash- 1616 functions", 3 2004. 1618 [MODES] National Institute for Standards and Technology (NIST), 1619 "Recommendation for Block Cipher Modes of Operation: 1620 Methods and Techniques", 12 2001. 1622 [RFC1423] Balenson, D., "Privacy Enhancement for Internet Electronic 1623 Mail: Part III: Algorithms, Modes, and Identifiers", 1624 RFC 1423, DOI 10.17487/RFC1423, February 1993, 1625 . 1627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1628 Requirement Levels", BCP 14, RFC 2119, 1629 DOI 10.17487/RFC2119, March 1997, 1630 . 1632 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1633 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 1634 2003, . 1636 [RFC3657] Moriai, S. and A. Kato, "Use of the Camellia Encryption 1637 Algorithm in Cryptographic Message Syntax (CMS)", 1638 RFC 3657, DOI 10.17487/RFC3657, January 2004, 1639 . 1641 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 1642 Counter Mode With IPsec Encapsulating Security Payload 1643 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 1644 . 1646 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1647 Specifications: ABNF", STD 68, RFC 5234, 1648 DOI 10.17487/RFC5234, January 2008, 1649 . 1651 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1652 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1653 DOI 10.17487/RFC5288, August 2008, 1654 . 1656 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1657 DOI 10.17487/RFC5958, August 2010, 1658 . 1660 [RFC7253] Krovetz, T. and P. Rogaway, "The OCB Authenticated- 1661 Encryption Algorithm", RFC 7253, DOI 10.17487/RFC7253, May 1662 2014, . 1664 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1665 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1666 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1667 . 1669 [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", 1670 05 2009. 1672 [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 1673 128-Bit Block Cipher, 1st Edition", 03 1999. 1675 [XEP-0231] 1676 Peter, S. and P. Simerda, "XEP-0231: Bits of Binary", 09 1677 2008, . 1679 12.2. Informative References 1681 [DeadParrot] 1682 Houmansadr, A., Burbaker, C., and V. Shmatikov, "The 1683 Parrot is Dead: Observing Unobservable Network 1684 Communications", 2013, 1685 . 1687 [KAnon] Ahn, L., Bortz, A., and N. Hopper, "k-Anonymous Message 1688 Transmission", 2003. 1690 [MVAnalysis] 1691 Gwerder, M., "MessageVortex", 2018, 1692 . 1694 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1695 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 1696 . 1698 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1699 Extensions (MIME) Part One: Format of Internet Message 1700 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1701 . 1703 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1704 RFC 2595, DOI 10.17487/RFC2595, June 1999, 1705 . 1707 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1708 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 1709 . 1711 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1712 DOI 10.17487/RFC5321, October 2008, 1713 . 1715 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1716 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1717 March 2011, . 1719 Appendix A. The ASN.1 schema for Vortex messages 1721 The following sections contain the ASN.1 modules specifying the 1722 MessageVortex Protocol. 1724 A.1. The main VortexMessageBlocks 1726 A.2. The VortexMessage Ciphers Structures 1728 A.3. The VortexMessage Request Structures 1730 A.4. The VortexMessage Replies Structures 1732 A.5. The VortexMessage Requirements Structures 1734 A.6. The VortexMessage Helpers Structures 1736 A.7. The VortexMessage Additional Structures 1737 Author's Address 1739 Martin Gwerder 1740 University of Applied Sciences of Northwestern Switzerland 1741 Bahnhofstrasse 5 1742 Windisch, AG 5210 1743 Switzerland 1745 Phone: +41 56 202 76 81 1746 Email: rfc@messagevortex.net