idnits 2.17.1 draft-gwerder-messagevortexmain-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 29, 2018) is 1973 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '12201' on line 1648 -- Looks like a reference, but probably isn't: '12202' on line 1650 -- Looks like a reference, but probably isn't: '11011' on line 1657 -- Looks like a reference, but probably isn't: '11012' on line 1659 -- Looks like a reference, but probably isn't: '11021' on line 1663 -- Looks like a reference, but probably isn't: '11022' on line 1665 -- Looks like a reference, but probably isn't: '11031' on line 1672 -- Looks like a reference, but probably isn't: '11032' on line 1674 -- Looks like a reference, but probably isn't: '331' on line 1685 -- Looks like a reference, but probably isn't: '332' on line 1687 -- Looks like a reference, but probably isn't: '131' on line 1695 -- Looks like a reference, but probably isn't: '401' on line 1710 -- Looks like a reference, but probably isn't: '402' on line 1712 -- Looks like a reference, but probably isn't: '403' on line 1714 -- Looks like a reference, but probably isn't: '404' on line 1716 -- Looks like a reference, but probably isn't: '405' on line 1718 -- Looks like a reference, but probably isn't: '406' on line 1720 -- Looks like a reference, but probably isn't: '407' on line 1725 -- Looks like a reference, but probably isn't: '408' on line 1727 -- Looks like a reference, but probably isn't: '409' on line 1729 -- Looks like a reference, but probably isn't: '150' on line 1758 -- Looks like a reference, but probably isn't: '160' on line 1759 -- Looks like a reference, but probably isn't: '300' on line 1760 -- Looks like a reference, but probably isn't: '310' on line 1761 -- Looks like a reference, but probably isn't: '400' on line 1762 -- Looks like a reference, but probably isn't: '410' on line 1763 -- Looks like a reference, but probably isn't: '15001' on line 1780 -- Looks like a reference, but probably isn't: '15101' on line 1781 -- Looks like a reference, but probably isn't: '16000' on line 1796 -- Looks like a reference, but probably isn't: '16001' on line 1839 -- Looks like a reference, but probably isn't: '16002' on line 1840 -- Looks like a reference, but probably isn't: '16003' on line 1841 -- Looks like a reference, but probably isn't: '16004' on line 1842 -- Looks like a reference, but probably isn't: '16005' on line 1802 -- Looks like a reference, but probably isn't: '10000' on line 1934 -- Looks like a reference, but probably isn't: '10001' on line 1935 -- Looks like a reference, but probably isn't: '10002' on line 1936 -- Looks like a reference, but probably isn't: '10003' on line 1937 -- Looks like a reference, but probably isn't: '10004' on line 1938 -- Looks like a reference, but probably isn't: '10005' on line 1939 -- Looks like a reference, but probably isn't: '10010' on line 1940 -- Looks like a reference, but probably isn't: '10011' on line 2191 -- Looks like a reference, but probably isn't: '10012' on line 2193 -- Looks like a reference, but probably isn't: '10013' on line 1943 -- Looks like a reference, but probably isn't: '10014' on line 1944 -- Looks like a reference, but probably isn't: '2' on line 2151 -- Looks like a reference, but probably isn't: '3' on line 2152 -- Looks like a reference, but probably isn't: '0' on line 2130 -- Looks like a reference, but probably isn't: '1' on line 2150 -- Looks like a reference, but probably isn't: '4' on line 1989 -- Looks like a reference, but probably isn't: '5' on line 1990 -- Looks like a reference, but probably isn't: '99' on line 1991 -- Looks like a reference, but probably isn't: '10021' on line 2196 -- Looks like a reference, but probably isn't: '10022' on line 2199 -- Looks like a reference, but probably isn't: '100' on line 2205 -- Looks like a reference, but probably isn't: '1001' on line 2219 -- Looks like a reference, but probably isn't: '1002' on line 2221 -- Looks like a reference, but probably isn't: '1003' on line 2224 -- Looks like a reference, but probably isn't: '1004' on line 2225 -- Looks like a reference, but probably isn't: '1005' on line 2226 -- Looks like a reference, but probably isn't: '1006' on line 2227 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 63 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Gwerder 3 Internet-Draft November 29, 2018 4 Intended status: Experimental 5 Expires: June 2, 2019 7 MessageVortex Protocol 8 draft-gwerder-messagevortexmain-00 10 Abstract 12 MessageVortex Protocol specifies messages embedded within existing 13 transfer protocols such as SMTP or XMPP to send them anonymously from 14 peer to peer. 16 The protocol outperforms other protocols by decoupling transport from 17 the final transmitter and receiver party. There is no trust put into 18 any infrastructure except for the infrastructure of the sending and 19 receiving party of a message. The Message flow is entirely selected 20 by the creator of the routing block. Routing nodes gain no non- 21 obvious knowledge about messages even when collaborating. Third- 22 party anonymity is always achieved. Furthermore, one out of sender 23 and receiver anonymity may be achieved. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 2, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 61 1.2. Protocol Specification . . . . . . . . . . . . . . . . . 5 62 1.3. Number Specification . . . . . . . . . . . . . . . . . . 5 63 2. Entities Overview . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Node . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1.1. NodeSpec . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1.1.1. NodeSpec for SMTP nodes . . . . . . . . . . . . . 6 67 2.1.1.2. NodeSpec for XMPP nodes . . . . . . . . . . . . . 6 68 2.2. Peer Partner . . . . . . . . . . . . . . . . . . . . . . 6 69 2.3. Encryption keys . . . . . . . . . . . . . . . . . . . . . 6 70 2.3.1. Identity Keys . . . . . . . . . . . . . . . . . . . . 7 71 2.3.2. Peer Key . . . . . . . . . . . . . . . . . . . . . . 7 72 2.3.3. Sender Key . . . . . . . . . . . . . . . . . . . . . 7 73 2.4. Vortex Message . . . . . . . . . . . . . . . . . . . . . 7 74 2.5. Message . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 2.6. Key and MAC specifications and usages . . . . . . . . . . 8 76 2.6.1. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 9 77 2.6.2. Symmetric Keys . . . . . . . . . . . . . . . . . . . 9 78 2.7. Blocks . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 2.8. Transport Address . . . . . . . . . . . . . . . . . . . . 9 80 2.9. Identity . . . . . . . . . . . . . . . . . . . . . . . . 10 81 2.9.1. Peer Identity . . . . . . . . . . . . . . . . . . . . 10 82 2.9.2. Ephemeral Identity . . . . . . . . . . . . . . . . . 10 83 2.9.3. Official Identity . . . . . . . . . . . . . . . . . . 10 84 2.10. Workspace . . . . . . . . . . . . . . . . . . . . . . . . 10 85 3. Layer Overview . . . . . . . . . . . . . . . . . . . . . . . 11 86 3.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 11 87 3.2. Blending Layer . . . . . . . . . . . . . . . . . . . . . 11 88 3.3. Routing Layer . . . . . . . . . . . . . . . . . . . . . . 12 89 3.4. Accounting Layer . . . . . . . . . . . . . . . . . . . . 12 90 4. Vortex Message . . . . . . . . . . . . . . . . . . . . . . . 12 91 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 92 4.2. Message Prefix Block (MPREFIX) . . . . . . . . . . . . . 13 93 4.3. Inner Message Block . . . . . . . . . . . . . . . . . . . 13 94 4.3.1. Control Prefix Block . . . . . . . . . . . . . . . . 13 95 4.3.2. Control Blocks . . . . . . . . . . . . . . . . . . . 14 96 4.3.2.1. Header Block . . . . . . . . . . . . . . . . . . 14 97 4.3.2.2. Routing Block . . . . . . . . . . . . . . . . . . 14 98 4.3.3. Payload Block . . . . . . . . . . . . . . . . . . . . 15 99 5. General notes . . . . . . . . . . . . . . . . . . . . . . . . 15 100 5.1. Supported Symmetric Ciphers . . . . . . . . . . . . . . . 15 101 5.2. Supported Asymmetric Ciphers . . . . . . . . . . . . . . 15 102 5.3. Supported MACs . . . . . . . . . . . . . . . . . . . . . 16 103 5.4. Supported Paddings . . . . . . . . . . . . . . . . . . . 16 104 5.5. Supported Modes . . . . . . . . . . . . . . . . . . . . . 16 105 6. Blending . . . . . . . . . . . . . . . . . . . . . . . . . . 17 106 6.1. Blending in Attachments . . . . . . . . . . . . . . . . . 17 107 6.1.1. PLAIN embedding into attachments . . . . . . . . . . 17 108 6.1.2. F5 embedding into attachments . . . . . . . . . . . . 17 109 6.2. Blending into an SMTP layer . . . . . . . . . . . . . . . 18 110 6.3. Blending into an XMPP layer . . . . . . . . . . . . . . . 18 111 7. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 112 7.1. Vortex Message Processing . . . . . . . . . . . . . . . . 18 113 7.1.1. Processing of incoming Vortex Messages . . . . . . . 18 114 7.1.2. Processing of Routing Blocks in Workspace . . . . . . 19 115 7.1.3. Processing of Outgoing MessageVortex Messages . . . . 21 116 7.2. Header Requests . . . . . . . . . . . . . . . . . . . . . 21 117 7.2.1. Request New Ephemeral Identity . . . . . . . . . . . 21 118 7.2.2. Request Message Quota . . . . . . . . . . . . . . . . 21 119 7.2.3. Request Increase of Message Quota . . . . . . . . . . 21 120 7.2.4. Request Transfer Quota . . . . . . . . . . . . . . . 22 121 7.2.5. Query Quota . . . . . . . . . . . . . . . . . . . . . 22 122 7.2.6. Request Capabilities . . . . . . . . . . . . . . . . 22 123 7.2.7. Request Nodes . . . . . . . . . . . . . . . . . . . . 22 124 7.2.8. Request Identity Replace . . . . . . . . . . . . . . 23 125 7.3. Special Blocks . . . . . . . . . . . . . . . . . . . . . 23 126 7.3.1. Error Block . . . . . . . . . . . . . . . . . . . . . 23 127 7.3.2. Requirement Block . . . . . . . . . . . . . . . . . . 23 128 7.3.2.1. Puzzle Requirement . . . . . . . . . . . . . . . 24 129 7.3.2.2. Payment Requirement . . . . . . . . . . . . . . . 24 130 7.4. Routing Operations . . . . . . . . . . . . . . . . . . . 24 131 7.4.1. Mapping Operation . . . . . . . . . . . . . . . . . . 25 132 7.4.2. Split and Merge Operations . . . . . . . . . . . . . 25 133 7.4.3. Encrypt and Decrypt Operations . . . . . . . . . . . 25 134 7.4.4. Add and Remove Redundancy Operations . . . . . . . . 25 135 7.4.4.1. Padding Operation . . . . . . . . . . . . . . . . 26 136 7.4.4.2. Apply Matrix . . . . . . . . . . . . . . . . . . 26 137 7.4.4.3. Encrypt Target Block . . . . . . . . . . . . . . 27 138 7.5. Processing of Vortex Messages . . . . . . . . . . . . . . 27 139 8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 27 140 8.1. Accounting Operations . . . . . . . . . . . . . . . . . . 27 141 8.1.1. Time-Based Garbage Collection . . . . . . . . . . . . 27 142 8.1.2. Time-Based Routing Initiation . . . . . . . . . . . . 28 143 8.1.3. Routing Based Quota Updates . . . . . . . . . . . . . 28 144 8.1.4. Routing Based Authorization . . . . . . . . . . . . . 28 145 8.1.5. Ephemeral Identity Creation . . . . . . . . . . . . . 28 146 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 147 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 148 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 149 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 150 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 151 12.2. Informative References . . . . . . . . . . . . . . . . . 33 152 Appendix A. The ASN.1 schema for Vortex messages . . . . . . . . 34 153 A.1. The main VortexMessageBlocks . . . . . . . . . . . . . . 34 154 A.2. The VortexMessage Operation Structures . . . . . . . . . 37 155 A.3. The VortexMessage Ciphers Structures . . . . . . . . . . 39 156 A.4. The VortexMessage Request Structures . . . . . . . . . . 42 157 A.5. The VortexMessage Replies Structures . . . . . . . . . . 43 158 A.6. The VortexMessage Requirements Structures . . . . . . . . 45 159 A.7. The VortexMessage Helpers Structures . . . . . . . . . . 45 160 A.8. The VortexMessage Additional Structures . . . . . . . . . 46 161 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 163 1. Introduction 165 Anonymization is hard to achieve. Most of the attempts in the past 166 rely on either trust in a dedicated infrastructure or a specialized 167 networking protocol. 169 Instead of defining a transport layer, MessageVortex piggybacks on 170 other transport protocols. Messages are being transported alongside 171 ordinary messages of that transport protocol. A blending layer picks 172 the messages up, applies local operations to it and resends the new 173 chunks to the next recipients. 175 A processing node learns as little as possible from the message due 176 to the nature of the operations processed. The onionized structure 177 of the protocol makes it impossible to follow the trace of a message 178 without having control over the processing node itself. 180 MessageVortex is a protocol which allows sending and receiving 181 messages by using a routing block instead of a destination address. 182 The sender has full control over all parameters of the message flow. 184 A message is split and reassembled during transmission. Chunks of 185 the message may carry redundant information to avoid service 186 interruptions of the message transit. Decoy traffic and message 187 traffic are not differentiable as the nature of the addRedundancy 188 operation allows each generated part to be a message part or decoy. 189 Any routing node is thus unable to differentiate between the message 190 and decoy traffic. 192 Any Receiver knows after processing whether a message is destined for 193 it (it creates a chunk with ID 1) or other nodes (processing 194 instructions only). Due to the missing keys, no other node may do 195 this processing. 197 This RFC starts with the general terminology (see Section 2). Next, 198 a general overview of the process is given (see Section 3). Lastly, 199 the subsequent sections describe the details of the protocol. 201 1.1. Requirements Language 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in [RFC2119]. 207 1.2. Protocol Specification 209 Appendix A specifies all relevant parts of the protocol in ASN.1 (see 210 [CCITT.X680.2002] and [CCITT.X208.1988]). The blocks are, if not 211 otherwise mentioned, DER encoded. 213 1.3. Number Specification 215 All numbers within this document are, if not suffixed, decimal 216 numbers. Numbers suffixed with a small letter 'h' followed by two 217 hex digits are octets in hex writing. A blank in ASCII (' ') is 218 written as 20h and a capital 'K' in ASCII as 4Bh. 220 2. Entities Overview 222 Within this document, we refer to the entities as defined below. 224 2.1. Node 226 We use the term 'node' to describe any system connected to other 227 nodes, and supporting the MessageVortex Protocol. A 'node address' 228 is typically an email address, an XMPP address, or any other 229 transport protocol identity supporting the MessageVortex protocol. 230 Any address SHOULD include a public part of an 'identity key' 231 allowing to transmit messages safely. One or more addresses MAY 232 belong to the same node. 234 2.1.1. NodeSpec 236 Every addressable node is addressed in a unified format stored in a 237 nodeSpec block. This RFC specifies transport layers for XMPP and 238 SMTP. Adding transport layers requires to write an extension to this 239 RFC. 241 2.1.1.1. NodeSpec for SMTP nodes 243 Typically a node specification is specified with the ASN.1 block 244 NodeSpec (see Appendix A.7). To allow addressing of a vortex node 245 with an ordinary client an alternative representation SHOULD be 246 supported as defined below as smtpAlternateSpec (specification noted 247 in ABNF as specified in [RFC5234]). 249 localPart = 250 domain = 251 email = localPart "@" domain 252 keySpec = ; 253 smtpAlternateSpec = localPart ":" keySpec "@" domain 255 2.1.1.2. NodeSpec for XMPP nodes 257 Typically a node specification is specified with the ASN.1 block 258 NodeSpec. To allow addressing of a vortex node with an ordinary 259 client, an alternative representation SHOULD be supported as defined 260 below as jidAlternateSpec (specification noted in ABNF as specified 261 in [RFC5234]). 263 localPart = 264 domain = 265 jid = localPart "@" domain [ "/" resourcepart ] 266 keySpec = ; 267 jidAlternateSpec = localPart ":" keySpec "@" domain [ "/" resourcepart 269 Please note that the ":" character (3Ah) is explicitly excluded in 270 [RFC7622] in the localpart. 272 2.2. Peer Partner 274 We use the term 'peer partner' as two or more message sending or 275 receiving entities. One of these peer partners sends a message, and 276 all other peer partners receive one or more messages. Peer partners 277 are message specific. Every peer partner always connects directly to 278 a node. 280 2.3. Encryption keys 282 There are several keys required for a Vortex message. For identities 283 and ephemeral identities (see below) we use asymmetric keys. For 284 message encryption, we use symmetric keys. 286 2.3.1. Identity Keys 288 Every participant of the network has an asymmetric key. These keys 289 SHOULD be either EC keys with a minimum length of 384 bits or RSA 290 keys with a minimum length of 2048 bits. 292 The public key needs to be known by all parties writing to or through 293 that node. 295 2.3.2. Peer Key 297 Peer keys are symmetrical keys transmitted with a Vortex message. 298 Peer keys are always known to the node sending a message, the node 299 receiving the message from the sender, and to the creator of the 300 routing block. 302 A peer key is included in the identity block of a Vortex message and 303 in the building instructions for a Vortex message (see RoutingCombo 304 in Appendix A). 306 2.3.3. Sender Key 308 The sender key is a symmetrical key protecting the identity and 309 routing block of a Vortex message. It is encrypted with the 310 receiving peer key and prefixed to the identity block. This key 311 decouples further identity and processing information from the 312 previous key. 314 A sender key is known to precisely one peer of a Vortex message and 315 the creator of the routing block. 317 2.4. Vortex Message 319 We use the term 'Vortex message' for a single transmission between 320 two routing layers. A 'blended Vortex message' describes a Vortex 321 message which has been adapted to the transport layer by the blending 322 layer (see Section 3). 324 A full vortex message contains the following items: 326 o The peer key (encrypted with the host key of the node; stored in a 327 PrefixBlock) protecting the inner Vortex message 328 (innerMessageBlock). 330 o The small padding guarantees that a replayed routing block with 331 different content does not look alike. 333 o The sender key (encrypted with the host key of the node) 334 protecting the identity and routing block. 336 o The identity block (protected by the sender key) containing 337 information about the ephemeral identity of the sender, replay 338 protection information, header requests (optional) and a 339 requirement reply (optional). 341 o The routing block (protected by the sender key) containing 342 information on how subsequent messages are processed, assembled 343 and blended. 345 o The payload block (protected by the peer key) contains payload 346 chunks for processing. 348 2.5. Message 350 A Message is a content to be transmitted from one sender to the 351 recipient. The Sender uses a routing block to achieve this which is 352 either built by him or provided by the receiver. A Message may be 353 anonymous. There are however different degrees of anonymity: 355 o If the sender of a message is not known to anyone else except the 356 sender, we refer to that as 'sender anonymity.' 358 o If the receiver of a message is not known to anyone else except 359 the receiver, we refer to that as 'receiver anonymity.' 361 o If an attacker is unable to determine content, original sender, 362 and final receiver, we refer to that as third-party anonymity. 364 o If a sender or a receiver may be determined as "one of a set of 365 entities we refer to it as k-anonymity (for more about this 366 see [KAnon]). 368 A message is always MIME encoded as specified in [RFC2045]. 370 2.6. Key and MAC specifications and usages 372 MessageVortex uses a unique encoding for keys. It is designed to be 373 small and flexible while maintaining a specific base structure. 375 The following key structures exist: 377 o SymmetricKey 379 o AsymmetricKey 380 MAC does not need a complete structure containing specs and value. 381 Instead only a MacAlgorithmSpec is available. The following sections 382 outline the constraints when specifying parameters for these 383 structures. A node MUST NOT specify any parameter more than once. 385 If a crypto mode is specified requiring an IV, a node MUST provide 386 the IV when specifying the key. 388 2.6.1. Asymmetric Keys 390 Nodes use asymmetric keys for identifying peer nodes (identities) and 391 encrypting symmetric keys (for later de-/encryption of payload or 392 blocks). All asymmetric keys MUST contain a key type specifying a 393 strictly normed key. They MUST contain a public part of the key 394 encoded as X.509 container and a private key as specified in PKCS#8 395 wherever possible. 397 RSA and EC keys must contain a keysize parameter. All asymmetric 398 keys SHOULD contain a padding parameter. A node SHOULD assume PKCS#1 399 if no padding is specified. 401 NTRU specification MUST provide parameters "n", "p", and "q". 402 McEliece specification MUST contain parameters "n", "k", and "t". 404 2.6.2. Symmetric Keys 406 Nodes use symmetric keys for encrypting payload and control blocks. 407 All symmetric keys MUST contain a key type specifying a strictly 408 normed key. They MUST contain a key encoded. 410 A node MUST provide a keysize parameter if the key (or equivalently 411 block) size is not standardized or encoded in the name. All 412 symmetric key specification MUST contain a mode and padding 413 parameter. A node MAY list multiple padding or mode parameters in a 414 ReplyCapability block to give the recipient a free choice. 416 2.7. Blocks 418 We use the term 'block' for an ASN.1 sequence in a transmitted 419 message. We embed messages in the transport protocol. It may have 420 any size. 422 2.8. Transport Address 424 We use the term 'transport address' for the token required to address 425 the next immediate node on the transport layer. An email transport 426 layer would have SMTP addresses such as 'vortex@example.com' as 427 transport address. 429 2.9. Identity 431 2.9.1. Peer Identity 433 The peer identity may contain the following information of a peer 434 partner: 436 o A transport address (always) and the public key of this identity 437 (given there is no recipient anonymity) 439 o The routing blocks for contacting the identity (optional; this 440 block is only required in the case of recipient anonymity) 442 o The private key (only known by the owner of the identity) 444 2.9.2. Ephemeral Identity 446 Ephemeral identities are temporary identities created on a single 447 node. These identities MUST NOT relate to any other identity. They 448 allow bookkeeping for a node. To each ephemeral identity is a 449 workspace assigned. Every ephemeral identity may have multiple 450 quotas assigned. 452 2.9.3. Official Identity 454 An official identity may have the following items assigned: 456 o Routing blocks to be used to reply to the node. 458 o A list of assigned ephemeral identities on all other nodes and 459 their projected quotas. 461 o A list of known nodes and the respective node identity 463 2.10. Workspace 465 Every official or ephemeral identity has a workspace. A workspace 466 consists of the following elements: 468 o Zero or more routing blocks to be processed 470 o Slots for payload block sequentially numbered. Every slot... 472 * MUST contain a numerical ID identifying the slot 474 * MAY contain a payload content 475 * If a block contains a payload, it MUST contain a validity 476 period. 478 3. Layer Overview 480 The protocol is designed in four layers as shown in Figure 1 482 +-------------------------------------------------------------------+ 483 | Vortex Node | 484 | +---------------------------------------------------------------+ | 485 | | Accounting | | 486 | |_______________________________________________________________| | 487 | | 488 | +---------------------------------------------------------------+ | 489 | | Routing | | 490 | |_______________________________________________________________| | 491 | | 492 | +----------------------------+ +--------------------------------+ | 493 | | Blending | | Blending | | 494 | |____________________________| |________________________________| | 495 |___________________________________________________________________| 496 +----------------------------+ +--------------+ +---------------+ 497 | Transport | | Transport in | | Transport out | 498 |____________________________| |______________| |_______________| 500 Figure 1: Layer overview 502 Every participating node MUST implement the layers blending, routing, 503 and accounting. There MUST be at least one incoming and one outgoing 504 transport layer available to a node. All blending layers SHOULD 505 connect to respective Transport layers for sending and receiving 506 packets. 508 3.1. Transport Layer 510 The transport layer embeds the blended MessageVortex packets into the 511 data stream of the existing transport layer protocol. 513 The transport layer infrastructure SHOULD NOT be specific to 514 anonymous communication and should contain significant parts of non- 515 MessageVortex traffic. 517 3.2. Blending Layer 519 The blending layer embeds MessageVortex packets into the transport 520 layer data stream and extracts MessageVortex packets from the 521 transport layer. 523 3.3. Routing Layer 525 The Routing Layer expands information contained in MessageVortex 526 packets, processes them, and passes generated packets to the 527 respective Blending Layer. 529 3.4. Accounting Layer 531 The accounting layer keeps track of all ephemeral identities 532 authorized to use a MessageVortex node. Especially it verifies the 533 available quotas to an ephemeral identity. 535 4. Vortex Message 537 4.1. Overview 539 Figure 2 shows a Vortex message. The enclosed sections denote 540 encrypted blocks. The three to four letter abbreviations denote the 541 key required for decryption. The abbreviation k_h stands for the 542 asymmetric host key. sk_p is the symmetric peer key. The receiving 543 node obtains this key by decrypting MPREFIX with its host key k_h. 544 sk_s is the symmetric sender key. When decrypting the MPREFIX block, 545 the node obtains this key. The sender key protects the header and 546 the routing blocks. This key guarantees that the node assembling the 547 message does not know about upcoming identities, operations, and 548 requests. The peer key protects the message including structure from 549 any third party observer. 551 +-+---+-+-+---+-+---+-+-+---+-+-+---+-+-------+-+ 552 | | | | | | | C | | | | | | R | | | | 553 | | | | | | | P | | | H | | | O | | | | 554 | | M | | | P | | R | | | E | | | U | | P | | 555 | | P | | | A | | E | | | A | | | T | | A | | 556 | | R | | | D | | F | | | D | | | I | | Y | | 557 | | E | | | D | | I | | | E | | | N | | L | | 558 | | F | | | I | | X | | | R | | | G | | O | | 559 | | I | | | N | +---+ | |___| | |___| | A | | 560 | | X | | | G | k_h | sk_s | sk_s | D | | 561 | |___| | |___|_______|_______|_______|_______| | 562 | k_h | sk_p | 563 |_______|_______________________________________| 565 Figure 2: Vortex message overview 567 4.2. Message Prefix Block (MPREFIX) 569 The PrefixBlock contains a symmetrical key as defined in Appendix A.1 570 and is encrypted using the host key of the receiving peer host. The 571 symmetric key used MUST be one out of the set advertised by a 572 CapabilitiesReplyBlock (see Section 7.2.6). A node MAY choose any 573 parameters omitted in the CapabilitiesReplyBlock freely (unless 574 stated otherwise in Section 7.2.6). A node SHOULD avoid sending 575 unencrypted PrefixBlocks. A prefix block MUST contain the same 576 forward-secret as the other prefix, the routing block, and the header 577 block. A host MAY reply to a message with an unencrypted message 578 block. Any reply to a message SHOULD be encrypted. 580 The sender MUST choose a key which may be encrypted with the host key 581 using the padding advertised by the CapabilitiesReplyBlock. 583 4.3. Inner Message Block 585 A node MUST always encrypt (with the symmetric key of the 586 PrefixBlock) an InnerMessageBlock. The encryption hides the inner 587 structure of the message. The InnerMessageBlock SHOULD always 588 accommodate four or more payload chunks. 590 An InnerMessageBlock always starts with a padding block. This 591 padding guarantees that when using the same routing block multiple 592 times, its binary structure is not repeated throughout the messages 593 with the same routing block. The padding MUST be the first 16 bytes 594 of the first four non-empty payload chunks (PayloadChunks). If a 595 payload chunk is shorter than 16 bytes, the content of the padding 596 SHOULD be filled with zero-valued bytes (00h) at very end up to the 597 required number of bytes. An inner message block (InnerMessageBlock) 598 SHOULD contain at least four payload chunks sized 16 bytes or bigger. 599 If there are less than four payload chunks, then the padding MUST 600 contain a random sequence of 16 bytes for the missing payload chunks. 601 A node MUST NOT reuse random sequences. 603 An InnerMessageBlock contains so-called forwardSecrets. This random 604 number MUST be the same in the HeaderBlock, the RoutingBlock, and the 605 PrefixBlock. Nodes receiving Messages containing non-matching 606 forwardSecrets MUST discard these messages, and SHOULD NOT send an 607 error message. 609 4.3.1. Control Prefix Block 611 Control prefix block (CPREFIX) and MPREFIX block share the same 612 structure and logic. It contains the sender key sk_s. If an MPREFIX 613 block was unencrypted, a node MAY omit the CPREFIX block. An omitted 614 CPREFIX block results in unencrypted control blocks (HeaderBlock and 615 RoutingBlock). 617 A prefix block MUST contain the same forwardSecret as the other 618 prefix, the routing block, and the header block. 620 4.3.2. Control Blocks 622 The control blocks contain the core information to process the 623 payload. It contains a HeaderBlock and a RoutingBlock. 625 4.3.2.1. Header Block 627 The header block (see HeaderBlock in Appendix A) contains the 628 following information: 630 o It MUST contain the local ephemeral identity of the routing block 631 builder. 633 o It MAY contain header requests. 635 o It MAY contain the solution to a PuzzleRequired block previously 636 opposed in a header request. 638 The list of header requests MAY one of the following: 640 o be empty 642 o contain a single identity create request (HeaderRequestIdentity) 644 o contain a single increase quota request 646 If a header block violates these rules, then a node MUST NOT reply to 647 any header requests. Payload and routing blocks SHOULD still be 648 added to the workspace and processed, given the message quota is not 649 exceeded. 651 4.3.2.2. Routing Block 653 The routing block (see RoutingBlock in Appendix A) contains the 654 following information: 656 o It MUST contain a serial number uniquely identifying the routing 657 block of this user. A serial number MUST be unique during the 658 lifetime of a routing block. 660 o It MUST contain the same forward secret as the two prefix blocks 661 and the header block. 663 o It MAY contain assembly and processing instructions for subsequent 664 messages. 666 o It MAY contain a reply block for messages assigned to the owner of 667 the identity. 669 4.3.3. Payload Block 671 Each InnerMessageBlock containing routing information SHOULD contain 672 at least four PayloadChunks. 674 5. General notes 676 The MessageVortex protocol is a modular protocol. It allows using 677 different encryption algorithms. For operation, a Vortex node SHOULD 678 always support at least two completely different (i.e. relying on two 679 different mathematical problems) types of algorithms, paddings, or 680 modes. 682 5.1. Supported Symmetric Ciphers 684 A node MUST support the following symmetric ciphers: 686 o AES128 (see [FIPS-AES] for AES implementation details) 688 o AES256 690 o CAMELLIA128 (see [RFC3657] chapter 3 for Camellia implementation 691 details) 693 o CAMELLIA256 695 A node SHOULD support any standardized, bigger key size than the 696 smallest key. 698 A node MAY support Twofish ciphers (see [TWOFISH]). 700 5.2. Supported Asymmetric Ciphers 702 A node MUST support the following asymmetric ciphers: 704 o RSA (key sizes bigger or equal to 2048) ([RFC8017]) 706 o ECC (named curves secp384r1, sect409k1, secp521r1) (see [SEC1]) 708 5.3. Supported MACs 710 A node MUST support the following Message Authentication Codes (MAC): 712 o SHA256 (see [ISO-10118-3] for SHA implementation details) 714 o RipeMD160 (see [ISO-10118-3] for RIPEMD implementation details) 716 A node SHOULD support the following MACs: 718 o SHA512 720 o RipeMD256 722 o RipeMD512 724 5.4. Supported Paddings 726 A node MUST support the following paddings specified in [RFC8017]: 728 o PKCS1 (see [RFC8017]) 730 o PKCS7 (see [RFC5958]) 732 5.5. Supported Modes 734 A node MUST support the following modes: 736 o CBC (see [RFC1423]). The used IV must be of equal length as the 737 key) 739 o EAX (see [EAX]) 741 o GCM (see [RFC5288]) 743 o NONE (only used in special cases. See Section 11) 745 A node SHOULD NOT use the following modes: 747 o NONE (Except as stated when using the addRedundancy function 749 o ECB 751 A node SHOULD support the following modes: 753 o CTR ([RFC3686]) 755 o CCM ([RFC3610]) 756 o OCB ([RFC7253]) 758 o OFB ([MODES]) 760 6. Blending 762 Each node supports a fixed set of blending capabilities. They may be 763 different for incoming and outgoing messages. 765 The following sections describe the blending mechanism. There are 766 currently two blending layers specified. One layer specification for 767 the simple mail transfer protocol (SMTP; See [RFC5321]) and one for 768 the Extensible Messaging and Presence Protocol (XMPP; See [RFC6120]). 770 6.1. Blending in Attachments 772 There are two types of blending supported when using attachments. 774 o Plain binary encoding with offset (PLAIN) 776 o Embedding with F5 in an image (F5) 778 A node MUST support PLAIN blending for reasons of interoperability. 779 A node MAY support blending using F5. 781 6.1.1. PLAIN embedding into attachments 783 A blending layer embeds a VortexMessage in a carrier file with an 784 offset for PLAIN blending. For replacing a file start, a node MUST 785 use the offset 0. The routing node MUST choose the payload file for 786 the message. A routing node SHOULD use a credible payload type 787 (e.g., MIME type) with high entropy. It furthermore SHOULD prefix a 788 valid header structure to avoid easy detection of the Vortex message. 789 A routing node SHOULD use a valid footer, if any, to a payload file 790 to improve blending. 792 A node SHOULD offer at least one PLAIN blending method for incoming 793 Vortex messages. A node may offer multiple offsets for incoming 794 Vortex messages. 796 6.1.2. F5 embedding into attachments 798 For F5, a blending layer embeds a VortexMessage into a jpeg file 799 according to [F5]. The password for blending may be publicly known. 800 A routing node MAY advertise multiple passwords. The use of F5 adds 801 roughly a tenfold of transfer volume to the message. A routing block 802 building node SHOULD only use F5 blending where appropriate. 804 6.2. Blending into an SMTP layer 806 Email messages containing messages MUST be encoded with Multipurpose 807 Internet Mail Extensions (MIME) as specified in [RFC2045]. All nodes 808 MUST support BASE64 encoding. A node MUST test all sections of a 809 MIME message for the presence of a VortexMessage. 811 A vortex message is present if a block containing the peer key at the 812 known offset of any MIME part decodes correctly. 814 A node SHOULD support SMTP blending for sending and receiving. For 815 sending SMTP as specified in [RFC5321] must be used. TLS layers MUST 816 always be applied when obtaining messages using POP3 (as specified in 817 [RFC1939] and [RFC2595]) or IMAP (as specified in [RFC3501]). Any 818 SMTP connection MUST employ a TLS encryption when passing any 819 credentials. 821 6.3. Blending into an XMPP layer 823 For interoperability, an implementation SHOULD provide XMPP blending. 825 Blending into XMPP traffic is done using the [XEP-0234] extension of 826 the XMPP protocol. 828 PLAIN and F5 blending is acceptable for this transport layer. 830 7. Routing 832 7.1. Vortex Message Processing 834 7.1.1. Processing of incoming Vortex Messages 836 An incoming message is considered unauthenticated at first. A node 837 should consider a VortexMessage as authenticated as soon as the 838 ephemeral identity is known and is not temporary. 840 For an unauthenticated message the following rules apply: 842 o A node MUST ignore all Routing blocks. 844 o A node MUST ignore all Payload blocks. 846 o A node SHOULD accept identity creation requests in unauthenticated 847 messages. 849 o A node MUST ignore any other header request except identity 850 creation requests. 852 o A node MUST ignore all identity creation requests which belong to 853 an already existing identity. 855 A message is considered authenticated as soon as the identity used in 856 the header block is known and not temporary. A node MUST NOT treat a 857 message as authenticated if the specified maximum number of replays 858 have been reached. For authenticated messages the following rules 859 apply: 861 o A node MUST ignore identity creation requests. 863 o A node MUST replace the current reply block with the reply block 864 provided in the routing block (if any). The node MUST keep the 865 reply block if no reply block is provided. 867 o A node SHOULD process all header requests. 869 o A node SHOULD add all routing blocks to the workspace. 871 o A node SHOULD add all payload blocks to the workspace. 873 A routing node MUST decrement the message quota by one if a received 874 message is authenticated and contains at least one payload block. If 875 a message is identified as duplicate acording to the reply 876 protection, a node MUST NOT decrement the message quota. 878 7.1.2. Processing of Routing Blocks in Workspace 880 A routing workspace consists of the following items: 882 o The identity linked to it (This determines the lifetime of the 883 workspace). 885 o The routing combos (RoutingCombo) linked to it. 887 o A payload chunk space. Multiple subspaces are available within 888 this space: 890 * ID 0 represents a message to be embedded (when reading) or a 891 message to be extracted to the user (when written). 893 * ID 1 to ID maxPayloadBlocks represents the payload chunk slots 894 in the target message. 896 * All blocks between ID maxPayloadBlocks+1 to ID 32767 belong to 897 a temporary routing block specific space. 899 * All blocks between ID 32768 to ID 65535 belong to a shared 900 space available to all operations of this identity. 902 The accounting layer typically triggers processing. It represents 903 either a cleanup action or a routing event. A cleanup event deletes 904 the following information from all workspaces: 906 o All processed routing combos. 908 o All routing combos with expired usagePeriod. 910 o All payload chunks when exceeded their maxProcess time. 912 o All expired objects. 914 o All expired puzzles. 916 o All expired identities. 918 o All expired replay protections. 920 Note that maxProcessTime reflects the number of seconds since the 921 arrival of the last octet of the message at the transport layer 922 facility. A node SHOULD NOT take additional processing time (e.g., 923 for anti-UBE or anti-virus) into account. 925 The accounting layer triggers routing events. The trigger occurs at 926 least minProcessTime after the last octet of the message arrived at 927 the routing layer. A node SHOULD choose the latest possible moment 928 in such a way that the peer node receives the last octet of the 929 assembled message before maxProcessTime is reached. The calculation 930 of the last point in time where a message may be set SHOULD always 931 assume that the target node is working. A sending node SHOULD choose 932 the time within these bounds randomly. An accounting layer MAY 933 trigger multiple routing combos in bulk to further obfuscate identity 934 of a single transport message. 936 First, the processing node escapes the payload chunk at ID 0 if 937 needed (non-special block starting with a backslash). Next, it 938 executes all processing instructions of a routing combo in the 939 sequence specified. If an instruction fails, the block at the target 940 ID of the operation remains unchanged. The routing layer proceeds 941 with the subsequent processing instructions, ignoring the error. For 942 a detailed description of the operations see Section 7.4. If a node 943 succeeds in building at least one payload chunk, a VortexMessage is 944 composed and passed to the blending layer. 946 7.1.3. Processing of Outgoing MessageVortex Messages 948 The blending layer MUST then compose a transport layer message 949 according to the specification provided in the routing combo. It 950 SHOULD choose any decoy message or steganographic carrier in such a 951 way that the dead parrot syndrome as specified in [DeadParrot] is 952 avoided. 954 7.2. Header Requests 956 Header requests are control requests for the anonymization system. 957 Messages with requests or replies only MUST NOT affect any quota. 959 7.2.1. Request New Ephemeral Identity 961 Requesting a new ephemeral identity is done by sending a message 962 containing a header block with the new identity and an identity 963 creation request (HeaderRequestIdentity) to a node. The node MAY 964 send an error block (see Section 7.3.1) if rejecting the request. 966 If a node accepts an identity creation request, it MUST send a reply. 967 To accept a request without a requirement, an accepting node MUST 968 send back a special block containing "no error". To accept a block 969 with a requirement, an accepting node MUST send a special block 970 containing a requirement block. 972 7.2.2. Request Message Quota 974 Any valid ephemeral identity may request to raise the current message 975 quota to a specific value at any time. The request MUST include a 976 reply block in the header. The request may contain other parts. If 977 a requested value is lower than the current quota, the node SHOULD 978 NOT refuse the quota request and SHOULD send a "No Error" status. 980 A node SHOULD reply to a HeaderRequestIncreaseMessageQuota request 981 (see Appendix A) of a valid ephemeral identity. The reply MUST 982 include a requirement, an error message or a "No Error" status 983 message. 985 7.2.3. Request Increase of Message Quota 987 A node may request to increase the current message quota. The 988 increase is requested by sending a HeaderRequestIncreaseMessageQuota 989 request to the routing node. The value specified within the node is 990 the new quota. HeaderRequestIncreaseMessageQuota requests MUST 991 include a reply block. A node SHOULD NOT use a previously sent MURB 992 to reply. 994 If the requested quota is higher than the current quota, then the 995 node SHOULD send a "no error" reply. If the requested quota is not 996 accepted, the node SHOULD send a requestedQuotaOutOfBand reply. 998 A node accepting the request MUST send a RequirementBlock or a "no 999 error block". 1001 7.2.4. Request Transfer Quota 1003 Any valid ephemeral identity may request to raise the current 1004 transfer quota to a specific value at any time. The request MUST 1005 include a reply block in the header. The request may contain other 1006 parts. If a requested value is lower than the current quota, the 1007 node SHOULD NOT refuse the quota request and SHOULD send a "No Error" 1008 status. 1010 A node SHOULD reply to a HeaderRequestIncreaseTransferQuota request 1011 (see Appendix A) of a valid ephemeral identity. The reply MUST 1012 include a requirement, an error message, or a "No Error" status 1013 message. 1015 7.2.5. Query Quota 1017 Any valid ephemeral identity may request the current message and 1018 transfer quota. The request MUST include a reply block in the 1019 header. The request may contain other parts. 1021 A node MUST reply to a HeaderRequestQueryQuota request (see 1022 Appendix A). The reply MUST include the current message quota and 1023 the current message transfer quota. The reply to this request MUST 1024 NOT include a requirement. 1026 7.2.6. Request Capabilities 1028 Any node MAY request the capabilities of another node. The 1029 capabilities include all information necessary to create a parseable 1030 VortexMessage. Any node SHOULD reply to any encrypted 1031 HeaderRequestCapability. 1033 7.2.7. Request Nodes 1035 A node may ask another node for a list of routing node addresses and 1036 keys. This request may be used to bootstrap a new node and to add 1037 routing nodes increasing the anonymization of a node. The receiving 1038 node of such a request SHOULD reply with a requirement (e.g., 1039 RequirementPuzzleRequired). 1041 A node SHOULD reply to a HeaderRequest request (see Appendix A) of a 1042 valid ephemeral identity. The reply MUST include a requirement, an 1043 error message or a "No Error" status message. 1045 7.2.8. Request Identity Replace 1047 This request allows a receiving node to replace an identity with the 1048 identity provided in the message. This request is required if an 1049 adversary managed to deny the usage of a node (e.g., by deleting the 1050 corresponding transport account). Any sending node may recover from 1051 such an attack by sending a validly authenticated message to another 1052 identity providing the new transport and key details. 1054 A node SHOULD reply to a such a request of a valid known identity. 1055 The reply MUST include an error message or a "No Error" status 1056 message. 1058 7.3. Special Blocks 1060 Special blocks are payload messages. They reflect messages from one 1061 node to another and are not visible to the user. A special block 1062 starts with the character sequence '\special' (or 5Ch 73h 70h 65h 63h 1063 69h 61h 6Ch) followed by a DER encoded special block (SpecialBlock). 1064 Any non-special message decoding to ID 0 in a workspace starting with 1065 a backslash (5Ch) MUST escape all backslashes within the payload 1066 chunk with an additional backslash. 1068 7.3.1. Error Block 1070 An error block may be sent as a reply where specified as a payload. 1071 The error block is embedded in a special block and sent with any 1072 provided reply block. Error messages SHOULD contain the serial 1073 number of the offending header block and MAY contain a human-readable 1074 text providing additional messages about the error. 1076 7.3.2. Requirement Block 1078 If a node is receiving a requirements block, it MUST assume that the 1079 request block has been accepted, has not been processed yet, and will 1080 be processed if the contained requirement is met. A node MUST 1081 process a request as soon as the requirement is fulfilled. A node 1082 MUST resend the request as soon as the requirement is met. 1084 A node MAY reject a request, accept a request without a requirement, 1085 accept a request upon payment (RequirementPaymentRequired), or accept 1086 a request upon solving a proof of work puzzle 1087 (RequirementPuzzleRequired). 1089 7.3.2.1. Puzzle Requirement 1091 If a node requests a puzzle, it MUST send a RequirementPuzzleRequired 1092 block. The puzzle requirement is solved, if the node receiving the 1093 puzzle is replying with a header block containing the puzzle block 1094 and the hash of the encoded block starts with the bit sequence 1095 mentioned in the puzzle within the period specified in the field 1096 'valid'. 1098 To solve a puzzle posed by a node a Vortex Message needs to be sent 1099 to the requesting node. This Vortex Message MUST contain a header 1100 block which includes the puzzle block and MUST have a MAC fingerprint 1101 starting with the bit sequence as specified in the challenge. A node 1102 calculates the MAC from the unencrypted DER encoded HeaderBlock with 1103 the algorithm specified by the node. To meet this requirement, a 1104 node adds a proofOfWork field to the HeaderBlock. 1106 7.3.2.2. Payment Requirement 1108 If a node requests a payment, it MUST send a 1109 RequirementPaymentRequired block. As soon as the requested fee is 1110 paid and confirmed, the requesting node MUST send a "No Error" status 1111 message. The usage period 'valid' describes the period in which the 1112 payment may be carried out. A node MUST accept the payment if 1113 carried out within the 'valid' period but confirmed later. A node 1114 SHOULD return allunsolicited payments to the sending address. 1116 7.4. Routing Operations 1118 Routing operations are contained in a routing block and processed 1119 either on arrival on a message or when a compiling new message. All 1120 Operations are reversible. No Operation is available for generating 1121 decoy traffic. For decoy traffic, either encryption of an unpadded 1122 block may be used, or the addRedundancy operation. 1124 All payload chunk blocks inherit the validity time from the message 1125 routing combos (arrival time + max(maxProcessTime)). 1127 When applying an operation to a source block, the resulting target 1128 block inherits the expiry of the of the source block. When having 1129 multiple different expiry times, the expiry the furthest in the 1130 future will be applied to the target block. If the operation fails, 1131 the target expiry remains unchanged. 1133 7.4.1. Mapping Operation 1135 A mapping operation is a straightforward operation mainly used in 1136 inOperations of a routing block to map the routing block specific 1137 blocks to a permanent workspace. 1139 7.4.2. Split and Merge Operations 1141 The split and merge operations allow splitting and recombining 1142 message chunks. A node MUST adhere to these constraints: 1144 o The operation must be applied at an absolute (measuring in bytes) 1145 or relative (measured as a float value in the range 0>value>100) 1146 position. 1148 o All calculations must be done according to IEEE 754 [IEEE754] and 1149 in 64 Bit precision. 1151 o If a relative value is a non-integer result, a floor operation 1152 (cutting off all non-integer parts) determines the number of 1153 bytes. 1155 o If an absolute value is negative, the size reflected applies to 1156 the number of bytes counted from the end of the message chunk. 1158 o If an absolute value is bigger than the number of bytes in a 1159 block, all bytes are mapped to the respective target block, and 1160 the other target block becomes a zero byte sized block. 1162 An operation MUST fail if relative values are equal to, or below 1163 zero. An operation MUST fail if a relative value is equal to or 1164 above 100. All floating point operations must be carried out 1165 according to [IEEE754] and in 64-bit precision. 1167 7.4.3. Encrypt and Decrypt Operations 1169 Encryption and decryption are executed according to the standards 1170 mentioned before. An encryption operation encrypts a block 1171 symmetrically and places the result in the target block. The 1172 parameters MUST contain required parameters such as IV, padding, or 1173 cipher modes. An encryption operation without a valid parameter set 1174 MUST fail. 1176 7.4.4. Add and Remove Redundancy Operations 1178 The addRedundancy and removeRedundancy operations are the core 1179 operations of the protocol. They may be used to split messages and 1180 distribute message content across multiple routing nodes. The 1181 operation is split into three steps. 1183 1. Pad the input block to a multiple of the key block size in the 1184 resulting output blocks. 1186 2. Apply a Vandermonde matrix with the given sizes. 1188 3. Encrypt each resulting block with a separate key. 1190 The following sections describe the order of the operations in an 1191 addRedundancy operation. For a removeRedundancy operation invert the 1192 functions and order. 1194 7.4.4.1. Padding Operation 1196 First, the length of all output blocks including redundancy is 1197 calculated. This is done by L=roof((+4)/)*. 1199 The block is prepended with a 32-bit length indicator in bytes at the 1200 beginning (little-endian). This length indicator i is calculated by 1201 i=*randominteger()*L. The rest of the 1202 input block up to length L is padded with random data. If GF(16) is 1203 applied, numbers are treated as little-endian representations. 1205 For padding removal, first, the padding i at the start is removed as 1206 a little-endian integer. Then, the length of the output block is 1207 calculated by applying =i mod 1210 This padding guarantees that each resulting block is as big as the 1211 subsequent encryption operation and does not require any further 1212 padding. 1214 7.4.4.2. Apply Matrix 1216 Next, the input block is organized in a data matrix D of dimensions 1217 inrows,incols where incols=(-) and inrows=L/(-). The input block data is distributed in this 1220 matrix first across, then down. 1222 Next, we multiply the data matrix D by a Vandermonde matrix V. The V 1223 matrix has the number of rows equal to the incols calculated, and 1224 columns are equal to the . The content of the 1225 matrix is formed by v(i,j)=pow(i,j), whereas i reflects the row 1226 number starting at 0, and j reflects the column number starting at 0. 1227 Please note that calculations noted here have to be carried out in 1228 the GF noted in the respective operation to be successful. The 1229 operation results in a matrix A. 1231 7.4.4.3. Encrypt Target Block 1233 Each row vector of A is a new data block which is then encrypted with 1234 the corresponding encryption key noted in keys of the 1235 addRedundancyOperation. If there are not enough keys available, the 1236 keys used for encryption are reused from the beginning after the last 1237 key has been used. A routing block builder SHOULD provide enough 1238 keys so that all target blocks may be encrypted with a unique key. 1239 All encryptions SHOULD NOT use padding. 1241 7.5. Processing of Vortex Messages 1243 The accounting layer triggers processing according to information 1244 contained in a routing block in the workspace. All operations MUST 1245 be executed in the sequence provided in the routing block. Any 1246 failing operation must leave the result block unmodified. 1248 All workspace blocks resulting in IDs 1 to maxPayloadBlock are then 1249 added to the message and passed to the blending layer with 1250 appropriate instructions. 1252 8. Accounting 1254 8.1. Accounting Operations 1256 The accounting layer has two major kinds of operations: 1258 o Time-based operations (cleanup jobs and initiation of routing) 1260 o Routing triggered operations (updating quotas, authorizing 1261 operations, and pickup of incoming messages) 1263 Implementations MUST provide sufficient locking mechanisms to 1264 guarantee the integrity of accounting information and workspace at 1265 any time. 1267 8.1.1. Time-Based Garbage Collection 1269 The accounting layer SHOULD keep a list of expiry times. As soon as 1270 an entry (e.g., payload block, or identity) expires, the respective 1271 structure should be removed from the workspace. An implementation 1272 MAY choose to remove expired items periodically or when encountering 1273 them during normal operation. 1275 8.1.2. Time-Based Routing Initiation 1277 The accounting layer MAY keep a list of any time a routing block is 1278 activated. For improved privacy, the accounting layer should use a 1279 slotted model where, whenever possible, multiple routing blocks are 1280 handled in the same period of time, and the requests to the blending 1281 layers are mixed between the transactions. 1283 8.1.3. Routing Based Quota Updates 1285 A node MUST update quotas on the respective operations. It MUST 1286 decrease message quota before processing routing blocks in the 1287 workspace. A node MUST decrease the message quota after the 1288 processing of any header requests. 1290 8.1.4. Routing Based Authorization 1292 The transfer quota MUST be checked and decreased by the number of 1293 data bytes in the payload chunks after all header requests have been 1294 processed. The message quota MUST be decreased by one on each 1295 routing block triggering processing in the workspace. 1297 8.1.5. Ephemeral Identity Creation 1299 Any packet may request the creation of an ephemeral identity. A node 1300 SHOULD NOT accept such a request without a costly requirement. The 1301 request includes a lifetime of the ephemeral identity. The costs for 1302 creating the ephemeral identity SHOULD raise if a longer lifetime is 1303 requested. 1305 9. Acknowledgments 1307 Thanks go to my family which did support me with patience and 1308 countless hours and to Mark Zeman for his feedback challenging my 1309 thoughts and peace. 1311 10. IANA Considerations 1313 This memo includes no request to IANA. 1315 Additional encryption algorithms, paddings, modes, blending layers, 1316 or puzzles MUST be added by writing an extension to this or a 1317 subsequent RFC. For testing purposes, IDs above 1,000,000 should be 1318 used. 1320 11. Security Considerations 1322 The MessageVortex protocol may be understood more as a toolset than a 1323 fixed product. Depending on the usage of the toolset anonymity and 1324 security are affected. For a detailed analysis see [MVAnalysis]. 1326 The primary goals for security within this protocol did rely on the 1327 following focus areas: 1329 o Confidentiality 1331 o Integrity 1333 o Availability 1335 o Anonymity 1337 * 3rd party anonymity 1339 * sender anonymity 1341 * receiver anonymity 1343 All these factors are affected by the usage of the protocol. The 1344 following sections provide a list of factors affecting the primary 1345 goals. 1347 The Vortex protocol does not rely on any encryption on the transport 1348 layer. Vortex messages are already encrypted. Confidentiality is 1349 not affected by the protection mechanisms of the transport layer. 1351 If a transport layer supports encryption, a Vortex node SHOULD use it 1352 to improve the privacy of the message. 1354 Anonymity is affected by the inner workings of the blending layer in 1355 many ways. A Vortex message cannot be read by anyone except the peer 1356 nodes and the routing block builder, but the presence of a vortex 1357 node message may be detected. This may be done either by detecting 1358 the typical high entropy of an encrypted file, broken structures of a 1359 carrier file, a meaningless content of a carrier file, or the 1360 contextless communication of the transport layer with its peer 1361 partner. A blending layer SHOULD minimize the possibility of easy 1362 detection by minimizing these effects. 1364 A blending layer SHOULD use carrier files with high compression or 1365 encryption. Carrier files SHOULD NOT have inner structures so that 1366 the payload is comparable to valid content. To achieve 1367 undetectability by a human reviewer, a routing block builder should 1368 use F5 blending instead of PLAIN blending. This, however, increases 1369 the protocol overhead roughly by a tenfold. 1371 The two layers 'routing' and 'accounting' have the deepest insight 1372 into a Vortex message's inner working. They know the immediate peer 1373 sender and the peer recipients of all payload chunks. As decoy 1374 traffic is generated by combining chunks and applying redundancy 1375 calculations upon them, a node can never know whether a malfunction 1376 (e.g., when doing a recovery calculation) was intended or not. 1377 Therefore a node is unable to tell a failed transaction apart from a 1378 terminated transaction. It furthermore cannot tell content apart 1379 from decoy traffic. 1381 A routing block builder SHOULD follow the following rules in order 1382 not to compromise a Vortex message's anonymity: 1384 o All operations applied SHOULD be credibly involved in a message 1385 transfer. 1387 o There should always be a sufficient subset of the result of an 1388 addRedundancy operation sent to peers to allow recovery of the 1389 data built. 1391 o The anonymity set of a message should be sufficiently large to 1392 avoid legal prosecution of all jurisdictional entities involved. 1393 It has to be large enough to do so even if a certain amount of the 1394 anonymity set cooperates with an adversary. 1396 o Encryption and decryption SHOULD follow whenever possible normal 1397 usage. Avoid encrypting a block on a node with one key and 1398 decrypting it with a different key on the same or an adjacent 1399 node. 1401 o Traffic peaks SHOULD be uniformly distributed within the whole 1402 anonymity set. 1404 o A routing block SHOULD be used for a limited number of messages. 1405 If used as a message block for the node itself it should be used 1406 only once. A block builder SHOULD use the 1407 HeaderRequestReplaceIdentity block to update reply routing blocks 1408 on a regular base. Implementers should always keep in mind that 1409 the same routing block is identifiable as such by its structure. 1411 An active adversary cannot use blocks from other routing block 1412 builders for his purposes. He may falsify the result by injecting 1413 wrong message chunks or by not sending a message. Such message 1414 disruptions may be detected by intentionally routing some information 1415 to the routing block builders' node. If the Vortex message does not 1416 carry the information expected the node may safely assume that one of 1417 the involved nodes is misbehaving. A block building node MAY 1418 calculate reputation for involved nodes over time. A block building 1419 node MAY build redundancy paths into a routing block to withstand 1420 such malicious nodes. 1422 Receiver anonymity is in danger if the handling of message header and 1423 content is not done with care. An attacker might send a bugged 1424 message (e.g., with a DKIM or DMARC header) to deanonymize a 1425 recipient. Great care has to be taken when handling any other than 1426 local references when processing, verifying, or rendering a message. 1428 12. References 1430 12.1. Normative References 1432 [CCITT.X208.1988] 1433 International Telephone and Telegraph Consultative 1434 Committee, "Specification of Abstract Syntax Notation One 1435 (ASN.1)", CCITT Recommendation X.208, 11 1998. 1437 [CCITT.X680.2002] 1438 International Telephone and Telegraph Consultative 1439 Committee, "Abstract Syntax Notation One (ASN.1): 1440 Specification of basic notation", 11 2002. 1442 [EAX] Bellare, M., Rogaway, P., and D. Wagner, "The EAX mode of 1443 operation", 2011. 1445 [F5] Westfeld, A., "F5 - A Steganographic Algorithm - High 1446 Capacity Despite Better Steganalysis", 10 2001. 1448 [FIPS-AES] 1449 Federal Information Processing Standard (FIPS), 1450 "Specification for the ADVANCED ENCRYPTION STANDARD 1451 (AES)", 11 2011. 1453 [IEEE754] IEEE, "754-2008 - IEEE Standard for Floating-Point 1454 Arithmetic", 08 2008. 1456 [ISO-10118-3] 1457 International Organization for Standardization, "ISO/IEC 1458 10118-3:2004 -- Information technology -- Security 1459 techniques -- Hash-functions -- Part 3: Dedicated hash- 1460 functions", 3 2004. 1462 [MODES] National Institute for Standards and Technology (NIST), 1463 "Recommendation for Block Cipher Modes of Operation: 1464 Methods and Techniques", 12 2001. 1466 [RFC1423] Balenson, D., "Privacy Enhancement for Internet Electronic 1467 Mail: Part III: Algorithms, Modes, and Identifiers", 1468 RFC 1423, DOI 10.17487/RFC1423, February 1993, 1469 . 1471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1472 Requirement Levels", BCP 14, RFC 2119, 1473 DOI 10.17487/RFC2119, March 1997, 1474 . 1476 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1477 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 1478 2003, . 1480 [RFC3657] Moriai, S. and A. Kato, "Use of the Camellia Encryption 1481 Algorithm in Cryptographic Message Syntax (CMS)", 1482 RFC 3657, DOI 10.17487/RFC3657, January 2004, 1483 . 1485 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 1486 Counter Mode With IPsec Encapsulating Security Payload 1487 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 1488 . 1490 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1491 Specifications: ABNF", STD 68, RFC 5234, 1492 DOI 10.17487/RFC5234, January 2008, 1493 . 1495 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1496 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1497 DOI 10.17487/RFC5288, August 2008, 1498 . 1500 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1501 DOI 10.17487/RFC5958, August 2010, 1502 . 1504 [RFC7253] Krovetz, T. and P. Rogaway, "The OCB Authenticated- 1505 Encryption Algorithm", RFC 7253, DOI 10.17487/RFC7253, May 1506 2014, . 1508 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1509 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1510 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1511 . 1513 [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", 1514 05 2009. 1516 [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 1517 128-Bit Block Cipher, 1st Edition", 03 1999. 1519 [XEP-0234] 1520 Peter, S. and L. Stout, "XEP-0234: Jingle File Transfer", 1521 08 2017, . 1523 12.2. Informative References 1525 [DeadParrot] 1526 Houmansadr, A., Burbaker, C., and V. Shmatikov, "The 1527 Parrot is Dead: Observing Unobservable Network 1528 Communications", 2013, 1529 . 1531 [KAnon] Ahn, L., Bortz, A., and N. Hopper, "k-Anonymous Message 1532 Transmission", 2003. 1534 [MVAnalysis] 1535 Gwerder, M., "MessageVortex", 2018, 1536 . 1538 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1539 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 1540 . 1542 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1543 Extensions (MIME) Part One: Format of Internet Message 1544 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1545 . 1547 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1548 RFC 2595, DOI 10.17487/RFC2595, June 1999, 1549 . 1551 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1552 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 1553 . 1555 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1556 DOI 10.17487/RFC5321, October 2008, 1557 . 1559 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1560 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1561 March 2011, . 1563 [RFC7622] Saint-Andre, P., "Extensible Messaging and Presence 1564 Protocol (XMPP): Address Format", RFC 7622, 1565 DOI 10.17487/RFC7622, September 2015, 1566 . 1568 Appendix A. The ASN.1 schema for Vortex messages 1570 The following sections contain the ASN.1 modules specifying the 1571 MessageVortex Protocol 1573 A.1. The main VortexMessageBlocks 1575 MessageVortex-Schema DEFINITIONS EXPLICIT TAGS ::= 1576 BEGIN 1577 EXPORTS PrefixBlock, InnerMessageBlock, RoutingBlock, 1578 maxID; 1579 IMPORTS SymmetricKey, AsymmetricKey, MacAlgorithmSpec, CipherSpec 1580 FROM MessageVortex-Ciphers 1581 HeaderRequest 1582 FROM MessageVortex-Requests 1583 PayloadOperation 1584 FROM MessageVortex-Operations 1586 UsagePeriod, BlendingSpec 1587 FROM MessageVortex-Helpers; 1589 --*************************************************************** 1590 -- Constant definitions 1591 --*************************************************************** 1593 -- maximum serial number 1594 maxSerial INTEGER ::= 4294967295 1595 -- maximum number of administrative requests 1596 maxNumberOfRequests INTEGER ::= 8 1597 -- maximum number of seconds which the message might be delayed 1598 -- in the local queue (starting from startOffset) 1599 maxDurationOfProcessing INTEGER ::= 86400 1600 -- maximum id of an operation 1601 maxID INTEGER ::= 32767 1602 -- maximum number of routing blocks in a message 1603 maxRoutingBlocks INTEGER ::= 127 1604 -- maximum number a block may be replayed 1605 maxNumberOfReplays INTEGER ::= 127 1606 -- maximum number of payload chunks in a message 1607 maxPayloadBlocks INTEGER ::= 127 1608 -- maximum number of seconds a proof of non revocation may be old 1609 maxTimeCachedProof INTEGER ::= 86400 1610 -- The maximum ID of the workspace 1611 maxWorkspaceId INTEGER ::= 65535 1612 -- The maximum number of assembly instructions per combo 1613 maxAssemblyInstructions INTEGER ::= 255 1615 --*************************************************************** 1616 -- Block Definitions 1617 --*************************************************************** 1618 PrefixBlock ::= SEQUENCE { 1619 forwardsecret ChainSecret, 1620 key SymmetricKey, 1621 version INTEGER OPTIONAL 1622 } 1624 HeaderBlock ::= SEQUENCE { 1625 -- Public key of the identity representing this transmission 1626 identityKey AsymmetricKey, 1627 -- serial identifying this block 1628 serial INTEGER (0..maxSerial), 1629 -- number of times this block may be replayed (Tuple is 1630 -- identityKey, serial while UsagePeriod of block) 1631 maxReplays INTEGER (0..maxNumberOfReplays), 1632 -- subsequent Blocks are not processed before valid time. 1633 -- Host may reject too long retention. Recomended validity 1634 -- support >=1Mt. 1635 valid UsagePeriod, 1636 -- represents the chained secret which has to be found in 1637 -- subsequent blocks 1638 -- prevents reassembly attack 1639 forwardSecret ChainSecret, 1640 -- contains the MAC-Algorithm used for signing 1641 signAlgorithm MacAlgorithmSpec, 1642 -- contains administrative requests such as quota requests 1643 requests SEQUENCE (SIZE (0..maxNumberOfRequests)) 1644 OF HeaderRequest , 1645 -- Reply Block for the requests 1646 requestReplyBlock RoutingCombo, 1647 -- padding and identitifier required to solve the cryptopuzzle 1648 identifier [12201] PuzzleIdentifier OPTIONAL, 1649 -- This is for solving crypto puzzles 1650 proofOfWork [12202] OCTET STRING OPTIONAL 1652 } 1654 InnerMessageBlock ::= SEQUENCE { 1655 padding OCTET STRING, 1656 prefix CHOICE { 1657 plain [11011] PrefixBlock, 1658 -- contains prefix encrypted with receivers public key 1659 encrypted [11012] OCTET STRING 1660 }, 1661 identity CHOICE { 1662 -- debug/internal use only 1663 plain [11021] HeaderBlock, 1664 -- contains encrypted identity block 1665 encyrpted [11022] OCTET STRING 1666 }, 1667 -- contains signature of Identity [as stored in 1668 -- HeaderBlock; signed unencrypted HeaderBlock without Tag] 1669 identitySignature OCTET STRING, 1670 -- contains routing information (next hop) for the payloads 1671 routing CHOICE { 1672 plain [11031] RoutingBlock, 1673 -- contains encrypted routing block 1674 encyrpted [11032] OCTET STRING 1675 }, 1676 -- contains the actual payload 1677 payload SEQUENCE (SIZE (0..maxPayloadBlocks)) 1678 OF OCTET STRING 1679 } 1681 RoutingBlock ::= SEQUENCE { 1682 -- contains the prefix to be used 1683 routing CHOICE { 1684 -- debug/internal use only 1685 plain [331] SEQUENCE (SIZE (0..maxRoutingBlocks)) 1686 OF RoutingCombo, 1687 encrypted [332] SEQUENCE (SIZE (0..maxRoutingBlocks)) 1688 OF OCTET STRING 1689 }, 1690 -- contains the secret of the header block 1691 forwardSecret ChainSecret, 1692 -- contains a routing block which may be used when sending 1693 -- error messages back to the quota owner 1694 -- this routing block may be cached for future use 1695 replyBlock [131] SEQUENCE { 1696 murb RoutingCombo, 1697 maxReplay INTEGER, 1698 validity UsagePeriod 1699 } OPTIONAL 1701 } 1703 RoutingCombo ::= SEQUENCE { 1704 -- contains the period when the payload should be processed 1705 -- Router might refuse to long queue retention 1706 -- Recommended support for retention >=1h 1707 minProcessTime INTEGER (0..maxDurationOfProcessing), 1708 maxProcessTime INTEGER (0..maxDurationOfProcessing), 1709 -- The message key to encrypt the message 1710 messageKey [401] SymmetricKey OPTIONAL, 1711 -- contains the next recipient 1712 recipient [402] BlendingSpec OPTIONAL, 1713 -- PrefixBlock encrypted with message key 1714 mPrefix [403] OCTET STRING OPTIONAL, 1715 -- PrefixBlock encrypted with sender key 1716 cPrefix [404] OCTET STRING OPTIONAL, 1717 -- HeaderBlock encrypted with sender key 1718 header [405] OCTET STRING OPTIONAL, 1719 -- RoutingBlock encrypted with sender key 1720 routing [406] OCTET STRING OPTIONAL, 1721 -- contains information for building messages (when used as MURB 1722 -- ID 0 denotes original message; ID 1-maxPayloadBlocks denotes 1723 -- target message; 32768-maxWorkspaceId shared workspace for all 1724 -- blocks of this identity) 1725 assembly [407] SEQUENCE (SIZE (0..maxAssemblyInstructions)) 1726 OF PayloadOperation, 1727 validity [408] UsagePeriod, 1728 -- optional - to identify the sender of a message when received 1729 id [409] INTEGER OPTIONAL 1730 } 1732 PuzzleIdentifier ::= OCTET STRING ( SIZE(0..16) ) 1734 ChainSecret ::= INTEGER (0..4294967295) 1736 END 1738 A.2. The VortexMessage Operation Structures 1740 MessageVortex-Operations DEFINITIONS EXPLICIT TAGS ::= 1741 BEGIN 1742 EXPORTS PayloadOperation; 1743 IMPORTS maxID 1744 FROM MessageVortex-Schema 1745 SymmetricKey, AsymmetricKey, MacAlgorithmSpec, CipherSpec 1746 FROM MessageVortex-Ciphers 1747 UsagePeriod, BlendingSpec 1748 FROM MessageVortex-Helpers; 1750 -- maximum omega of the Galois field used 1751 maxGFSize INTEGER ::= 16 1752 -- maximum size of a message chunk 1753 maxChunkSize INTEGER ::= 4294967295 1754 -- minimum size of a message chunk (should be -maxChunkSize) 1755 minChunkSize INTEGER ::= -4294967295 1757 PayloadOperation ::= CHOICE { 1758 splitPayload [150] SplitPayloadOperation, 1759 mergePayload [160] MergePayloadOperation, 1760 encryptPayload [300] EncryptPayloadOperation, 1761 decryptPayload [310] DecryptPayloadOperation, 1762 addRedundancy [400] AddRedundancyOperation, 1763 removeRedundancy[410] RemoveRedundancyOperation 1764 } 1766 PercentSizeBlock ::= SEQUENCE { 1767 fromPercent INTEGER (0..100), 1768 toPercent INTEGER (0..100) 1769 } 1771 AbsoluteSizeBlock ::= SEQUENCE { 1772 fromAbsolute INTEGER (0..maxChunkSize), 1773 toAbsolute INTEGER (minChunkSize..maxChunkSize) 1774 -- negative toAbsolute denominates end in absolute value 1775 -- specified from the end of block 1776 } 1778 SizeBlock ::= SEQUENCE{ 1779 size CHOICE { 1780 percent [15001] PercentSizeBlock, 1781 absolute [15101] AbsoluteSizeBlock 1782 } 1783 } 1785 AddRedundancyOperation ::= SEQUENCE { 1786 inputId [16000] INTEGER (0..maxID), 1787 dataStripes [16001] INTEGER (1..254), 1788 redundancy [16002] INTEGER (1..254), 1789 keys [16003] SEQUENCE (SIZE (2..512)) 1790 OF SymmetricKey, 1791 outputId [16004] INTEGER (1..maxID), 1792 gfSize [16005] INTEGER (2..maxGFSize) 1793 } 1795 RemoveRedundancyOperation ::= SEQUENCE { 1796 inputId [16000] INTEGER (0..maxID), 1797 dataStripes [16001] INTEGER (1..254), 1798 redundancy [16002] INTEGER (1..254), 1799 keys [16003] SEQUENCE (SIZE (2..512)) 1800 OF SymmetricKey, 1801 outputId [16004] INTEGER (1..maxID), 1802 gfSize [16005] INTEGER (2..maxGFSize) 1803 } 1805 SplitPayloadOperation ::= SEQUENCE { 1806 originalId INTEGER (0..maxID), 1807 firstSize SizeBlock, 1808 newFirstId INTEGER (1..maxID), 1809 newSecondId INTEGER (1..maxID) 1810 } 1812 MergePayloadOperation ::= SEQUENCE { 1813 originalFirstId INTEGER (0..maxID), 1814 originalSecondId INTEGER (0..maxID), 1815 newId INTEGER (1..maxID) 1816 } 1818 EncryptPayloadOperation ::= SEQUENCE { 1819 originalId INTEGER (0..maxID), 1820 key SymmetricKey, 1821 newId INTEGER (1..maxID) 1822 } 1824 DecryptPayloadOperation ::= SEQUENCE { 1825 originalId INTEGER (0..maxID), 1826 key SymmetricKey, 1827 newId INTEGER (1..maxID) 1828 } 1830 END 1832 A.3. The VortexMessage Ciphers Structures 1834 MessageVortex-Ciphers DEFINITIONS EXPLICIT TAGS ::= 1835 BEGIN 1836 EXPORTS SymmetricKey, AsymmetricKey, MacAlgorithmSpec, CipherSpec; 1838 CipherSpec ::= SEQUENCE { 1839 asymmetric [16001] AsymmetricAlgorithmSpec OPTIONAL, 1840 symmetric [16002] SymmetricAlgorithmSpec OPTIONAL, 1841 mac [16003] MacAlgorithmSpec OPTIONAL, 1842 cipherUsage[16004] CipherUsage 1843 } 1845 CipherUsage ::= ENUMERATED { 1846 sign (200), 1847 encrypt (210) 1848 } 1850 SymmetricAlgorithmSpec ::= SEQUENCE { 1851 algorithm [16101]SymmetricAlgorithm, 1852 -- if ommited: pkcs1 1853 padding [16102]CipherPadding OPTIONAL, 1854 -- if ommited: cbc 1855 mode [16103]CipherMode OPTIONAL, 1856 parameter [16104]AlgorithmParameters OPTIONAL 1857 } 1859 AsymmetricAlgorithmSpec ::= SEQUENCE { 1860 algorithm AsymmetricAlgorithm, 1861 parameter AlgorithmParameters OPTIONAL 1862 } 1864 MacAlgorithmSpec ::= SEQUENCE { 1865 algorithm MacAlgorithm, 1866 parameter AlgorithmParameters 1867 } 1869 PRNGAlgorithmSpec ::= SEQUENCE { 1870 type PRNGType, 1871 seed OCTET STRING 1872 } 1874 PRNGType ::= ENUMERATED { 1875 xsadd (1000), 1876 blumMicali (1001) 1877 } 1879 SymmetricAlgorithm ::= ENUMERATED { 1880 aes128 (1000), -- required 1881 aes192 (1001), -- optional support 1882 aes256 (1002), -- required 1883 camellia128 (1100), -- required 1884 camellia192 (1101), -- optional support 1885 camellia256 (1102), -- required 1886 twofish128 (1200), -- optional support 1887 twofish192 (1201), -- optional support 1888 twofish256 (1202) -- optional support 1889 } 1891 CipherMode ::= ENUMERATED { 1892 -- ECB is a really bad choice. Do not use unless really 1893 -- necessary 1894 ecb (10000), 1895 cbc (10001), 1896 eax (10002), 1897 ctr (10003), 1898 ccm (10004), 1899 gcm (10005), 1900 ocb (10006), 1901 ofb (10007), 1902 none (10100) 1903 } 1905 CipherPadding ::= ENUMERATED { 1906 none (1000), 1907 pkcs1 (1001), 1908 pkcs7 (1002) 1909 } 1911 AsymmetricAlgorithm ::= ENUMERATED { 1912 rsa (2000), 1913 dsa (2100), 1914 ec (2200), 1915 ntru (2300) 1916 } 1918 MacAlgorithm ::= ENUMERATED { 1919 sha256 (3000), 1920 sha384 (3001), 1921 sha512 (3002), 1922 ripemd160 (3100), 1923 ripemd256 (3101), 1924 ripemd320 (3102) 1925 } 1927 ECCurveType ::= ENUMERATED{ 1928 secp384r1 (2500), 1929 sect409k1 (2501), 1930 secp521r1 (2502) 1931 } 1933 AlgorithmParameters ::= SEQUENCE { 1934 keySize [10000] INTEGER (0..65535) OPTIONAL, 1935 curveType [10001] ECCurveType OPTIONAL, 1936 initialisationVector [10002] OCTET STRING OPTIONAL, 1937 nonce [10003] OCTET STRING OPTIONAL, 1938 mode [10004] CipherMode OPTIONAL, 1939 padding [10005] CipherPadding OPTIONAL, 1940 n [10010] INTEGER OPTIONAL, 1941 p [10011] INTEGER OPTIONAL, 1942 q [10012] INTEGER OPTIONAL, 1943 k [10013] INTEGER OPTIONAL, 1944 t [10014] INTEGER OPTIONAL 1945 } 1947 -- Symmetric key 1948 SymmetricKey ::= SEQUENCE { 1949 keyType SymmetricAlgorithm, 1950 parameter AlgorithmParameters, 1951 key OCTET STRING (SIZE(16..512)) 1952 } 1954 -- Asymmetric Key 1955 AsymmetricKey ::= SEQUENCE { 1956 keyType AsymmetricAlgorithm, 1957 -- private key encoded as PKCS#8/PrivateKeyInfo 1958 publicKey [2] OCTET STRING, 1959 -- private key encoded as X.509/SubjectPublicKeyInfo 1960 privateKey [3] OCTET STRING OPTIONAL 1961 } 1963 END 1965 A.4. The VortexMessage Request Structures 1967 MessageVortex-Requests DEFINITIONS EXPLICIT TAGS ::= 1968 BEGIN 1969 IMPORTS StatusBlock, ReplyNodes, ReplyCurrentQuota, ReplyCapability 1970 FROM MessageVortex-Replies 1971 RequirementBlock 1972 FROM MessageVortex-Requirements 1973 UsagePeriod 1974 FROM MessageVortex-Helpers; 1976 HeaderRequest ::= CHOICE { 1977 identity [0] HeaderRequestIdentity, 1978 capabilities [1] HeaderRequestCapability, 1979 messageQuota [2] HeaderRequestIncreaseMessageQuota, 1980 transferQuota [3] HeaderRequestIncreaseTransferQuota, 1981 quotaQuery [4] HeaderRequestQuota, 1982 nodeQuery [5] HeaderRequestNodes 1983 } 1985 SpecialBlock ::= CHOICE { 1986 capabilities [1] ReplyCapability, 1987 requirement [2] SEQUENCE (SIZE (1..127)) 1988 OF RequirementBlock, 1989 quota [4] ReplyCurrentQuota, 1990 nodes [5] ReplyNodes, 1991 status [99] StatusBlock 1992 } 1994 HeaderRequestIdentity ::= SEQUENCE { 1995 period UsagePeriod 1996 } 1998 HeaderRequestQuota ::= SEQUENCE { 1999 } 2001 HeaderRequestNodes ::= SEQUENCE { 2002 numberOfNodes INTEGER 2003 } 2005 HeaderRequestIncreaseMessageQuota ::= SEQUENCE { 2006 messages INTEGER (0..4294967295) 2007 } 2009 HeaderRequestIncreaseTransferQuota ::= SEQUENCE { 2010 size INTEGER (0..4294967295) 2011 } 2013 HeaderRequestCapability ::= SEQUENCE { 2014 period UsagePeriod 2015 } 2017 END 2019 A.5. The VortexMessage Replies Structures 2021 MessageVortex-Replies DEFINITIONS EXPLICIT TAGS ::= 2022 BEGIN 2023 EXPORTS StatusBlock, ReplyCurrentQuota, ReplyCapability, 2024 ReplyNodes; 2025 IMPORTS BlendingSpec, NodeSpec 2026 FROM MessageVortex-Helpers 2027 CipherSpec 2028 FROM MessageVortex-Ciphers; 2030 StatusBlock ::= SEQUENCE { 2031 code StatusCode 2032 } 2034 StatusCode ::= ENUMERATED { 2036 -- System messages 2037 ok (2000), 2038 quotaStatus (2101), 2039 puzzleRequired (2201), 2041 -- protocol usage failures 2042 transferQuotaExceeded (3001), 2043 messageQuotaExceeded (3002), 2044 requestedQuotaOutOfBand (3003), 2045 identityUnknown (3101), 2046 messageChunkMissing (3201), 2047 messageLifeExpired (3202), 2048 puzzleUnknown (3301), 2050 -- capability errors 2051 macAlgorithmUnknown (3801), 2052 symmetricAlgorithmUnknown (3802), 2053 asymmetricAlgorithmUnknown (3803), 2054 prngAlgorithmUnknown (3804), 2055 missingParameters (3820), 2056 badParameters (3821), 2058 -- Mayor host specific errors 2059 hostError (5001) 2060 } 2062 ReplyNodes ::= SEQUENCE { 2063 node SEQUENCE (SIZE (1..5)) 2064 OF NodeSpec 2065 } 2067 ReplyCapability ::= SEQUENCE { 2068 cipher SEQUENCE (SIZE (2..256)) OF CipherSpec, 2069 maxTransferQuota INTEGER (0..4294967295), 2070 maxMessageQuota INTEGER (0..4294967295), 2071 supportedBlendingIn SEQUENCE OF BlendingSpec 2072 } 2074 ReplyCurrentQuota ::= SEQUENCE { 2075 messages INTEGER (0..4294967295), 2076 size INTEGER (0..4294967295) 2077 } 2079 END 2081 A.6. The VortexMessage Requirements Structures 2083 MessageVortex-Requirements DEFINITIONS EXPLICIT TAGS ::= 2084 BEGIN 2085 EXPORTS RequirementBlock; 2086 IMPORTS MacAlgorithmSpec 2087 FROM MessageVortex-Ciphers 2088 UsagePeriod, UsagePeriod 2089 FROM MessageVortex-Helpers; 2091 RequirementBlock ::= CHOICE { 2092 puzzle [1] RequirementPuzzleRequired, 2093 payment [2] RequirementPaymentRequired 2094 } 2096 RequirementPuzzleRequired ::= SEQUENCE { 2097 -- bit sequence at beginning of hash from encrypted identity 2098 -- block 2099 challenge BIT STRING, 2100 mac MacAlgorithmSpec, 2101 valid UsagePeriod, 2102 identifier INTEGER (0..4294967295) 2103 } 2105 RequirementPaymentRequired ::= SEQUENCE { 2106 account OCTET STRING, 2107 ammount REAL, 2108 currency Currency 2109 } 2111 Currency ::= ENUMERATED { 2112 btc (8001), 2113 eth (8002), 2114 zec (8003) 2115 } 2117 END 2119 A.7. The VortexMessage Helpers Structures 2120 MessageVortex-Helpers DEFINITIONS EXPLICIT TAGS ::= 2121 BEGIN 2122 EXPORTS UsagePeriod, BlendingSpec, NodeSpec; 2123 IMPORTS AsymmetricKey, SymmetricKey 2124 FROM MessageVortex-Ciphers; 2126 -- the maximum number of parameters that might be embedded 2127 maxNumberOfParameter INTEGER ::= 127 2129 UsagePeriod ::= SEQUENCE { 2130 notBefore [0] GeneralizedTime OPTIONAL, 2131 notAfter [1] GeneralizedTime OPTIONAL 2132 } 2134 -- contains a node spec of a routing point 2135 -- At the moment either smtp: or xmpp: 2136 BlendingSpec ::= SEQUENCE { 2137 target [1] NodeSpec, 2138 blendingType [2] IA5String, 2139 parameter [3] SEQUENCE ( SIZE (0..maxNumberOfParameter) ) 2140 OF BlendingParameter 2141 } 2143 BlendingParameter ::= CHOICE { 2144 offset [1] INTEGER, 2145 symmetricKey [2] SymmetricKey, 2146 asymmetricKey [3] AsymmetricKey 2147 } 2149 NodeSpec ::= SEQUENCE { 2150 transportProtocol [1] Protocol, 2151 recipientAddress [2] IA5String, 2152 recipientKey [3] AsymmetricKey OPTIONAL 2153 } 2155 Protocol ::= ENUMERATED { 2156 smtp (100), 2157 xmmp (110) 2158 } 2160 END 2162 A.8. The VortexMessage Additional Structures 2164 -- States: Tuple()=Value() [vallidity; allowed operations] {Store} 2165 -- - Tuple(identity)=Value(messageQuota,transferQuota,sequence of 2166 -- Routingblocks for Error Message Routing) [validity; Requested 2167 -- at creation; may be extended upon request] {identityStore} 2168 -- - Tuple(Identity,Serial)=maxReplays ['valid' from Identity 2169 -- Block; from First Identity Block; may only be reduced] 2170 -- {IdentityReplayStore} 2172 MessageVortex-NonProtocolBlocks DEFINITIONS EXPLICIT TAGS ::= 2173 BEGIN 2174 IMPORTS PrefixBlock, InnerMessageBlock, RoutingBlock, maxID 2175 FROM MessageVortex-Schema 2176 UsagePeriod, NodeSpec, BlendingSpec 2177 FROM MessageVortex-Helpers 2178 AsymmetricKey 2179 FROM MessageVortex-Ciphers 2180 RequirementBlock 2181 FROM MessageVortex-Requirements; 2183 -- maximum size of transfer quota in bytes of an identity 2184 maxTransferQuota INTEGER ::= 4294967295 2185 -- maximum size of message quota in messages of an identity 2186 maxMessageQuota INTEGER ::= 4294967295 2188 -- do not use these blocks for protocol encoding (internal only) 2189 VortexMessage ::= SEQUENCE { 2190 prefix CHOICE { 2191 plain [10011] PrefixBlock, 2192 -- contains prefix encrypted with receivers public key 2193 encrypted [10012] OCTET STRING 2194 }, 2195 innerMessage CHOICE { 2196 plain [10021] InnerMessageBlock, 2197 -- contains inner message encrypted with Symmetric key from 2198 -- Prefix 2199 encrypted [10022] OCTET STRING 2200 } 2201 } 2203 MemoryPayloadChunk ::= SEQUENCE { 2204 id INTEGER (0..maxID), 2205 payload [100] OCTET STRING, 2206 validity UsagePeriod 2207 } 2209 IdentityStore ::= SEQUENCE { 2210 identities SEQUENCE (SIZE (0..4294967295)) 2211 OF IdentityStoreBlock 2212 } 2214 IdentityStoreBlock ::= SEQUENCE { 2215 valid UsagePeriod, 2216 messageQuota INTEGER (0..maxMessageQuota), 2217 transferQuota INTEGER (0..maxTransferQuota), 2218 -- if omitted this is a node identity 2219 identity [1001] AsymmetricKey OPTIONAL, 2220 -- if ommited own identity key 2221 nodeAddress [1002] NodeSpec OPTIONAL, 2222 -- Contains the identity of the owning node; 2223 -- May be ommited if local node 2224 nodeKey [1003] SEQUENCE OF AsymmetricKey OPTIONAL, 2225 routingBlocks [1004] SEQUENCE OF RoutingBlock OPTIONAL, 2226 replayStore [1005] IdentityReplayStore, 2227 requirement [1006] RequirementBlock OPTIONAL 2228 } 2230 IdentityReplayStore ::= SEQUENCE { 2231 replays SEQUENCE (SIZE (0..4294967295)) 2232 OF IdentityReplayBlock 2233 } 2235 IdentityReplayBlock ::= SEQUENCE { 2236 identity AsymmetricKey, 2237 valid UsagePeriod, 2238 replaysRemaining INTEGER (0..4294967295) 2239 } 2241 END 2243 Author's Address 2245 Martin Gwerder 2246 Untere Parkstrasse 9 2247 Hausen, AG 5212 2248 Switzerland 2250 Phone: +41 56 202 76 81 2251 Email: rfc@messagevortex.net