idnits 2.17.1 draft-gwerder-messagevortexmain-07.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 (3 April 2021) is 1119 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 2278 -- Looks like a reference, but probably isn't: '2' on line 2301 -- Looks like a reference, but probably isn't: '11011' on line 1795 -- Looks like a reference, but probably isn't: '11012' on line 1798 -- Looks like a reference, but probably isn't: '11021' on line 1802 -- Looks like a reference, but probably isn't: '11022' on line 1804 -- Looks like a reference, but probably isn't: '11001' on line 1812 -- Looks like a reference, but probably isn't: '11031' on line 1813 -- Looks like a reference, but probably isn't: '11032' on line 1815 -- Looks like a reference, but probably isn't: '12201' on line 1848 -- Looks like a reference, but probably isn't: '12202' on line 1850 -- Looks like a reference, but probably isn't: '331' on line 1855 -- Looks like a reference, but probably isn't: '332' on line 1868 -- Looks like a reference, but probably isn't: '401' on line 1885 -- Looks like a reference, but probably isn't: '402' on line 1889 -- Looks like a reference, but probably isn't: '403' on line 1891 -- Looks like a reference, but probably isn't: '404' on line 1895 -- Looks like a reference, but probably isn't: '405' on line 1897 -- Looks like a reference, but probably isn't: '406' on line 1899 -- Looks like a reference, but probably isn't: '407' on line 1907 -- Looks like a reference, but probably isn't: '408' on line 1911 -- Looks like a reference, but probably isn't: '16001' on line 1925 -- Looks like a reference, but probably isn't: '16002' on line 1926 -- Looks like a reference, but probably isn't: '16003' on line 1927 -- Looks like a reference, but probably isn't: '16004' on line 1928 -- Looks like a reference, but probably isn't: '3' on line 2302 -- Looks like a reference, but probably isn't: '9000' on line 1991 -- Looks like a reference, but probably isn't: '9001' on line 1992 -- Looks like a reference, but probably isn't: '9002' on line 1993 -- Looks like a reference, but probably isn't: '9003' on line 1994 -- Looks like a reference, but probably isn't: '9004' on line 1995 -- Looks like a reference, but probably isn't: '9005' on line 1996 -- Looks like a reference, but probably isn't: '9010' on line 1997 -- Looks like a reference, but probably isn't: '9011' on line 1998 -- Looks like a reference, but probably isn't: '9012' on line 1999 -- Looks like a reference, but probably isn't: '9013' on line 2000 -- Looks like a reference, but probably isn't: '9014' on line 2001 -- Looks like a reference, but probably isn't: '1' on line 2300 -- Looks like a reference, but probably isn't: '4' on line 2296 -- Looks like a reference, but probably isn't: '5' on line 2127 -- Looks like a reference, but probably isn't: '6' on line 2066 -- Looks like a reference, but probably isn't: '99' on line 2128 -- Looks like a reference, but probably isn't: '10011' on line 2349 -- Looks like a reference, but probably isn't: '10012' on line 2352 -- Looks like a reference, but probably isn't: '10021' on line 2355 -- Looks like a reference, but probably isn't: '10022' on line 2358 -- Looks like a reference, but probably isn't: '100' on line 2363 -- Looks like a reference, but probably isn't: '1001' on line 2377 -- Looks like a reference, but probably isn't: '1002' on line 2379 -- Looks like a reference, but probably isn't: '1003' on line 2382 -- Looks like a reference, but probably isn't: '1004' on line 2384 -- Looks like a reference, but probably isn't: '1005' on line 2386 -- Looks like a reference, but probably isn't: '1006' on line 2387 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 55 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Gwerder 3 Internet-Draft FHNW 4 Intended status: Experimental 3 April 2021 5 Expires: 5 October 2021 7 MessageVortex Protocol 8 draft-gwerder-messagevortexmain-07 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 the existing 15 transfer protocols, such as SMTP or XMPP, sent via peer nodes to one 16 or more 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 (routing block 22 builder; RBB) has full control over the message flow. Routing nodes 23 gain no non-obvious knowledge about the messages even when 24 collaborating. While third-party anonymity is always achieved, the 25 protocol also allows for either 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 5 October 2021. 44 Copyright Notice 46 Copyright (c) 2021 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 62 1.2. Protocol Specification . . . . . . . . . . . . . . . . . 5 63 1.3. Number Specification . . . . . . . . . . . . . . . . . . 5 64 2. Entities Overview . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Node . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1.1. Blocks . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.1.2. NodeSpec . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1.2.1. NodeSpec for SMTP nodes . . . . . . . . . . . . . 6 69 2.1.2.2. NodeSpec for XMPP nodes . . . . . . . . . . . . . 7 70 2.2. Peer Partners . . . . . . . . . . . . . . . . . . . . . . 7 71 2.3. Encryption Keys . . . . . . . . . . . . . . . . . . . . . 7 72 2.3.1. Identity Keys . . . . . . . . . . . . . . . . . . . . 7 73 2.3.2. Peer Key . . . . . . . . . . . . . . . . . . . . . . 7 74 2.3.3. Sender Key . . . . . . . . . . . . . . . . . . . . . 8 75 2.4. Vortex Message . . . . . . . . . . . . . . . . . . . . . 8 76 2.5. Message . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 2.6. Key and MAC specifications and usage . . . . . . . . . . 9 78 2.6.1. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 9 79 2.6.2. Symmetric Keys . . . . . . . . . . . . . . . . . . . 10 80 2.7. Transport Address . . . . . . . . . . . . . . . . . . . . 10 81 2.8. Identity . . . . . . . . . . . . . . . . . . . . . . . . 10 82 2.8.1. Peer Identity . . . . . . . . . . . . . . . . . . . . 10 83 2.8.2. Ephemeral Identity . . . . . . . . . . . . . . . . . 10 84 2.8.3. Official Identity . . . . . . . . . . . . . . . . . . 11 85 2.9. Workspace . . . . . . . . . . . . . . . . . . . . . . . . 11 86 2.10. Multi-use Reply Blocks . . . . . . . . . . . . . . . . . 11 87 2.11. Protocol Version . . . . . . . . . . . . . . . . . . . . 11 88 3. Layer Overview . . . . . . . . . . . . . . . . . . . . . . . 12 89 3.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 12 90 3.2. Blending Layer . . . . . . . . . . . . . . . . . . . . . 12 91 3.3. Routing Layer . . . . . . . . . . . . . . . . . . . . . . 13 92 3.4. Accounting Layer . . . . . . . . . . . . . . . . . . . . 13 93 4. Vortex Message . . . . . . . . . . . . . . . . . . . . . . . 13 94 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 95 4.2. Message Prefix Block (MPREFIX) . . . . . . . . . . . . . 14 96 4.3. Inner Message Block . . . . . . . . . . . . . . . . . . . 14 97 4.3.1. Control Prefix Block . . . . . . . . . . . . . . . . 14 98 4.3.2. Control Blocks . . . . . . . . . . . . . . . . . . . 14 99 4.3.2.1. Header Block . . . . . . . . . . . . . . . . . . 14 100 4.3.2.2. Routing Block . . . . . . . . . . . . . . . . . . 15 101 4.3.3. Payload Block . . . . . . . . . . . . . . . . . . . . 15 102 5. General notes . . . . . . . . . . . . . . . . . . . . . . . . 15 103 5.1. Supported Symmetric Ciphers . . . . . . . . . . . . . . . 15 104 5.2. Supported Asymmetric Ciphers . . . . . . . . . . . . . . 16 105 5.3. Supported MACs . . . . . . . . . . . . . . . . . . . . . 16 106 5.4. Supported Paddings . . . . . . . . . . . . . . . . . . . 16 107 5.5. Supported Modes . . . . . . . . . . . . . . . . . . . . . 17 108 6. Blending . . . . . . . . . . . . . . . . . . . . . . . . . . 17 109 6.1. Blending in Attachments . . . . . . . . . . . . . . . . . 17 110 6.1.1. PLAIN embedding into attachments . . . . . . . . . . 18 111 6.1.2. F5 embedding into attachments . . . . . . . . . . . . 19 112 6.2. Blending into an SMTP layer . . . . . . . . . . . . . . . 19 113 6.3. Blending into an XMPP layer . . . . . . . . . . . . . . . 19 114 7. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 115 7.1. Vortex Message Processing . . . . . . . . . . . . . . . . 20 116 7.1.1. Processing of incoming Vortex Messages . . . . . . . 20 117 7.1.2. Processing of Routing Blocks in the Workspace . . . . 22 118 7.1.3. Processing of Outgoing Vortex Messages . . . . . . . 23 119 7.2. Header Requests . . . . . . . . . . . . . . . . . . . . . 24 120 7.2.1. Request New Ephemeral Identity . . . . . . . . . . . 24 121 7.2.2. Request Message Quota . . . . . . . . . . . . . . . . 24 122 7.2.3. Request Increase of Message Quota . . . . . . . . . . 24 123 7.2.4. Request Transfer Quota . . . . . . . . . . . . . . . 25 124 7.2.5. Query Quota . . . . . . . . . . . . . . . . . . . . . 25 125 7.2.6. Request Capabilities . . . . . . . . . . . . . . . . 25 126 7.2.7. Request Nodes . . . . . . . . . . . . . . . . . . . . 25 127 7.2.8. Request Identity Replace . . . . . . . . . . . . . . 26 128 7.2.9. Request Upgrade . . . . . . . . . . . . . . . . . . . 26 129 7.3. Special Blocks . . . . . . . . . . . . . . . . . . . . . 26 130 7.3.1. Error Block . . . . . . . . . . . . . . . . . . . . . 26 131 7.3.2. Requirement Block . . . . . . . . . . . . . . . . . . 27 132 7.3.2.1. Puzzle Requirement . . . . . . . . . . . . . . . 27 133 7.3.2.2. Payment Requirement . . . . . . . . . . . . . . . 27 134 7.3.2.3. Upgrade . . . . . . . . . . . . . . . . . . . . . 27 135 7.4. Routing Operations . . . . . . . . . . . . . . . . . . . 28 136 7.4.1. Mapping Operation . . . . . . . . . . . . . . . . . . 28 137 7.4.2. Split and Merge Operations . . . . . . . . . . . . . 28 138 7.4.3. Encrypt and Decrypt Operations . . . . . . . . . . . 29 139 7.4.4. Add and Remove Redundancy Operations . . . . . . . . 29 140 7.4.4.1. Padding Operation . . . . . . . . . . . . . . . . 29 141 7.4.4.2. Apply Matrix . . . . . . . . . . . . . . . . . . 30 142 7.4.4.3. Encrypt Target Block . . . . . . . . . . . . . . 31 143 7.5. Processing of Vortex Messages . . . . . . . . . . . . . . 31 144 8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 31 145 8.1. Accounting Operations . . . . . . . . . . . . . . . . . . 31 146 8.1.1. Time-Based Garbage Collection . . . . . . . . . . . . 31 147 8.1.2. Time-Based Routing Initiation . . . . . . . . . . . . 32 148 8.1.3. Routing Based Quota Updates . . . . . . . . . . . . . 32 149 8.1.4. Routing Based Authorization . . . . . . . . . . . . . 32 150 8.1.5. Ephemeral Identity Creation . . . . . . . . . . . . . 32 151 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 152 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 153 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 154 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 155 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 156 12.2. Informative References . . . . . . . . . . . . . . . . . 37 157 Appendix A. The ASN.1 schema for Vortex messages . . . . . . . . 38 158 A.1. The Main MessageVortex Blocks . . . . . . . . . . . . . . 38 159 A.2. The MessageVortex Ciphers Structures . . . . . . . . . . 42 160 A.3. The MessageVortex Request Structures . . . . . . . . . . 44 161 A.4. The MessageVortex Replies Structures . . . . . . . . . . 46 162 A.5. The MessageVortex Requirements Structures . . . . . . . . 48 163 A.6. The MessageVortex Helpers Structures . . . . . . . . . . 49 164 A.7. The MessageVortex Additional Structures . . . . . . . . . 50 165 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 53 166 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53 168 1. Introduction 170 Anonymization is difficult to achieve. Most previous attempts relied 171 on either trust in a dedicated infrastructure or a specialized 172 networking protocol. 174 Instead of defining a transport layer, Vortex piggybacks on other 175 transport protocols. A blending layer embeds MessageVortex messages 176 (VortexMessage) into ordinary messages of the respective transport 177 protocol. This layer picks up the messages, passes them to a routing 178 layer, which applies local operations to the messages, and resends 179 the new message chunks to the next recipients. 181 A processing node learns as little as possible from the message or 182 the network utilized. The operations have been designed to be 183 sensible in any context. The 'onionized' structure of the protocol 184 makes it impossible to follow the trace of a message without having 185 control over the processing node. 187 MessageVortex is a protocol that allows sending and receiving 188 messages by using a routing block instead of a destination address. 189 With this approach, the sender has full control over all parameters 190 of the message flow. 192 A message is split and reassembled during transmission. Chunks of 193 the message may carry redundant information to avoid service 194 interruptions during transit. Decoy and message traffic are not 195 differentiable as the nature of the addRedundancy operation allows 196 each generated portion to be either message or decoy. Therefore, all 197 routing nodes are unable to distinguish between message and decoy 198 traffic. 200 After processing, a potential receiver node knows if the message is 201 destined for it (by creating a chunk with ID 0) or other nodes. Due 202 to missing keys, no other node may perform this processing. 204 This RFC begins with general terminology (see Section 2) followed by 205 an overview of the process (see Section 3). The subsequent sections 206 describe the details of the protocol. 208 1.1. Requirements Language 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [RFC2119]. 214 1.2. Protocol Specification 216 Appendix A specifies all relevant parts of the protocol in ASN.1 (see 217 [CCITT.X680.2002] and [CCITT.X208.1988]). The blocks are DER- 218 encoded, if not otherwise specified. 220 1.3. Number Specification 222 All numbers within this document are, if not suffixed, decimal 223 numbers. Numbers suffixed with a small letter 'h' followed by two 224 hexadecimal digits are octets written in hexadecimal. For example, a 225 blank ASCII character (' ') is written as 20h and a capital 'K' in 226 ASCII as 4Bh. 228 2. Entities Overview 230 The following entities used in this document are defined below. 232 2.1. Node 234 The term 'node' describes any computer system connected to other 235 nodes, which support the MessageVortex protocol. A 'node address' is 236 typically an email address, an XMPP address, or other transport 237 protocol identity supporting the MessageVortex protocol. Any address 238 SHOULD include a public part of an 'identity key' to allow messages 239 to transmit safely. One or more addresses MAY belong to the same 240 node. 242 2.1.1. Blocks 244 A 'block' represents an ASN.1 sequence in a transmitted message. We 245 embed messages in the transport protocol, and these messages may be 246 of any size. 248 2.1.2. NodeSpec 250 A nodeSpec block, as specified in Appendix A.6, expresses an 251 addressable node in a unified format. The nodeSpec contains a 252 reference to the routing protocol, the routing address within this 253 protocol, and the keys required for addressing the node. This RFC 254 specifies transport layers for XMPP and SMTP. Additional transport 255 layers will require an extension to this RFC. 257 2.1.2.1. NodeSpec for SMTP nodes 259 An alternative address representation is defined that allows a 260 standard email client to address a Vortex node. A node SHOULD 261 support the smtpAlternateSpec (its specification is noted in ABNF as 262 in [RFC5234]). For applications with QR code support, an 263 implementation SHOULD use the smtpUrl representation. 265 localPart = 266 domain = 267 email = localPart "@" domain 268 keySpec = 269 smtpAlternateSpec = localPart ".." keySpec ".." domain "@localhost" 270 smtpUrl = "vortexsmtp://" smtpAlternateSpec 272 This representation does not support quoted local part SMTP 273 addresses. 275 2.1.2.2. NodeSpec for XMPP nodes 277 Typically, a node specification follows the ASN.1 block NodeSpec. 278 For support of XMPP clients, an implementation SHOULD support the 279 jidAlternateSpec (its specification is noted in ABNF as in 280 [RFC5234]). 282 localPart = 283 domain = 284 resourcePart = 285 jid = localPart "@" domain [ "/" resourcePart ] 286 keySpec = ; 287 jidAlternateSpec = localPart ".." keySpec ".." 288 domain "@localhost" [ "/" resourcePart ] 289 jidUrl = "vortexxmpp://" jidAlternateSpec 291 2.2. Peer Partners 293 This document refers to two or more message sending or receiving 294 entities as peer partners. One partner sends a message, and all 295 others receive one or more messages. Peer partners are message 296 specific, and each partner always connects directly to a node. 298 2.3. Encryption Keys 300 Several keys are required for a Vortex message. For identities and 301 ephemeral identities (see below), we use asymmetric keys, while 302 symmetric keys are used for message encryption. 304 2.3.1. Identity Keys 306 Every participant of the network includes an asymmetric key, which 307 SHOULD be either an EC key with a minimum length of 384 bits or an 308 RSA key with a minimum length of 2048 bits. 310 The public key must be known by all parties writing to or through the 311 node. 313 2.3.2. Peer Key 315 Peer keys are symmetrical keys transmitted with a Vortex message and 316 are always known to the node sending the message, the node receiving 317 the message, and the creator of the routing block. 319 A peer key is included in the Vortex message as well as the building 320 instructions for subsequent Vortex messages (see RoutingCombo in 321 Appendix A). 323 2.3.3. Sender Key 325 The sender key is a symmetrical key protecting the identity and 326 routing block of a Vortex message. It is encrypted with the 327 receiving peer key and prefixed to the identity block. This key 328 further decouples the identity and processing information from the 329 previous key. 331 A sender key is known to only one peer of a Vortex message and the 332 creator of the routing block. 334 2.4. Vortex Message 336 The term 'Vortex message' represents a single transmission between 337 two routing layers. A message adapted to the transport layer by the 338 blending layer is called a 'blended Vortex message' (see Section 3). 340 A complete Vortex message contains the following items: 342 * The peer key, which is encrypted with the host key of the node and 343 stored in a prefixBlock, protects the inner Vortex message 344 (innerMessageBlock). 346 * The sender key, also encrypted with the host key of the node, 347 protects the identity and routing block. 349 * The identity block, protected by the sender key, contains 350 information about the ephemeral identity of the sender, replay 351 protection information, header requests (optional), and a 352 requirement reply (optional). 354 * The routing block, protected by the sender key, contains 355 information on how subsequent messages are processed, assembled, 356 and blended. 358 * The payload block, protected by the peer key, contains payload 359 chunks for processing. 361 2.5. Message 363 A message is content to be transmitted from a single sender to a 364 recipient. The sender uses a routing block either built by themself 365 or provided by the receiver to perform the transmission. While a 366 message may be anonymous, there are different degrees of anonymity as 367 described in the following. 369 * If the sender of a message is not known to anyone else except the 370 sender, then this degree is referred to as 'sender anonymity.' 372 * If the receiver of a message is not known to anyone else except 373 the receiver, then the degree is 'receiver anonymity.' 375 * If an attacker is unable to determine the content, original 376 sender, and final receiver, then the degree is considered 'third- 377 party anonymity.' 379 * If a sender or a receiver may be determined as one of a set of 380 entities, then it is referred to as k-anonymity[KAnon]. 382 A message is always MIME-encoded as specified in [RFC2045]. 384 2.6. Key and MAC specifications and usage 386 MessageVortex uses a unique encoding for keys. This encoding is 387 designed to be small and flexible while maintaining a specific base 388 structure. 390 The following key structures are available: 392 * SymmetricKey 394 * AsymmetricKey 396 MAC does not require a complete structure containing specs and 397 values, and only a MacAlgorithmSpec is available. The following 398 sections outline the constraints for specifying parameters of these 399 structures where a node MUST NOT specify any parameter more than 400 once. 402 If a crypto mode is specified requiring an IV, then a node MUST 403 provide the IV when specifying the key. 405 2.6.1. Asymmetric Keys 407 Nodes use asymmetric keys for identifying peer nodes (i.e., 408 Identities) and encrypting symmetric keys (for subsequent 409 de-/encryption of the payload or blocks). All asymmetric keys MUST 410 contain a key type specifying a strictly normed key. Also, they MUST 411 contain a public part of the key encoded as an X.509 container and a 412 private key specified in PKCS#8 wherever possible. 414 RSA and EC keys MUST contain a keySize parameter. All asymmetric 415 keys SHOULD have a padding parameter, and a node SHOULD assume PKCS#1 416 if no padding is specified. 418 NTRU specification MUST provide the parameters "n", "p", and "q". 420 2.6.2. Symmetric Keys 422 Nodes use symmetric keys for encrypting payloads and control blocks. 423 These symmetric keys MUST contain a key type specifying a key, which 424 MUST be in an encoded form. 426 A node MUST provide a keySize parameter if the key (or equivalently, 427 the block) size is not standardized or encoded in the name. All 428 symmetric key specifications MUST contain a mode and padding 429 parameter. A node MAY list multiple padding or mode parameters in a 430 ReplyCapability block to offer the recipient a free choice. 432 2.7. Transport Address 434 The term 'transport address' represents the token required to address 435 the next immediate node on the transport layer. An email transport 436 layer would have SMTP addresses, such as 'vortex@example.com,' as the 437 transport address. 439 2.8. Identity 441 2.8.1. Peer Identity 443 The peer identity may contain the following information of a 444 peerpartner: 446 * A transport address (always) and the public key of thisidentity, 447 given there is no recipient anonymity. 449 * A routing block, which may be used to contact the sender. If 450 striving for recipient anonymity, then this block is required. 452 * The private key, which is only known by the owner of the identity. 454 2.8.2. Ephemeral Identity 456 Ephemeral identities are temporary identities created on a single 457 node. These identities MUST NOT relate to another identity on any 458 other node so that they allow bookkeeping for a node. Each ephemeral 459 identity has a workspace assigned and may also have the following 460 items assigned. 462 * An asymmetric key pair to represent the identity. 464 * A validity time of the identity. 466 2.8.3. Official Identity 468 An official identity may have the following items assigned. 470 * Routing blocks used to reply to the node. 472 * A list of assigned ephemeral identities on all other nodes and 473 their projected quotas. 475 * A list of known nodes with the respective node identity. 477 2.9. Workspace 479 Every official or ephemeral identity has a workspace, which consists 480 of the following elements. 482 * Zero or more routing blocks to be processed. 484 * Slots for a payload block sequentially numbered. Every slot: 486 - MUST contain a numerical ID identifying the slot. 488 - MAY contain payload content. 490 - If a block contains a payload, then it MUST contain a validity 491 period. 493 2.10. Multi-use Reply Blocks 495 'Multi-use reply blocks' (MURB) are a special type routing block sent 496 to a receiver of a message or request. A sender may use such a block 497 one or several times to reply to the sender linked to the ephemeral 498 identity, and it is possible to achieve sender anonymity using MURBs. 500 A vortex node MAY deny the use of MURBs by indicating a maxReplay 501 equal to zero when sending a ReplyCapability block. An unobservable 502 node SHOULD deny the use of MURBs. 504 2.11. Protocol Version 506 This document describes version 1 of the protocol. The message 507 PrefixBlock contains an optional version indicator. If absent 508 protocol version 1 should be assumed. %FIXME something is missing 509 here 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 that 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. A host MAY reply to a message with an unencrypted 609 message block, but any reply to a message SHOULD be encrypted. 611 The sender MUST choose a key that may be encrypted with the host key 612 in the respective PrefixBlock using the padding advertised by the 613 CapabilitiesReplyBlock. 615 4.3. Inner Message Block 617 A node MUST always encrypt an InnerMessageBlock with the symmetric 618 key of the PrefixBlock to hide the inner structure of the message. 619 The InnerMessageBlock SHOULD always accommodate four or more payload 620 chunks. 622 4.3.1. Control Prefix Block 624 Control prefix (CPREFIX) and MPREFIX blocks share the same structure 625 and logic as well as containing the sender key sk_s. If an MPREFIX 626 block is unencrypted, a node MAY omit the CPREFIX block. An omitted 627 CPREFIX block results in unencrypted control blocks (e.g., the 628 HeaderBlock and RoutingBlock). 630 4.3.2. Control Blocks 632 The control blocks of the HeaderBlock and a RoutingBlock contain the 633 core information to process the payload. 635 4.3.2.1. Header Block 637 The header block (see HeaderBlock in Appendix A) contains the 638 following information. 640 * It MUST contain the local ephemeral identity of the routing block 641 builder. 643 * It MAY contain header requests. 645 * It MAY contain the solution to a PuzzleRequired block previously 646 opposed in a header request. 648 The list of header requests MAY be one of the following. 650 * Empty. 652 * Contain a single identity create request (HeaderRequestIdentity). 654 * Contain a single increase quota request. 656 If a header block violates these rules, then a node MUST NOT reply to 657 any header request. The payload and routing blocks SHOULD still be 658 added to the workspace and processed if the message quota is not 659 exceeded. 661 4.3.2.2. Routing Block 663 The routing block (see RoutingBlock in Appendix A) contains the 664 following information. 666 * It MUST contain a serial number uniquely identifying the routing 667 block of this user. The serial number MUST be unique during the 668 lifetime of the routing block. 670 * It MUST contain the same forward secret as the two prefix blocks 671 and the header block. 673 * It MAY contain assembly and processing instructions for subsequent 674 messages. 676 * It MAY contain a reply block for messages assigned to the owner of 677 the identity. 679 4.3.3. Payload Block 681 Each InnerMessageBlock with routing information SHOULD contain at 682 least four PayloadChunks. 684 5. General notes 686 The MessageVortex protocol is a modular protocol that allows the use 687 of different encryption algorithms. For its operation, a Vortex node 688 SHOULD always support at least two distinct types of algorithms, 689 paddings, or modes such that they rely on two mathematical problems. 691 5.1. Supported Symmetric Ciphers 693 A node MUST support the following symmetric ciphers. 695 * AES128 (see [FIPS-AES] for AES implementation details). 697 * AES256. 699 * CAMELLIA128 (see [RFC3657] Chapter 3 for Camellia implementation 700 details). 702 * CAMELLIA256. 704 A node SHOULD support any standardized key larger than the smallest 705 key size. 707 A node MAY support Twofish ciphers (see [TWOFISH]). 709 5.2. Supported Asymmetric Ciphers 711 A node MUST support the following asymmetric ciphers. 713 * RSA with key sizes larger or equal to 2048 ([RFC8017]). 715 * ECC with named curves secp384r1, sect409k1 or secp521r1 (see 716 [SEC1]). 718 5.3. Supported MACs 720 A node MUST support the following Message Authentication Codes (MAC). 722 * SHA3-256 (see [ISO-10118-3] for SHA implementation details). 724 * RipeMD160 (see [ISO-10118-3] for RIPEMD implementation details). 726 A node SHOULD support the following MACs. 728 * SHA3-512. 730 * RipeMD256. 732 * RipeMD512. 734 5.4. Supported Paddings 736 A node MUST support the following paddings specified in [RFC8017]. 738 * PKCS1 (see [RFC8017]). 740 * PKCS7 (see [RFC5958]). 742 5.5. Supported Modes 744 A node MUST support the following modes. 746 * CBC (see [RFC1423]) such that the utilized IV must be of equal 747 length as the key. 749 * EAX (see [EAX]). 751 * GCM (see [RFC5288]). 753 * NONE (only used in special cases, see Section 11). 755 A node SHOULD NOT use the following modes. 757 * NONE (except as stated when using the addRedundancy function). 759 * ECB. 761 A node SHOULD support the following modes. 763 * CTR ([RFC3686]). 765 * CCM ([RFC3610]). 767 * OCB ([RFC7253]). 769 * OFB ([MODES]). 771 6. Blending 773 Each node supports a fixed set of blending capabilities, which may be 774 different for incoming and outgoing messages. 776 The following sections describe the blending mechanism. There are 777 currently two blending layers specified with one for the Simple Mail 778 Transfer Protocol (SMTP, see [RFC5321]) and the second for the 779 Extensible Messaging and Presence Protocol (XMPP, see [RFC6120]). 780 All nodes MUST at least support "encoding=plain:0,256". 782 6.1. Blending in Attachments 784 There are two types of blending supported when using attachments. 786 * Plain binary encoding with offset (PLAIN). 788 * Embedding with F5 in an image (F5). 790 A node MUST support PLAIN blending for reasons of interoperability, 791 whereas a node MAY support blending using F5. 793 A routing block builder (RBB) MUST take care of sizing restrictions 794 of the transport layer when composing routing blocks 796 6.1.1. PLAIN embedding into attachments 798 A blending layer embeds a VortexMessage in a carrier file with an 799 offset for PLAIN blending. For replacing a file start, a node MUST 800 use the offset 0. The routing node MUST choose the payload file for 801 the message and SHOULD use a credible payload type (e.g., MIMEtype) 802 with high entropy. Furthermore, it SHOULD prefix a valid header 803 structure to avoid easy detection of the Vortex message. Finally, a 804 routing node SHOULD use a valid footer, if any, to a payload file to 805 improve blending. 807 The blended Vortex message is embedded in one or more message chunks, 808 each starting with a chunk header. The chunk header consists of two 809 unsigned integers of variable length. The integer starts with the 810 LSB, and if bit 7 is set, then another byte follows. There cannot be 811 more than four bytes whereas the last, fourth byte is always 8 bit. 812 The three preceding bytes have a payload of seven bits each, which 813 results in a maximum number of 2^29 bits. The first of the extracted 814 numbers (modulo remaining document bytes starting from the first and 815 including byte of the chunk header) reflect the number of bytes in 816 the chunk after the chunk header. The second contains the number of 817 bytes (again modulo remaining document bytes) to be skipped after the 818 current chunk to reach the next chunk. There is no "last chunk" 819 indicator. A gap or chunk may surpass the end of the file. 821 pos: 00h 02h 04h 06h 08h...400h 402h 404h 406h 408h 40Ah 822 val: 01 02 03 04 05 06 07 08 09 ...01 05 0A 0B 0C 0D 0E 0F f0 03 12 13 824 Embedding: "(plain:1024)" 826 Result: 0A 13 (+ 494 omitted bytes; then skip 12 bytes to next chunk) 828 A node SHOULD offer at least one PLAIN blending method and MAY offer 829 multiple offsets for incoming Vortex messages. 831 A plain blending is specified as follows. 833 plainEncoding = "("plain:" 834 [ "," ]* ")" 836 6.1.2. F5 embedding into attachments 838 For F5, a blending layer embeds a Vortex message into a jpeg file 839 according to [F5]. The password for blending may be public, and a 840 routing node MAY advertise multiple passwords. The use of F5 adds 841 approximately tenfold transfer volume to the message. A routing 842 block building node SHOULD only use F5 blending where appropriate. 844 A blending in F5 is specified as the following. 846 f5Encoding = "(F5:" [ "," ]* ")" 848 Commas and backslashes in passwords MUST be escaped with a backslash 849 whereas closing brackets are treated as normal password characters 850 unless they are the final character of the encoding specification 851 string. 853 6.2. Blending into an SMTP layer 855 Email messages with content MUST be encoded with Multipurpose 856 Internet Mail Extensions (MIME) as specified in [RFC2045]. All nodes 857 MUST support BASE64 encoding and MUST test all sections of a MIME 858 message for the presence of a VortexMessage. 860 A Vortex message is present if a block containing the peer key at the 861 known offset of any MIME part decodes correctly. 863 A node SHOULD support SMTP-blending for sending and receiving. For 864 sending SMTP, the specification in [RFC5321] must be used. TLS 865 layers MUST always be applied when obtaining messages using POP3 (as 866 specified in [RFC1939] and [RFC2595]) or IMAP (as specified in 867 [RFC3501]). Any SMTP connection MUST employ a TLS encryption when 868 passing credentials. 870 6.3. Blending into an XMPP layer 872 For interoperability, an implementation SHOULD provide XMPP-blending. 874 Blending into XMPP traffic is performed using the [XEP-0231] 875 extension of the XMPP protocol. 877 PLAIN- and F5-blending are acceptable for this transport layer. 879 7. Routing 881 7.1. Vortex Message Processing 883 7.1.1. Processing of incoming Vortex Messages 885 An incoming message is considered initially unauthenticated. A node 886 should consider a VortexMessage as authenticated as soon as the 887 ephemeral identity is known and is not temporary. 889 For an unauthenticated message, the following rules apply. 891 * A node MUST ignore all routing blocks. 893 * A node MUST ignore all payload blocks. 895 * A node SHOULD accept identity creation requests in unauthenticated 896 messages. 898 * A node MUST ignore all other header requests except identity 899 creation requests. 901 * A node MUST ignore all identity creation requests belonging to an 902 existing identity. 904 A message is considered authenticated as soon as the identity used in 905 the header block is known and not temporary. A node MUST NOT treat a 906 message as authenticated if the specified maximum number of replays 907 is reached. For authenticated messages, the following rules apply. 909 * A node MUST ignore identity creation requests. 911 * A node MUST replace the current reply block with the reply block 912 provided in the routing block (if any). The node MUST keep the 913 reply block if none is provided. 915 * A node SHOULD process all header requests. 917 * A node SHOULD add all routing blocks to the workspace. 919 * A node SHOULD add all payload blocks to the workspace. 921 A routing node MUST decrement the message quota by one if a received 922 message is authenticated, valid, and contains at least one payload 923 block. If a message is identified as a duplicate according to reply 924 protection, then a node MUST NOT decrement the message quota. 926 The message processing works according to the pseudo-code shown 927 below. 929 function incomming_message(VortexMessage blendedMessage) { 930 try{ 931 msg = unblend( blendedMessage ); 932 if( not msg ) { 933 // Abort processing 934 throw exception( "no embedded message found" ) 935 } else { 936 hdr = get_header( msg ) 937 if( not known_identity( hdr.identity ) { 938 if( get_requests( hdr ) contains HeaderRequestIdentity ) { 939 create_new_identity( hdr ).set_temporary( true ) 940 send_message( create_requirement( hdr ) ) 941 } else { 942 // Abort processing 943 throw exception( "identity unknown" ) 944 } 945 } else { 946 if( is_duplicate_or_replayed( msg ) ) { 947 // Abort processing 948 throw exception "duplicate or replayed message" ) 949 } else { 950 if( get_accounting( hdr.identity ).is_temporary() ) { 951 if( not verify_requirement( hdr.identity, msg ) ) { 952 get_accounting( hdr.identity ).set_temporary( false ) 953 } 954 } 955 if( get_accounting( hdr ).is_temporary() ) { 956 throw exception( "no processing on temporary identity" ) 957 } 959 // Message authenticated 960 get_accounting( hdr.identity ) 961 .register_for_replay_protection( msg ) 962 if( not verify_mtching_forward_secrets( msg ) ) { 963 throw exception( "forward secret missmatch" ) 964 } 965 if( contains_payload( msg ) ) { 966 if( get_accounting( hdr.identity 967 .decrement_message_quota() ) { 968 while index,nextPayloadBlock 969 == get_next_payload_block( msg ) { 970 add_workspace( header.identity, 971 index, nextPayloadBlock ) 972 } 973 while nextRoutingBlock = get_next_routing_block( msg ) { 974 add_workspace( hdr.identity, 975 add_routing( nextRoutingBlock ) ) 976 } 977 process_reserved_mapping_space( msg ) 978 while nextRequirement = get_next_requirement( hdr ) { 979 add_workspace( hdr.identity, nextRequirement ) 980 } 981 } else { 982 throw exception( "Message quota exceeded" ) 983 } 984 } 985 } 986 } 987 } catch( exception e ) { 988 // Message processing failed 989 throw e; 990 } 991 } 993 7.1.2. Processing of Routing Blocks in the Workspace 995 A routing workspace consists of the following items. 997 * The linked identity, which determines the lifetime of the 998 workspace. 1000 * The linked routing combos (RoutingCombo). 1002 * A payload chunk space with the following multiple subspaces 1003 available: 1005 - ID 0 represents a message to be embedded (when reading) or a 1006 message to be extracted to the user (when written). 1008 - ID 1 to ID maxPayloadBlocks represent the payload chunk slots 1009 in the target message. 1011 - All blocks between ID maxPayloadBlocks + 1 to ID 32766 belong 1012 to a temporary routing block-specific space. 1014 - ID 32767 MUST be used to signal a solicited reply block. 1016 - All blocks between ID 32768 to ID 65535 belong to a shared 1017 space available to all operations of the identity. 1019 The accounting layer typically triggers processing and represents 1020 either a cleanup action or a routing event. A cleanup event deletes 1021 the following information from all workspaces. 1023 * All processed routing combos. 1025 * All routing combos with expired usagePeriod. 1027 * All payload chunks exceeding the maxProcess time. 1029 * All expired objects. 1031 * All expired puzzles. 1033 * All expired identities. 1035 * All expired replay protections. 1037 Note that maxProcessTime reflects the number of seconds since the 1038 arrival of the last octet of the message at the transport layer 1039 facility. A node SHOULD NOT take additional processing time (e.g., 1040 for anti-UBE or anti-virus) into account. 1042 The accounting layer triggers routing events occurring at least the 1043 minProcessTime after the last octet of the message arrived at the 1044 routing layer. A node SHOULD choose the latest possible moment at 1045 which the peer node receives the last octet of the assembled message 1046 before the maxProcessTime is reached. The calculation of this last 1047 point in time where a message may be set SHOULD always assume that 1048 the target node is working. A sending node SHOULD choose the time 1049 within these bounds randomly. An accounting layer MAY trigger 1050 multiple routing combos in bulk to further obfuscate the identity of 1051 a single transport message. 1053 First, the processing node escapes the payload chunk at ID 0 if 1054 needed (e.g., a non-special block is starting with a backslash). 1055 Next, it executes all processing instructions of the routing combo in 1056 the specified sequence. If an instruction fails, then the block at 1057 the target ID of the operation remains unchanged. The routing layer 1058 proceeds with the subsequent processing instructions by ignoring the 1059 error. For a detailed description of the operations, see 1060 Section 7.4. If a node succeeds in building at least one payload 1061 chunk, then a VortexMessage is composed and passed to the blending 1062 layer. 1064 7.1.3. Processing of Outgoing Vortex Messages 1066 The blending layer MUST compose a transport layer message according 1067 to the specification provided in the routing combo. It SHOULD choose 1068 any decoy message or steganographic carrier in such a way that the 1069 Dead Parrot syndrome, as specified in [DeadParrot], is avoided. 1071 7.2. Header Requests 1073 Header requests are control requests for the anonymization system. 1074 Messages with requests or replies only MUST NOT affect any quota. 1076 7.2.1. Request New Ephemeral Identity 1078 Requesting a new ephemeral identity is performed by sending a message 1079 containing a header block with the new identity and an identity 1080 creation request (HeaderRequestIdentity) to a node. The node MAY 1081 send an error block (see Section 7.3.1) if it rejects the request. 1083 If a node accepts an identity creation request, then it MUST send a 1084 reply. A node accepting a request without a requirement MUST send 1085 back a special block containing "no error". A node accepting a 1086 request under the precondition of a requirement to be fulfilled MUST 1087 send a special block containing a requirement block. 1089 A node SHOULD NOT reply to any cleartext requests if the node does 1090 not want to officially disclose its identity as a Vortex node. A 1091 node MUST reply with an error block if a valid identity is used for 1092 the request. 1094 7.2.2. Request Message Quota 1096 Any valid ephemeral identity may request an increase of the current 1097 message quota to a specific value at any time. The request MUST 1098 include a reply block in the header and may contain other parts. If 1099 a requested value is lower than the current quota, then the node 1100 SHOULD NOT refuse the quota request and SHOULD send a "no error" 1101 status. 1103 A node SHOULD reply to a HeaderRequestIncreaseMessageQuota request 1104 (see Appendix A) of a valid ephemera identity. The reply MUST 1105 include a requirement, an error message or a "no error" status 1106 message. 1108 7.2.3. Request Increase of Message Quota 1110 A node may request to increase the current message quota by sending a 1111 HeaderRequestIncreaseMessageQuota request to the routing node. The 1112 value specified within the node is the new quota. 1113 HeaderRequestIncreaseMessageQuota requests MUST include a reply 1114 block, and a node SHOULD NOT use a previously sent MURB to reply. 1116 If the requested quota is higher than the current quota, then the 1117 node SHOULD send a "no error" reply. If the requested quota is not 1118 accepted, then the node SHOULD send a requestedQuotaOutOfBand reply. 1120 A node accepting the request MUST send a RequirementBlock or a "no 1121 error block." 1123 7.2.4. Request Transfer Quota 1125 Any valid ephemeral identity may request to increase the current 1126 transfer quota to a specific value at any time. The request MUST 1127 include a reply block in the header and may contain other parts. If 1128 a requested value is lower than the current quota, then the node 1129 SHOULD NOT refuse the quota request and SHOULD send a "no error" 1130 status. 1132 A node SHOULD reply to a eaderRequestIncreaseTransferQuota request 1133 (see Appendix A) of a valid ephemeral identity. The reply MUST 1134 include a requirement, an error message or a "no error" status 1135 message. 1137 7.2.5. Query Quota 1139 Any valid ephemeral identity may request the current message and 1140 transfer quota. The request MUST include a reply block in the header 1141 and may contain other parts. 1143 A node MUST reply to a HeaderRequestQueryQuota request (see 1144 Appendix A), which MUST include the current message quota and the 1145 current message transfer quota. The reply to this request MUST NOT 1146 include a requirement. 1148 7.2.6. Request Capabilities 1150 Any node MAY request the capabilities of another node, which include 1151 all information necessary to create a parsable VortexMessage. Any 1152 node SHOULD reply to any encrypted HeaderRequestCapability. 1154 A node SHOULD NOT reply to cleartext requests if the node does not 1155 want to officially disclose its identity as a Vortex node. A node 1156 MUST reply if a valid identity is used for the request, and it MAY 1157 reply to unknown identities. 1159 7.2.7. Request Nodes 1161 A node may ask another node for a list of routing node addresses and 1162 keys, which may be used to bootstrap a new node and add routing nodes 1163 to increase the anonymization of a node. The receiving node of such 1164 a request SHOULD reply with a requirement 1165 (e.g.,RequirementPuzzleRequired). 1167 A node MAY reply to a HeaderRequest request (see Appendix A) of a 1168 valid ephemeral identity, and the reply MUST include a requirement, 1169 an error message, or a "no error" status message. A node MUST NOT 1170 reply to an unknown identity and SHOULD always reply with the same 1171 result set to the same identity. 1173 7.2.8. Request Identity Replace 1175 This request type allows a receiving node to replace an existing 1176 identity with the identity provided in the message and is required if 1177 an adversary manages to deny the usage of a node (e.g., by deleting 1178 the corresponding transport account). Any sending node may recover 1179 from such an attack by sending a valid authenticated message to 1180 another identity to provide the new transport and key details. 1182 A node SHOULD reply to such a request from a valid known identity, 1183 and the reply MUST include an error message or a "no error" status 1184 message. 1186 7.2.9. Request Upgrade 1188 This request type allows a node to request a new version of the 1189 software in an anonymous, unlinked manor. The identifier MUST 1190 identify the software product uniquely. The version MUST reflect the 1191 version tag of the currently installed version or a similarly usable 1192 tag. 1194 7.3. Special Blocks 1196 Special blocks are payload messages that reflect messages from one 1197 node to another and are not visible to the user. A special block 1198 starts with the character sequence '\special' (or 5Ch 73h 70h 65h 63h 1199 69h 61h 6Ch) followed by a DER-encoded special block (SpecialBlock). 1200 Any non-special message decoding to ID 0 in a workspace starting with 1201 this character sequence MUST escape all backslashes within the 1202 payload chunk with an additional backslash. 1204 7.3.1. Error Block 1206 An error block may be sent as a reply contained in the payload 1207 section. The error block is embedded in a special block and sent 1208 with any provided reply block. Error messages SHOULD contain the 1209 serial number of the offending header block and MAY contain human- 1210 readable text providing additional messages about the error. 1212 7.3.2. Requirement Block 1214 If a node receives a requirement block, then it MUST assume that the 1215 request block is accepted, is not yet processed, and is to be 1216 processed if it meets the contained requirement. A node MUST process 1217 a request as soon as the requirement is fulfilled and MUST resend the 1218 request as soon as it meets the requirement. 1220 A node MAY reject a request, accept a request without a requirement, 1221 accept a request upon payment (RequirementPaymentRequired), or accept 1222 a request upon solving a proof of work puzzle 1223 (RequirementPuzzleRequired). 1225 7.3.2.1. Puzzle Requirement 1227 If a node requests a puzzle, then it MUST send a 1228 RequirementPuzzleRequired block. The puzzle requirement is solved if 1229 the node receiving the puzzle replies with a header block that 1230 contains the puzzle block, and the hash of the encoded block begins 1231 with the bit sequence mentioned in the puzzle within the period 1232 specified in the field 'valid.' 1234 A node solving a puzzle requires sending a VortexMessage to the 1235 requesting node, which MUST contain a header block that includes the 1236 puzzle block and MUST have a MAC fingerprint starting with the bit 1237 sequence as specified in the challenge. The receiving node 1238 calculates the MAC from the unencrypted DER-encoded HeaderBlock with 1239 the algorithm specified by the node. The sending node may achieve 1240 the requirement by adding a proofOfWork field to the HeaderBlock 1241 containing any content fulfilling the criteria. The sending node 1242 SHOULD keep the proofOfWork field as short as possible. 1244 7.3.2.2. Payment Requirement 1246 If a node requests a payment, then it MUST send a 1247 RequirementPaymentRequired block. As soon as the requested fee is 1248 paid and confirmed, the requesting node MUST send a "no error" status 1249 message. The usage period 'valid' describes the period during which 1250 the payment may be carried out. A node MUST accept the payment if it 1251 occurs within the 'valid' period but is confirmed later. A node 1252 SHOULD return all unsolicited payments to the sending address. 1254 7.3.2.3. Upgrade 1256 If a node requests an upgrade, a ReplyUpgrade block MAY be sent. The 1257 block must contain the identifier and version of the most recent 1258 software version. The blob MAY contain the software if there is a 1259 newer one available. 1261 7.4. Routing Operations 1263 Routing operations are contained in a routing block and processed 1264 upon arrival of a message or when compiling a new message. All 1265 operations are reversible, and no operation is available for 1266 generating decoy traffic, which may be used through encryption of an 1267 unpadded block or the addRedundancy operation. 1269 All payload chunk blocks inherit the validity time from the message 1270 routing combos as arrival time + max(maxProcessTime). 1272 When applying an operation to a source block, the resulting target 1273 block inherits the expiration of the source block. When multiple 1274 expiration times exist, the one furthest in the future is applied to 1275 the target block. If the operation fails, then the target expiration 1276 remains unchanged. 1278 7.4.1. Mapping Operation 1280 The straightforward mapping operation is used in inOperations of a 1281 routing block to map the routing block's specific blocks to a 1282 permanent workspace. 1284 7.4.2. Split and Merge Operations 1286 The split and merge operations allow splitting and recombining 1287 message chunks. A node MUST adhere to the following constraints. 1289 * The operation must be applied at an absolute (measuring in bytes) 1290 or relative (measured as a float value in the range 0>value>100) 1291 position. 1293 * All calculations must be performed according to IEEE 754 [IEEE754] 1294 and in 64-bit precision. 1296 * If a relative value is a non-integer result, then a floor 1297 operation (i.e., cutting off all non-integer parts) determines the 1298 number of bytes. 1300 * If an absolute value is negative, then the size represents the 1301 number of bytes counted from the end of the message chunk. 1303 * If an absolute value is greater than the number of bytes in a 1304 block, then all bytes are mapped to the respective target block, 1305 and the other target block becomes a zero byte-sized block. 1307 An operation MUST fail if relative values are equal to, or less than 1308 zero. An operation MUST fail if a relative value is equal to, or 1309 greater than 100. All floating-point operations must be performed 1310 according to [IEEE754] and in 64-bit precision. 1312 7.4.3. Encrypt and Decrypt Operations 1314 Encryption and decryption are executed according to the standards 1315 mentioned above. An encryption operation encrypts a block 1316 symmetrically and places the result in the target block. The 1317 parameters MUST contain IV, padding, and cipher modes. An encryption 1318 operation without a valid parameter set MUST fail. 1320 7.4.4. Add and Remove Redundancy Operations 1322 The addRedundancy and removeRedundancy operations are core to the 1323 protocol. They may be used to split messages and distribute message 1324 content across multiple routing nodes. The operation is separated 1325 into three steps. 1327 1. Pad the input block to a multiple of the key block size in the 1328 resulting output blocks. 1330 2. Apply a Vandermonde matrix with the given sizes. 1332 3. Encrypt each resulting block with a separate key. 1334 The following sections describe the order of the operations within an 1335 addRedundancy operation. For a removeRedundancy operation, invert 1336 the functions and order. If the removeRedundancy has more than the 1337 required blocks to recover the information, then it should take only 1338 the required number beginning from the smallest. If a seed and PRNG 1339 are provided, then the removeRedundancy operation MAY test any 1340 combination until recovery is successful. 1342 7.4.4.1. Padding Operation 1344 Padding is done in multiple steps. First, we calculate the padding 1345 value p. We then concatenate the padding value p as 32-bit little- 1346 endian unit with the message and fill the remaining bytes required 1347 with the seeded PRNG. 1349 A processing node calculates the final length of all payload blocks, 1350 including redundancy. This is done in three steps, followed by the 1351 calculation of the padding value p. 1353 1. i=len() [calculate the size of the input block] 1354 2. e=lcm(,<# of output 1355 blocks>) [Calculate Minimum size of the output block] 1357 3. l=roof((i+4+C2)/e)*e [Calculate the final length of the padded 1358 stream suitable for the subsequent operations. C2 is a constant 1359 which is either provided by the RBB or 0 if not specified.] 1361 4. p=i+(C1*l(mod (roof((2^32-1-i)/l)*))) [Calculate padding value p. 1362 C1 is a positive integer constant and MUST be provided by the RBB 1363 to maintain diagnosability.] 1365 The remainder of the input block, up to length L, is padded with 1366 random data. A routing block builder should specify the value of the 1367 randomInteger. If not specified, the routing node may choose a 1368 random positive integer value. A routing block builder SHOULD 1369 specify a PRNG and a seed used for this padding. If GF(16) is 1370 applied, then all numbers are treated as little-endian 1371 representations. Only GF(8) and GF(16) are allowed fields. 1373 The length of 0 is a valid length 1375 This padding guarantees that each resulting block matches the block 1376 size of the subsequent encryption operation and does not require 1377 further padding. 1379 For padding removal, the padding p at the start is first removed as a 1380 little-endian integer. Second, the length of the output block is 1381 calculated by applying =p (mod -4) 1384 7.4.4.2. Apply Matrix 1386 Next, the input block is organized in a data matrix D of dimensions 1387 (inrows, incols) where incols=(-) and inrows=L/(-). The input block data is first distributed in 1390 this matrix across, and then down. 1392 Next, the data matrix D is multiplied by a Vandermonde matrix V with 1393 its number of rows equal to the incols calculated and columns equal 1394 to the . The content of the matrix is formed 1395 by v(i,j)=pow(i,j), where i reflects the row number starting at 0, 1396 and j reflects the column number starting at 0. The calculations 1397 described must be carried out in the GF noted in the respective 1398 operation to be successful. The completed operation results in 1399 matrix A. 1401 7.4.4.3. Encrypt Target Block 1403 Each row vector of A is a new data block encrypted with the 1404 corresponding encryption key noted in the keys of the 1405 addRedundancyOperation. If there are not enough keys available, then 1406 the keys used for encryption are reused from the beginning after the 1407 final key is used. A routing block builder SHOULD provide enough 1408 keys so that all target blocks may be encrypted with a unique key. 1409 All encryptions SHOULD NOT use padding. 1411 7.5. Processing of Vortex Messages 1413 The accounting layer triggers processing according to the information 1414 contained in a routing block in the workspace. All operations MUST 1415 be executed in the sequence provided in the routing block, and any 1416 failing operation must leave the result block unmodified. 1418 All workspace blocks resulting in IDs of 1 to maxPayloadBlock are 1419 then added to the message and passed to the blending layer with 1420 appropriate instructions. 1422 8. Accounting 1424 8.1. Accounting Operations 1426 The accounting layer has two types of operations. 1428 * Time-based (e.g., cleanup jobs and initiation of routing). 1430 * Routing triggered (e.g., updating quotas, authorizing operations, 1431 and pickup of incoming messages). 1433 Implementations MUST provide sufficient locking mechanisms to 1434 guarantee the integrity of accounting information and the workspace 1435 at any time. 1437 8.1.1. Time-Based Garbage Collection 1439 The accounting layer SHOULD keep a list of expiration times. As soon 1440 as an entry (e.g., payload block or identity) expires, the respective 1441 structure should be removed from the workspace. An implementation 1442 MAY choose to remove expired items periodically or when encountering 1443 them during normal operation. 1445 8.1.2. Time-Based Routing Initiation 1447 The accounting layer MAY keep a list of when a routing block is 1448 activated. For improved privacy, the accounting layer should use a 1449 slotted model where, whenever possible, multiple routing blocks are 1450 handled in the same period, and the requests to the blending layers 1451 are mixed between the transactions. 1453 8.1.3. Routing Based Quota Updates 1455 A node MUST update quotas on the respective operations. For example, 1456 a node MUST decrease the message quota before processing routing 1457 blocks in the workspace and after the processing of header requests. 1459 8.1.4. Routing Based Authorization 1461 The transfer quota MUST be checked and decreased by the number of 1462 data bytes in the payload chunks after an outgoing message is 1463 processed and fully assembled. The message quota MUST be decreased 1464 by one on each routing block triggering the assembly of an outgoing 1465 message. 1467 8.1.5. Ephemeral Identity Creation 1469 Any packet may request the creation of an ephemeral identity. A node 1470 SHOULD NOT accept such a request without a costly requirement since 1471 the request includes a lifetime of the ephemeral identity. The costs 1472 for creating the ephemeral identity SHOULD increase if a longer 1473 lifetime is requested. 1475 9. Acknowledgments 1477 Thanks go to my family who supported me with patience and countless 1478 hours as well as to Mark Zeman for his feedback challenging my 1479 thoughts and peace. %FIXME is this in the correct place? 1481 10. IANA Considerations 1483 This memo includes no request to IANA. 1485 Additional encryption algorithms, paddings, modes, blending layers or 1486 puzzles MUST be added by writing an extension to this or a subsequent 1487 RFC. For testing purposes, IDs above 1,000,000 should be used. 1489 11. Security Considerations 1491 The MessageVortex protocol should be understood as a toolset instead 1492 of a fixed product. Depending on the usage of the toolset, anonymity 1493 and security are affected. For a detailed analysis, see 1494 [MVAnalysis]. 1496 The primary goals for security within this protocol rely on the 1497 following focus areas. 1499 * Confidentiality 1501 * Integrity 1503 * Availability 1505 * Anonymity 1507 - Third-party anonymity 1509 - Sender anonymity 1511 - Receiver anonymity 1513 These aspects are affected by the usage of the protocol, and the 1514 following sections provide additional information on how they impact 1515 the primary goals. 1517 The Vortex protocol does not rely on any encryption of the transport 1518 layer since Vortex messages are already encrypted. In addition, 1519 confidentiality is not affected by the protection mechanisms of the 1520 transport layer. 1522 If a transport layer supports encryption, then a Vortex node SHOULD 1523 use it to improve the privacy of the message. 1525 Anonymity is affected by the inner workings of the blending layer in 1526 many ways. A Vortex message cannot be read by anyone except the peer 1527 nodes and routing block builder. The presence of a Vortex node 1528 message may be detected through the typical high entropy of an 1529 encrypted file, broken structures of a carrier file, meaningless 1530 content of a carrier file, or the contextless communication of the 1531 transport layer with its peer partner. A blending layer SHOULD 1532 minimize the possibility of simple detection by minimizing these 1533 effects. 1535 A blending layer SHOULD use carrier files with high compression or 1536 encryption. Carrier files SHOULD NOT have inner structures such that 1537 the payload is comparable to valid content. To achieve 1538 undetectability by a human reviewer, a routing block builder should 1539 use F5 instead of PLAIN blending. This approach however, increases 1540 the protocol overhead by approximately tenfold. 1542 The two layers of 'routing' and 'accounting' have the deepest insight 1543 into a Vortex message's inner workings. Each is aware of the 1544 immediate peer sender and the peer recipients of all payload chunks. 1545 As decoy traffic is generated by combining chunks and applying 1546 redundancy calculations, a node can never know if a malfunction 1547 (e.g., during a recovery calculation) was intended. Therefore, a 1548 node is unable to distinguish a failed transaction from a terminated 1549 transaction as well as content from decoy traffic. 1551 A routing block builder SHOULD follow the following rules not to 1552 compromise a Vortex message's anonymity. 1554 * All operations applied SHOULD be credibly involved in a message 1555 transfer. 1557 * A sufficient subset of the result of an addRedundancy operation 1558 should always be sent to peers to allow recovery of the data 1559 built. 1561 * The anonymity set of a message should be sufficiently large to 1562 avoid legal prosecution of all jurisdictional entities involved, 1563 even if a certain amount of the anonymity set cooperates with an 1564 adversary. 1566 * Encryption and decryption SHOULD follow normal usage whenever 1567 possible by avoiding the encryption of a block on a node with one 1568 key and decrypting it with a different key on the same or adjacent 1569 node. 1571 * Traffic peaks SHOULD be uniformly distributed within the entire 1572 anonymity set. 1574 * A routing block SHOULD be used for a limited number of messages. 1575 If used as a message block for the node, then it should be used 1576 only once. A block builder SHOULD use the 1577 HeaderRequestReplaceIdentity block to update the reply to routing 1578 blocks regularly. Implementers should always remember that the 1579 same routing block is identifiable by its structure. 1581 An active adversary cannot use blocks from other routing block 1582 builders. While the adversary may falsify the result by injecting an 1583 incorrect message chunk or not sending a message, such message 1584 disruptions may be detected by intentionally routing information to 1585 the routing block builder (RBB) node. If the Vortex message does not 1586 carry the information expected, then the node may safely assume that 1587 one of the involved nodes is misbehaving. A block building node MAY 1588 calculate the reputation for involved nodes over time and MAY build 1589 redundancy paths into a routing block to withstand such malicious 1590 nodes. 1592 Receiver anonymity is at risk if the handling of the message header 1593 and content is not done with care. An attacker might send a bugged 1594 message (e.g., with a DKIM header) to de-anonymize a recipient. 1595 Careful attention is required when handling anything other than local 1596 references when processing, verifying or rendering a message. 1598 12. References 1600 12.1. Normative References 1602 [CCITT.X208.1988] 1603 International Telephone and Telegraph Consultative 1604 Committee, "Specification of Abstract Syntax Notation One 1605 (ASN.1)", CCITT Recommendation X.208, November 1998. 1607 [CCITT.X680.2002] 1608 International Telephone and Telegraph Consultative 1609 Committee, "Abstract Syntax Notation One (ASN.1): 1610 Specification of Basic Notation", November 2002. 1612 [EAX] Bellare, M., Rogaway, P., and D. Wagner, "The EAX Mode of 1613 Operation", 2011. 1615 [F5] Westfeld, A., "F5 - A Steganographic Algorithm - High 1616 Capacity Despite Better Steganalysis", 24 October 2001. 1618 [FIPS-AES] Federal Information Processing Standard (FIPS), 1619 "Specification for the ADVANCED ENCRYPTION STANDARD 1620 (AES)", November 2011. 1622 [IEEE754] IEEE, "754-2008 - IEEE Standard for Floating-Point 1623 Arithmetic", 29 August 2008. 1625 [ISO-10118-3] 1626 International Organization for Standardization, "ISO/IEC 1627 10118-3:2004 -- Information Technology -- Security 1628 Techniques -- Hash-Functions -- Part 3: Dedicated Hash- 1629 Functions", March 2004. 1631 [MODES] National Institute for Standards and Technology (NIST), 1632 "Recommendation for Block Cipher Modes of Operation: 1633 Methods and Techniques", December 2001. 1635 [RFC1423] Balenson, D., "Privacy Enhancement for Internet Electronic 1636 Mail: Part III: Algorithms, Modes, and Identifiers", 1637 RFC 1423, DOI 10.17487/RFC1423, February 1993, 1638 . 1640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1641 Requirement Levels", BCP 14, RFC 2119, 1642 DOI 10.17487/RFC2119, March 1997, 1643 . 1645 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1646 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 1647 2003, . 1649 [RFC3657] Moriai, S. and A. Kato, "Use of the Camellia Encryption 1650 Algorithm in Cryptographic Message Syntax (CMS)", 1651 RFC 3657, DOI 10.17487/RFC3657, January 2004, 1652 . 1654 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 1655 Counter Mode With IPsec Encapsulating Security Payload 1656 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 1657 . 1659 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1660 Specifications: ABNF", STD 68, RFC 5234, 1661 DOI 10.17487/RFC5234, January 2008, 1662 . 1664 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1665 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1666 DOI 10.17487/RFC5288, August 2008, 1667 . 1669 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1670 DOI 10.17487/RFC5958, August 2010, 1671 . 1673 [RFC7253] Krovetz, T. and P. Rogaway, "The OCB Authenticated- 1674 Encryption Algorithm", RFC 7253, DOI 10.17487/RFC7253, May 1675 2014, . 1677 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1678 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1679 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1680 . 1682 [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", 1683 21 May 2009. 1685 [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 1686 128-Bit Block Cipher, 1st Edition", March 1999. 1688 [XEP-0231] Peter, S.A. and P. Simerda, "XEP-0231: Bits of Binary", 3 1689 September 2008, 1690 . 1692 12.2. Informative References 1694 [DeadParrot] 1695 Houmansadr, A., Burbaker, C., and V. Shmatikov, "The 1696 Parrot is Dead: Observing Unobservable Network 1697 Communications", 2013, 1698 . 1700 [KAnon] Ahn, L., Bortz, A., and N.J. Hopper, "k-Anonymous Message 1701 Transmission", 2003. 1703 [MVAnalysis] 1704 Gwerder, M., "MessageVortex", 2018, 1705 . 1707 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1708 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 1709 . 1711 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1712 Extensions (MIME) Part One: Format of Internet Message 1713 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1714 . 1716 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1717 RFC 2595, DOI 10.17487/RFC2595, June 1999, 1718 . 1720 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1721 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 1722 . 1724 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1725 DOI 10.17487/RFC5321, October 2008, 1726 . 1728 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 1729 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1730 March 2011, . 1732 Appendix A. The ASN.1 schema for Vortex messages 1734 The following sections contain the ASN.1 modules specifying the 1735 MessageVortex Protocol. 1737 A.1. The Main MessageVortex Blocks 1739 MessageVortex-Schema DEFINITIONS EXPLICIT TAGS ::= 1740 BEGIN 1741 EXPORTS PrefixBlock, InnerMessageBlock, RoutingBlock, 1742 maxWorkspaceID; 1743 IMPORTS SymmetricKey, AsymmetricKey, MacAlgorithmSpec, CipherSpec 1744 FROM MessageVortex-Ciphers 1745 HeaderRequest 1746 FROM MessageVortex-Requests 1747 PayloadOperation, MapBlockOperation 1748 FROM MessageVortex-Operations 1750 UsagePeriod, BlendingSpec 1751 FROM MessageVortex-Helpers; 1753 --*************************************************************** 1754 -- Constant definitions 1755 --*************************************************************** 1756 -- maximum serial number 1757 maxSerial INTEGER ::= 4294967295 1758 -- maximum number of administrative requests 1759 maxNumOfRequests INTEGER ::= 8 1760 -- maximum number of seconds which the message might be delayed 1761 -- in the local queue (starting from startOffset) 1762 maxDurationOfProcessing INTEGER ::= 86400 1763 -- maximum id of an operation 1764 minWorkspaceID INTEGER ::= 32768 1765 -- maximum number of routing blocks in a message 1766 maxRoutingBlks INTEGER ::= 127 1767 -- maximum number a block may be replayed 1768 maxNumOfReplays INTEGER ::= 127 1769 -- maximum number of payload chunks in a message 1770 maxPayloadBlks INTEGER ::= 127 1771 -- maximum number of seconds a proof of non revocation may be old 1772 maxTimeCachedProof INTEGER ::= 86400 1773 -- The maximum ID of the workspace 1774 maxWorkspaceId INTEGER ::= 65535 1775 -- The maximum number of assembly instructions per combo 1776 maxAssemblyInstr INTEGER ::= 255 1778 --*************************************************************** 1779 -- Types 1780 --*************************************************************** 1781 PuzzleIdentifier ::= OCTET STRING ( SIZE(0..32) ) 1782 ChainSecret ::= OCTET STRING (SIZE (16..64)) 1784 --*************************************************************** 1785 -- Block Definitions 1786 --*************************************************************** 1787 PrefixBlock ::= SEQUENCE { 1788 version [0] INTEGER OPTIONAL, 1789 key [2] SymmetricKey 1790 } 1792 InnerMessageBlock ::= SEQUENCE { 1793 padding OCTET STRING, 1794 prefix CHOICE { 1795 plain [11011] PrefixBlock, 1796 -- contains prefix encrypted with receivers 1797 -- public key 1798 encrypted [11012] OCTET STRING 1799 }, 1800 header CHOICE { 1801 -- debug/internal use only 1802 plain [11021] HeaderBlock, 1803 -- contains encrypted identity block 1804 encyrpted [11022] OCTET STRING 1805 }, 1806 -- contains signature of Identity [as stored in 1807 -- HeaderBlock; signed unencrypted HeaderBlock without 1808 -- Tag] 1809 identitySignature OCTET STRING, 1810 -- contains routing information (next hop) for the 1811 -- payloads 1812 routing [11001] CHOICE { 1813 plain [11031] RoutingBlock, 1814 -- contains encrypted routing block 1815 encyrpted [11032] OCTET STRING 1816 }, 1817 -- contains the actual payload 1818 payload SEQUENCE (SIZE (0..maxPayloadBlks)) 1819 OF OCTET STRING 1820 } 1822 HeaderBlock ::= SEQUENCE { 1823 -- Public key of the identity representing this 1824 -- transmission 1825 identityKey AsymmetricKey, 1826 -- serial identifying this block 1827 serial INTEGER (0..maxSerial), 1828 -- number of times this block may be replayed 1829 -- (Tuple is identityKey, serial while 1830 -- UsagePeriod of block) 1831 maxReplays INTEGER (0..maxNumOfReplays), 1832 -- subsequent Blocks are not processed before 1833 -- valid time. 1834 -- Host may reject too long retention. 1835 -- Recomended validity support >=1Mt. 1836 valid UsagePeriod, 1837 -- contains the MAC-Algorithm used for signing 1838 signAlgorithm MacAlgorithmSpec, 1839 -- contains administrative requests such as 1840 -- quota requests 1841 requests SEQUENCE 1842 (SIZE (0..maxNumOfRequests)) 1843 OF HeaderRequest , 1844 -- Reply Block for the requests 1845 requestReplyBlock RoutingCombo OPTIONAL, 1846 -- padding and identitifier required to solve 1847 -- the cryptopuzzle 1848 identifier [12201] PuzzleIdentifier OPTIONAL, 1849 -- This is for solving crypto puzzles 1850 proofOfWork[12202] OCTET STRING OPTIONAL 1851 } 1853 RoutingBlock ::= SEQUENCE { 1854 -- contains the routingCombos 1855 routing [331] SEQUENCE 1856 (SIZE (0..maxRoutingBlks)) 1857 OF RoutingCombo, 1858 -- contains the mapping operations to map 1859 -- payloads to the workspace 1860 mappings [332] SEQUENCE 1861 (SIZE (0..maxPayloadBlks)) 1862 OF MapBlockOperation, 1864 -- contains a routing block which may be used 1865 -- when sending error messages back to the quota 1866 -- owner this routing block may be cached for 1867 -- future use 1868 replyBlock [332] SEQUENCE { 1869 murb RoutingCombo, 1870 maxReplay INTEGER, 1871 validity UsagePeriod 1872 } OPTIONAL 1873 } 1875 RoutingCombo ::= SEQUENCE { 1876 -- contains the period when the payload should 1877 -- be processed. 1878 -- Router might refuse too long queue retention 1879 -- Recommended support for retention >=1h 1880 minProcessTime INTEGER 1881 (0..maxDurationOfProcessing), 1882 maxProcessTime INTEGER 1883 (0..maxDurationOfProcessing), 1884 -- The message key to encrypt the message 1885 peerKey [401] SEQUENCE 1886 (SIZE (1..maxNumOfReplays)) 1887 OF SymmetricKey OPTIONAL, 1888 -- contains the next recipient 1889 recipient [402] BlendingSpec, 1890 -- PrefixBlock encrypted with message key 1891 mPrefix [403] SEQUENCE 1892 (SIZE (1..maxNumOfReplays)) 1893 OF OCTET STRING OPTIONAL, 1894 -- PrefixBlock encrypted with sender key 1895 cPrefix [404] OCTET STRING OPTIONAL, 1896 -- HeaderBlock encrypted with sender key 1897 header [405] OCTET STRING OPTIONAL, 1898 -- RoutingBlock encrypted with sender key 1899 routing [406] OCTET STRING OPTIONAL, 1900 -- contains information for building messages 1901 -- (when used as MURB) 1902 -- ID 0 denotes original/local message 1903 -- ID 1-maxPayloadBlks denotes target message 1904 -- ID 32767 denotes a solicited reply block 1905 -- 32768-maxWorkspaceId shared workspace for all 1906 -- blocks of this identity) 1907 assembly [407] SEQUENCE 1908 (SIZE (0..maxAssemblyInstr)) 1909 OF PayloadOperation, 1910 -- optional for storage of the arrival time 1911 validity [408] UsagePeriod OPTIONAL 1913 } 1915 END 1917 A.2. The MessageVortex Ciphers Structures 1919 MessageVortex-Ciphers DEFINITIONS EXPLICIT TAGS ::= 1920 BEGIN 1921 EXPORTS SymmetricKey, AsymmetricKey, MacAlgorithmSpec, 1922 MacAlgorithm, CipherSpec, PRNGType; 1924 CipherSpec ::= SEQUENCE { 1925 asymmetric [16001] AsymAlgSpec OPTIONAL, 1926 symmetric [16002] SymAlgSpec OPTIONAL, 1927 mac [16003] MacAlgorithmSpec OPTIONAL, 1928 cipherUsage [16004] CipherUsage 1929 } 1931 CipherUsage ::= ENUMERATED { 1932 sign (200), 1933 encrypt (210) 1934 } 1936 SymAlgSpec ::= SEQUENCE { 1937 algorithm [16101]SymmetricAlgorithm, 1938 -- if ommited: pkcs7 1939 padding [16102]CipherPadding OPTIONAL, 1940 -- if ommited: cbc 1941 mode [16103]CipherMode OPTIONAL, 1942 parameter [16104]AlgParameters OPTIONAL 1943 } 1945 AsymAlgSpec ::= SEQUENCE { 1946 algorithm AsymmetricAlgorithm, 1947 -- if ommited: pkcs1 1948 padding [16102]CipherPadding OPTIONAL, 1949 parameter AlgParameters OPTIONAL 1950 } 1952 SymmetricKey ::= SEQUENCE { 1953 keyType SymmetricAlgorithm, 1954 parameter AlgParameters, 1955 key OCTET STRING (SIZE(16..512)) 1956 } 1958 AsymmetricKey ::= SEQUENCE { 1959 keyType AsymmetricAlgorithm, 1960 -- private key encoded as PKCS#8/PrivateKeyInfo 1961 publicKey [2] OCTET STRING, 1962 -- private key encoded as 1963 -- X.509/SubjectPublicKeyInfo 1964 privateKey [3] OCTET STRING OPTIONAL 1965 } 1967 SymmetricAlgorithm ::= ENUMERATED { 1968 aes128 (1000), -- required 1969 aes192 (1001), -- optional support 1970 aes256 (1002), -- required 1971 camellia128 (1100), -- required 1972 camellia192 (1101), -- optional support 1973 camellia256 (1102), -- required 1974 twofish128 (1200), -- optional support 1975 twofish192 (1201), -- optional support 1976 twofish256 (1202) -- optional support 1977 } 1979 AsymmetricAlgorithm ::= ENUMERATED { 1980 rsa (2000), 1981 dsa (2100), 1982 ec (2200), 1983 ntru (2300) 1984 } 1985 ECCurveType ::= ENUMERATED{ 1986 secp384r1 (2500), 1987 sect409k1 (2501), 1988 secp521r1 (2502) 1989 } 1990 AlgParameters ::= SEQUENCE { 1991 keySize [9000] INTEGER (0..65535) OPTIONAL, 1992 curveType [9001] ECCurveType OPTIONAL, 1993 iv [9002] OCTET STRING OPTIONAL, 1994 nonce [9003] OCTET STRING OPTIONAL, 1995 mode [9004] CipherMode OPTIONAL, 1996 padding [9005] CipherPadding OPTIONAL, 1997 n [9010] INTEGER OPTIONAL, 1998 p [9011] INTEGER OPTIONAL, 1999 q [9012] INTEGER OPTIONAL, 2000 k [9013] INTEGER OPTIONAL, 2001 t [9014] INTEGER OPTIONAL 2002 } 2004 CipherMode ::= ENUMERATED { 2005 cbc (10000), -- required 2006 ctr (10001), -- required 2007 ccm (10002), -- optional support 2008 gcm (10003), -- optional support 2009 ocb (10004), -- optional support 2010 ofb (10005), -- optional support 2011 xts (10006), -- optional support 2012 none (10100) -- required 2013 } 2015 CipherPadding ::= ENUMERATED { 2016 none (10200), -- required 2017 pkcs1 (10201), -- required 2018 rsaesOaep (10202), -- optional support 2019 oaepSha256Mgf1 (10203), -- optional support 2020 pkcs7 (10301), -- required 2021 ap (10221) -- required 2022 } 2024 MacAlgorithm ::= ENUMERATED { 2025 sha3-256 (3000), -- required 2026 sha3-384 (3001), -- optional support 2027 sha3-512 (3002), -- required 2028 ripemd160 (3100), -- optional support 2029 ripemd256 (3101), -- required 2030 ripemd320 (3102) -- optional support 2031 } 2033 MacAlgorithmSpec ::= SEQUENCE { 2034 algorithm MacAlgorithm, 2035 parameter AlgParameters 2036 } 2038 PRNGAlgorithmSpec ::= SEQUENCE { 2039 type PRNGType, 2040 seed OCTET STRING 2041 } 2043 PRNGType ::= ENUMERATED { 2044 mrg32k3a (10300), -- required 2045 blumMicali (10301) -- required 2046 } 2048 END 2050 A.3. The MessageVortex Request Structures 2051 MessageVortex-Requests DEFINITIONS EXPLICIT TAGS ::= 2052 BEGIN 2053 EXPORTS HeaderRequest; 2054 IMPORTS RequirementBlock 2055 FROM MessageVortex-Requirements 2056 UsagePeriod, NodeSpec 2057 FROM MessageVortex-Helpers; 2059 HeaderRequest ::= CHOICE { 2060 identity [0] HeaderRequestIdentity, 2061 capabilities [1] HeaderRequestCapability, 2062 messageQuota [2] HeaderRequestIncreaseMessageQuota, 2063 transferQuota [3] HeaderRequestIncreaseTransferQuota, 2064 quotaQuery [4] HeaderRequestQuota, 2065 nodeQuery [5] HeaderRequestNodes, 2066 replace [6] HeaderRequestReplaceIdentity 2067 } 2069 HeaderRequestIdentity ::= SEQUENCE { 2070 period UsagePeriod 2071 } 2073 HeaderRequestReplaceIdentity ::= SEQUENCE { 2074 replace SEQUENCE { 2075 old NodeSpec, 2076 new NodeSpec OPTIONAL 2077 }, 2078 identitySignature OCTET STRING 2079 } 2081 HeaderRequestQuota ::= SEQUENCE { 2082 } 2084 HeaderRequestNodes ::= SEQUENCE { 2085 numberOfNodes INTEGER (0..255) 2086 } 2088 HeaderRequestIncreaseMessageQuota ::= SEQUENCE { 2089 messages INTEGER (0..4294967295) 2090 } 2092 HeaderRequestIncreaseTransferQuota ::= SEQUENCE { 2093 size INTEGER (0..4294967295) 2094 } 2096 HeaderRequestCapability ::= SEQUENCE { 2097 period UsagePeriod 2098 } 2099 HeaderRequestUpgrade ::= SEQUENCE { 2100 version OCTET STRING, 2101 identifier OCTET STRING 2102 } 2104 END 2106 A.4. The MessageVortex Replies Structures 2108 MessageVortex-Replies DEFINITIONS EXPLICIT TAGS ::= 2109 BEGIN 2110 EXPORTS SpecialBlock; 2111 IMPORTS BlendingSpec, NodeSpec 2112 FROM MessageVortex-Helpers 2113 RequirementBlock 2114 FROM MessageVortex-Requirements 2115 CipherSpec, PRNGType, MacAlgorithm 2116 FROM MessageVortex-Ciphers 2117 maxGFSize 2118 FROM MessageVortex-Operations 2119 maxNumberOfReplays 2120 FROM MessageVortex-Schema; 2122 SpecialBlock ::= CHOICE { 2123 capabilities [1] ReplyCapability, 2124 requirement [2] SEQUENCE (SIZE (1..127)) 2125 OF RequirementBlock, 2126 quota [4] ReplyCurrentQuota, 2127 nodes [5] ReplyNodes, 2128 status [99] StatusBlock 2129 } 2131 StatusBlock ::= SEQUENCE { 2132 code StatusCode 2133 } 2135 StatusCode ::= ENUMERATED { 2137 -- System messages 2138 ok (2000), 2139 quotaStatus (2101), 2140 puzzleRequired (2201), 2142 -- protocol usage failures 2143 transferQuotaExceeded (3001), 2144 messageQuotaExceeded (3002), 2145 requestedQuotaOutOfBand (3003), 2146 identityUnknown (3101), 2147 messageChunkMissing (3201), 2148 messageLifeExpired (3202), 2149 puzzleUnknown (3301), 2151 -- capability errors 2152 macAlgorithmUnknown (3801), 2153 symmetricAlgorithmUnknown (3802), 2154 asymmetricAlgorithmUnknown (3803), 2155 prngAlgorithmUnknown (3804), 2156 missingParameters (3820), 2157 badParameters (3821), 2159 -- Mayor host specific errors 2160 hostError (5001) 2161 } 2163 ReplyNodes ::= SEQUENCE { 2164 node SEQUENCE (SIZE (1..5)) 2165 OF NodeSpec 2166 } 2168 ReplyCapability ::= SEQUENCE { 2169 -- supported ciphers 2170 cipher SEQUENCE (SIZE (2..256)) 2171 OF CipherSpec, 2172 -- supported mac algorithms 2173 mac SEQUENCE (SIZE (2..256)) 2174 OF MacAlgorithm, 2175 -- supported PRNGs 2176 prng SEQUENCE (SIZE (2..256)) 2177 OF PRNGType, 2178 -- maximum number of bytes to be transferred 2179 -- (outgoing bytes in vortex message without blending) 2180 maxTransferQuota INTEGER (0..4294967295), 2181 -- maximum number of messages to process for this identity 2182 maxMessageQuota INTEGER (0..4294967295), 2183 -- maximum simultaneously tracked header serials 2184 maxHeaderSerials INTEGER (0..4294967295), 2185 -- maximum simultaneously valid build operations in workspace 2186 maxBuildOps INTEGER (0..4294967295), 2187 -- maximum payload size 2188 maxPayloadSize INTEGER (0..4294967295), 2189 -- maximum active payloads (without intermediate products) 2190 maxActivePayloads INTEGER (0..4294967295), 2191 -- maximum header lifespan in seconds 2192 maxHeaderLive INTEGER (0..4294967295), 2193 -- maximum number of replays accepted, 2194 maxReplay INTEGER (0..maxNumberOfReplays), 2195 -- Supported inbound blending 2196 supportedBlendingIn SEQUENCE OF BlendingSpec, 2197 -- Supported outbound blending 2198 supportedBlendingOut SEQUENCE OF BlendingSpec, 2199 -- supported galoise fields 2200 supportedGFSize SEQUENCE OF INTEGER (1..maxGF) 2201 } 2203 ReplyCurrentQuota ::= SEQUENCE { 2204 messages INTEGER (0..4294967295), 2205 size INTEGER (0..4294967295) 2206 } 2208 ReplyUpgrade ::= SEQUENCE { 2209 -- The offered version 2210 version [0] OCTET STRING, 2211 -- The offered identitfier 2212 identifier [1] OCTET STRING, 2213 -- The archive or blob containing the software 2214 blob [2] OCTET STRING OPTIONAL 2215 } 2217 END 2219 A.5. The MessageVortex Requirements Structures 2220 MessageVortex-Requirements DEFINITIONS EXPLICIT TAGS ::= 2221 BEGIN 2222 EXPORTS RequirementBlock; 2223 IMPORTS MacAlgorithmSpec 2224 FROM MessageVortex-Ciphers 2225 UsagePeriod, UsagePeriod 2226 FROM MessageVortex-Helpers; 2228 RequirementBlock ::= CHOICE { 2229 puzzle [1] RequirementPuzzleRequired, 2230 payment [2] RequirementPaymentRequired 2231 } 2233 RequirementPuzzleRequired ::= SEQUENCE { 2234 -- bit sequence at beginning of hash from 2235 -- the encrypted identity block 2236 challenge BIT STRING, 2237 mac MacAlgorithmSpec, 2238 valid UsagePeriod, 2239 identifier INTEGER (0..4294967295) 2240 } 2242 RequirementPaymentRequired ::= SEQUENCE { 2243 account OCTET STRING, 2244 ammount REAL, 2245 currency Currency 2246 } 2248 Currency ::= ENUMERATED { 2249 btc (8001), 2250 eth (8002), 2251 zec (8003) 2252 } 2254 END 2256 A.6. The MessageVortex Helpers Structures 2258 MessageVortex-Helpers DEFINITIONS EXPLICIT TAGS ::= 2259 BEGIN 2260 EXPORTS UsagePeriod, BlendingSpec, NodeSpec; 2261 IMPORTS AsymmetricKey, SymmetricKey 2262 FROM MessageVortex-Ciphers; 2264 -- the maximum number of embeddable parameters 2265 maxNumberOfParameter INTEGER ::= 127 2267 UsagePeriod ::= CHOICE { 2268 absolute [2] AbsoluteUsagePeriod, 2269 relative [3] RelativeUsagePeriod 2270 } 2272 AbsoluteUsagePeriod ::= SEQUENCE { 2273 notBefore [0] GeneralizedTime OPTIONAL, 2274 notAfter [1] GeneralizedTime OPTIONAL 2275 } 2277 RelativeUsagePeriod ::= SEQUENCE { 2278 notBefore [0] INTEGER OPTIONAL, 2279 notAfter [1] INTEGER OPTIONAL 2280 } 2282 -- contains a node spec of a routing point 2283 -- At the moment either smtp: or xmpp: 2284 BlendingSpec ::= SEQUENCE { 2285 target [1] NodeSpec, 2286 blendingType [2] IA5String, 2287 parameter [3] SEQUENCE 2288 ( SIZE (0..maxNumberOfParameter) ) 2289 OF BlendingParameter 2290 } 2292 BlendingParameter ::= CHOICE { 2293 offset [1] INTEGER, 2294 symmetricKey [2] SymmetricKey, 2295 asymmetricKey [3] AsymmetricKey, 2296 passphrase [4] OCTET STRING 2297 } 2299 NodeSpec ::= SEQUENCE { 2300 transportProtocol [1] Protocol, 2301 recipientAddress [2] IA5String, 2302 recipientKey [3] AsymmetricKey OPTIONAL 2303 } 2305 Protocol ::= ENUMERATED { 2306 smtp (100), 2307 xmmp (110) 2308 } 2310 END 2312 A.7. The MessageVortex Additional Structures 2313 -- States reflected: 2314 -- Tuple()=Val()[vallidity; allowed operations] 2315 -- {Store} 2316 -- - Tuple(identity)=Val(messageQuota,transferQuota, 2317 -- sequence of Routingblocks for Error Message 2318 -- Routing) [validity; Requested at creation; may 2319 -- be extended upon request] {identityStore} 2320 -- - Tuple(Identity,Serial)=maxReplays ['valid' from 2321 -- Identity Block; from First Identity Block; may 2322 -- only be reduced] {IdentityReplayStore} 2324 MessageVortex-NonProtocolBlocks DEFINITIONS 2325 EXPLICIT TAGS ::= 2326 BEGIN 2327 IMPORTS PrefixBlock, InnerMessageBlock, 2328 RoutingBlock, 2329 maxWorkspaceID 2330 FROM MessageVortex-Schema 2331 UsagePeriod, NodeSpec, BlendingSpec 2332 FROM MessageVortex-Helpers 2333 AsymmetricKey 2334 FROM MessageVortex-Ciphers 2335 RequirementBlock 2336 FROM MessageVortex-Requirements; 2338 -- maximum size of transfer quota in bytes of an 2339 -- identity 2340 maxTransferQuota INTEGER ::= 4294967295 2341 -- maximum # of messages quota in messages of an 2342 -- identity 2343 maxMessageQuota INTEGER ::= 4294967295 2345 -- do not use these blocks for protocol encoding 2346 -- (internal only) 2347 VortexMessage ::= SEQUENCE { 2348 prefix CHOICE { 2349 plain [10011] PrefixBlock, 2350 -- contains prefix encrypted with receivers 2351 -- public key 2352 encrypted [10012] OCTET STRING 2353 }, 2354 innerMessage CHOICE { 2355 plain [10021] InnerMessageBlock, 2356 -- contains inner message encrypted with 2357 -- Symmetric key from prefix 2358 encrypted [10022] OCTET STRING 2359 } 2360 } 2361 MemoryPayloadChunk ::= SEQUENCE { 2362 id INTEGER (0..maxWorkspaceID), 2363 payload [100] OCTET STRING, 2364 validity UsagePeriod 2365 } 2367 IdentityStore ::= SEQUENCE { 2368 identities SEQUENCE (SIZE (0..4294967295)) 2369 OF IdentityStoreBlock 2370 } 2372 IdentityStoreBlock ::= SEQUENCE { 2373 valid UsagePeriod, 2374 messageQuota INTEGER (0..maxMessageQuota), 2375 transferQuota INTEGER (0..maxTransferQuota), 2376 -- if omitted this is a node identity 2377 identity [1001] AsymmetricKey OPTIONAL, 2378 -- if ommited own identity key 2379 nodeAddress [1002] NodeSpec OPTIONAL, 2380 -- Contains the identity of the owning node; 2381 -- May be ommited if local node 2382 nodeKey [1003] SEQUENCE OF AsymmetricKey 2383 OPTIONAL, 2384 routingBlocks [1004] SEQUENCE OF RoutingBlock 2385 OPTIONAL, 2386 replayStore [1005] IdentityReplayStore, 2387 requirement [1006] RequirementBlock OPTIONAL 2388 } 2390 IdentityReplayStore ::= SEQUENCE { 2391 replays SEQUENCE (SIZE (0..4294967295)) 2392 OF IdentityReplayBlock 2393 } 2395 IdentityReplayBlock ::= SEQUENCE { 2396 identity AsymmetricKey, 2397 valid UsagePeriod, 2398 replaysRemaining INTEGER (0..4294967295) 2399 } 2401 END 2403 Appendix B. Changelog 2405 +=========+=========+===============================================+ 2406 | Version | Date | Changes | 2407 | # | | | 2408 +=========+=========+===============================================+ 2409 | 0 | 11-2018 | Initial version | 2410 +---------+---------+-----------------------------------------------+ 2411 | 1 | 02-2019 | Removed term block and added more | 2412 | | | precise spec about blending. Change in | 2413 | | | spec for XMPP blending (from XEP-234 to | 2414 | | | XEP-231). Restructured ASN.1. | 2415 +---------+---------+-----------------------------------------------+ 2416 | 2 | 03-2019 | Language and consistency improvements. | 2417 | | | Added example for chunked plain | 2418 | | | embedding. Added pseudo-code for | 2419 | | | incoming message processing. Improved | 2420 | | | wording of hashes in ASN.1. | 2421 +---------+---------+-----------------------------------------------+ 2422 | 3 | 09-2019 | Removed LaTeX notation in padding. | 2423 +---------+---------+-----------------------------------------------+ 2424 | 4 | 03-2020 | Added spec for Software update using | 2425 | | | MV. Minor language improvements. | 2426 +---------+---------+-----------------------------------------------+ 2427 | 5 | 09-2020 | Reinserted lost ASN.1 specs | 2428 | | | (unintentinally lost in last two | 2429 | | | versions). Added changelog. Modified | 2430 | | | padding to improve credibility of bad | 2431 | | | values. | 2432 +---------+---------+-----------------------------------------------+ 2433 | 6 | 02-2021 | Removed some outdated references and | 2434 | | | updated draft according to the final | 2435 | | | research document. Refining of | 2436 | | | language. | 2437 +---------+---------+-----------------------------------------------+ 2438 | 7 | 04-2021 | Lectorate and improved rendering. | 2439 +---------+---------+-----------------------------------------------+ 2441 Table 1: changes in versions 2443 Author's Address 2444 Martin Gwerder 2445 University of Applied Sciences and Arts Northwestern Switzerland 2446 Bahnhofstrasse 5 2447 CH-5210 Windisch 2448 Switzerland 2450 Phone: +41 56 202 76 81 2451 Email: rfc@messagevortex.net