- tor-dev - lists.torproject.org

TBB Memory Allocator choice fingerprint implications
by procmem＠riseup.net 21 Aug '19

21 Aug '19

Question for the Tor Browser experts. Do you know if it is possible to remotely fingerprint the browser based on the memory allocator it is using? (via JS or content rendering) We are thinking of switching Tor Browser to use the minimalist and security oriented hardened_malloc written by Daniel Micay. Thanks.

10 17

[prop305] Introduction Point Behavior
by David Goulet 20 Aug '19

20 Aug '19

Greetings, This is part of the many discussions about proposal 305 which is the ESTABLISH_INTRO DoS defenses cell extension. Implementation is close to done and under review in ticket #30924. However, there is one part that is yet to be cleared out. asn and I thought it would be better to bring it to tor-dev@ to get a more informed decision. As a reminder, the service operator will be able set torrc options that are the DoS defenses parameters. Those values are validated (bound check) and then sent to an introduction point, supporting the extension (protover HSIntro=5), in the ESTABLISH_INTRO cell. The intro point then gets them and apply them only to that specific circuit. If no cell extension is seen, the intro point will honor the consensus parameters for these DoS defenses. What we want to discuss is what happened when the introduction points receives bad values. What does it do with the circuit? Below is the list of possible bad values and the proposed behavior: 1) One of the paramater (at this point in time, only 2 exists) is out of bound that is above INT32_MAX. Behavior: We propose to ignore the cell extension, and fallback to follow the consensus parameters. Keeping the circuit alive and working. The reason for this is because if let say the intro point would close the circuit due to "bad protocol", then the service would open a new circuit to an intro point supporting the extension and it would fail again. Effectively turning the service into a "zombie" and "DoS" weapon itself ;). At this point, there is really no reason on why the service would send bad values since torrc options are validated and then sent to the intro point. But this doesn't protect us from our future-developer-self making coding or protocol mistake ;). 2) A parameter type is unrecognized. This one is mostly about forward compatibility. Behavior: Ignore the parameter type, and continue parsing the cell extension. If all the right parameters are found, apply defenses. 3) None or 1 parameter out of 2 is given. Behavior: This would be considered bad protocol so it would be like (1) where the intro point uses the consensus parameters. 4) <insert whatever case you can think about> So, for (1) and (3), there lies mostly the discussion. There is no way to send feedback to the service if a problem occurred and that the DoS defenses weren't applied due to reason X. If we had that, we could not only try to warn the operator (log or control event) but make tor smarter when an error is returned so it doesn't try to infinity other intro points with values that makes them fail. One avenue there is to pass down such error code into the INTRO_ESTABLISHED cell with probably a new extension. That requires more work and likely either extending prop305 or a new proposal. Thus, what is the minimal viable product here we are ok with? I'm leaning towards not closing the circuit and falling back on the consensus parameters. And at some point in time, we'll be able to implement the INTRO_ESTABLISHED response. In the meantime, there is little chances that tor vanilla start sending bad values since they are validated from the torrc file. Cheers! David -- eHE50zZRZOX3zLNHdPwN5gGQBUvDnfGyOuYr/afK2XY=

3 2

Re: [tor-dev] TBB Memory Allocator choice fingerprint implications
by procmem＠riseup.net 17 Aug '19

17 Aug '19

*On Sat, 17 Aug 2019 at**21:17, Tom Ritter* <tom at ritter.vg <mailto:tor-dev%40lists.torproject.org?Subject=Re%3A%20%5Btor-dev%5D%20TBB%20Memory%20Allocator%20choice%20fingerprint%20implications&In-Reply-To=%3CCA%2BcU71%3DPeZGCAJNsPQy9QpKY9%3Dwz3vPdW8QKruF_ZwyanoyYzQ%40mail.gmail.com%3E>> wrote: > On Sat, 17 Aug 2019 at 15:06, procmem at riseup.net <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev> <procmem at riseup.net <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev>> wrote: > >/Question for the Tor Browser experts. Do you know if it is possible to />/remotely fingerprint the browser based on the memory allocator it is />/using? (via JS or content rendering) / > Fingerprint what aspect of the browser/machine? I'm not really sure (I'm of the opinion it should not matter) and so I'm curious as to what could be affected if anything. Some members of our team are divided about making it the default because of unknown consequences which is what I'm trying to clear up. > >/We are thinking of switching Tor Browser to use the minimalist and />/security oriented hardened_malloc written by Daniel Micay. Thanks. / > I wouldn't advise giving up partitioning for.... what exactly? What > features does this allocator have that 68's jemalloc doesn't? > > -tom So the original suggestion [0] was prompted by past research done by the Tor Browser team for a jemalloc alternative. [1] Hardened_malloc wasn't around back then so it may be a worthy alternative for you guys to switch to too. Hardened_malloc has a partitioned heap among many other defenses implemented if I understand their label correctly (please see "Security properties" section in [2]). Also available on ARM. [0] https://forums.whonix.org/t/hardened-malloc/7474 [1] https://trac.torproject.org/projects/tor/ticket/10281 [2] https://github.com/GrapheneOS/hardened_malloc *** PS. A related debate is on whether we should enable Apparmor and Firejail sandboxing for Tor Browser by default, but again we don't know if restriction to resources and file paths on the machine is something that is remotely detectable as an anomaly or not, ruining the fingerprint in the process. Input is appreciated. related thread: https://forums.whonix.org/t/tor-browser-hardening-hardened-malloc-firejail-…

1 0

24 hours worth of BridgeDB usage metrics
by Philipp Winter 30 Jul '19

30 Jul '19

Over at <https://bugs.torproject.org/9316>, we are working on having BridgeDB export metrics. The patch is almost done and I deployed the work-in-progress code on BridgeDB, so we can take a look at the metrics and think of ways to improve them. The metrics format encodes the approximate number of requests per distribution mechanism per transport per country per success/fail. All numbers are rounded up to the next multiple of 10. The last field, "none", will be used for an anomaly score and is currently unused. For example, the line bridgedb-metric-count email.obfs4.riseup.success.none 10 tells us that there have been 1-10 successful email requests for obfs4 coming from Riseup addresses. I attached 24 hours worth of metrics to this email. Keep the following issues in mind: * My feature branch hasn't been reviewed yet and likely still has bugs, so take all numbers with a grain of salt. * The country codes are based on Debian stretch's geoip-database, which is slightly outdated and uses Maxmind's far-from-perfect GeoLite database. * The country code "??" refers to geo-location failure or lack of IP addresses (in the cast of moat). The country code "zz" refers to a request from a Tor exit relay. Some observations: * Gmail sees much more use than Riseup. That's no surprise. * The email distributor sees more vanilla than obfs4 requests. I wonder to what degree this is caused by the poor UX of the email distributor. * For HTTPS, many countries have a fail and success bucket of 10 each. I would expect this to be at least one user who failed the captcha at least once before finally getting it right. * The captcha success rate for obfs4 over moat is 54%. That's very low and must cause lots of frustration for users. This is a known issue that's tracked in this ticket: <https://bugs.torproject.org/29695> * Ignore the large amount of HTTPS requests from "zz" -- I expect the vast majority of these to be a bot that's interacting with BridgeDB over exit relays. After a cursory look at the numbers, I would like to aggregate the data, to make it easier to compare distributors, transports, and countries. For example: how do moat, email, and HTTPS rank in popularity? I'll improve the patch to keep track of these numbers in separate metrics. Any thoughts or suggestions? Cheers, Philipp

3 4

What hidden services does my relay node know about?
by clive.jenson＠tutanota.com 29 Jul '19

29 Jul '19

I built tor from source and am running it as a relay (not exit node) and also as a directory server. It is my understanding that after a while I should experience V2 hidden services publishing their descriptors to me (each hidden service picks 6 directory servers at random to publish their descriptor to). How can I tell if this is happening? Can I (temporarily, for debugging purposes) view the descriptors being published to me? I'm thinking their might be some useful logging if I enable debug logs (but I can't find it)? Or maybe there is something I can get over the control protocol (but I couldn't find anything obvious in the stem API docs that exposes it)? Or maybe I could make a code change to log this information (I'm not sure where the code is that receives the announcements)?

2 4

Hack
by Pordeshi Pothik 27 Jul '19

27 Jul '19

Hi,I want to learn how to hack facebook.

2 1

Proposal 306: Onion Balance Support for Onion Service v3
by David Goulet 26 Jul '19

26 Jul '19

Greetings! Around 4 months ago, nickm published a proposal draft for OnionBalance to support onion services v3. Due to #29583, it turns out that we can afterall take the easy approach which is basically how OnionBalance is working today for v2 but transposed to v3. See the ticket for the reasons why for now we'll proceed this way. However, we all agreed that #29583 is a "must fix at some point" meaning that OnionBalance v3 will then become much more complicated. In order to not forget about it, I'm reviving nickm's proposal as prop306 so we have the draft in torspec.git. See attachement for the proposal. Cheers! David -- vjZrE+FHHEPpllrbcUukx7LtWFzk066L23yoggvnmso=

3 2

Status of open circuit padding tickets
by George Kadianakis 23 Jul '19

23 Jul '19

Hello Nick and Mike, here is a summary of the current state of open circpad tickets, which I tried to tidy up today. These are all the tickets I had in my radar and I hope I didn't miss any. I will be on leave starting the day after tomorrow (25th) so I wanted to inform you of the status quo: 0.4.1: #31024: Coverity: circpadding: always check circpad_machine_current_state() - [needs_review] - This is done and in needs_review for Mike. #30992: circpadding: Circsetup machines give out warnings when client-side intro gets NACKed - This is still unresolved and in 041. I couldn't figure out by just looking at the logs... Perhaps we could push it in 042 given that it's a pretty rare client behavior. 0.4.2: #30942: [warn] Unexpected INTRODUCE_ACK on circuit 3944288021. - I took a stab at this today since this seems to be a central issue that can cause lots of log warns. It's now in needs_review. #31112: remove specified target_hopnum from relay-side machines - [merge_ready] #31113: Circuitpadding updated comments #31098: transition when we send our first padding packet, not on received - [merge_ready] - These are all Tobias' patches. I made changes files and fixed a few of them and also made a PR. I moved them to 042 since they are not really urgent bugfixes. The only one I would consider backporting to 041 is #31098. #31002: circpadding: Middle node did not accept our padding request - [assigned] - This is still unresolved. Mike took a look during PETS but not sure what's the verdict. I pushed to 042 since it does not seem urgent but we might want to reconsider. #30578: The circuitpadding_circuitsetup_machine test: Re-enable, remove, re-document, or ___? - This is still unresolved but not urgent. I pushed it to 042. 0.4.0: #30649: Every few hours, relays [warn] Received circuit padding stop command - This was hanging on a 040 backport which I just did.

1 0

resolving DNS TXT records?
by nusenu 11 Jul '19

11 Jul '19

Hi, as far as I can tell there is no way for a tor client to ask an exit to resolve a given TXT record and to provide the answer for it. Just wanted to make sure there is even no hack around that limitation. thanks, nusenu https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.t… -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 1

New revision: Proposal 295: Using ADL for relay cryptography (solving the crypto-tagging attack)
by Nick Mathewson 11 Jul '19

11 Jul '19

Hi! I'm sending a new version of proposal 295 from Tomer Ashur, Orr Dunkelman, and Atul Luykx. It's an updated version of their design for an improved relay cell encryption scheme, to prevent tagging attacks. This proposal is checked into the torspec repository. I'm also linking to a diagram for this scheme (and its latex source) from Atul Luykx: https://people.torproject.org/~nickm/prop295/ Finally, I have a draft python reference implementation for an older version of this proposal. I hope to be updating it soon and sending out a link next week. cheers! -- Nick Filename: 295-relay-crypto-with-adl.txt Title: Using ADL for relay cryptography (solving the crypto-tagging attack) Author: Tomer Ashur, Orr Dunkelman, Atul Luykx Created: 22 Feb 2018 Last-Modified: 1 March 2019 Status: Open 0. Context Although Crypto Tagging Attacks were identified already in the original Tor design, it was not before the rise of the Procyonidae in 2012 that their severity was fully realized. In Proposal 202 (Two improved relay encryption protocols for Tor cells) Nick Mathewson discussed two approaches to stymie tagging attacks and generally improve Tor's cryptography. In Proposal 261 (AEZ for relay cryptography) Mathewson puts forward a concrete approach which uses the tweakable wide-block cipher AEZ. This proposal suggests an alternative approach to Proposal 261 using the notion of Release (of) Unverified Plaintext (RUP) security. It describes an improved algorithm for circuit encryption based on CTR-mode which is already used in Tor, and an additional component for hashing. Incidentally, and similar to Proposal 261, this proposal employs the ENCODE-then-ENCIPHER approach thus it improves Tor's E2E integrity by using (sufficient) redundancy. For more information about the scheme and a security proof for its RUP-security see Tomer Ashur, Orr Dunkelman, Atul Luykx: Boosting Authenticated Encryption Robustness with Minimal Modifications. CRYPTO (3) 2017: 3-33 available online at https://eprint.iacr.org/2017/239 . For authentication between the OP and the edge node we use the PIV scheme: https://eprint.iacr.org/2013/835 2. Preliminaries 2.1 Motivation For motivation, see proposal 202. 2.2. Notation Symbol Meaning ------ ------- M Plaintext C_I Ciphertext CTR Counter Mode N_I A de/encryption nonce (to be used in CTR-mode) T_I A tweak (to be used to de/encrypt the nonce) T'_I A running digest ^ XOR || Concatenation (This is more readable than a single | but must be adapted before integrating the proposal into tor-spec.txt) 2.3. Security parameters HASH_LEN -- The length of the hash function's output, in bytes. PAYLOAD_LEN -- The longest allowable cell payload, in bytes. (509) DIG_KEY_LEN -- The key length used to digest messages (e.g., using GHASH). Since GHASH is only defined for 128-bit keys, we recommend DIG_KEY_LEN = 128. ENC_KEY_LEN -- The key length used for encryption (e.g., AES). We recommend ENC_KEY_LEN = 128. 2.4. Key derivation (replaces Section 5.2.2) For newer KDF needs, Tor uses the key derivation function HKDF from RFC5869, instantiated with SHA256. The generated key material is: K = K_1 | K_2 | K_3 | ... where, if H(x,t) denotes HMAC_SHA256 with value x and key t, and m_expand denotes an arbitrarily chosen value, and INT8(i) is an octet with the value "i", then K_1 = H(m_expand | INT8(1) , KEY_SEED ) and K_(i+1) = H(K_i | m_expand | INT8(i+1) , KEY_SEED ), in RFC5869's vocabulary, this is HKDF-SHA256 with info == m_expand, salt == t_key, and IKM == secret_input. When used in the ntor handshake a string of key material is generated and is used in the following way: Length Purpose Notation ------ ------- -------- HASH_LEN forward digest IV DF * HASH_LEN backward digest IV DB * ENC_KEY_LEN encryption key Kf ENC_KEY_LEN decryption key Kb DIG_KEY_LEN forward digest key Khf DIG_KEY_LEN backward digest key Khb ENC_KEY_LEN forward tweak key Ktf ENC_KEY_LEN backward tweak key Ktb DIGEST_LEN nonce to use in the * hidden service protocol * I am not sure that we need these any longer. Excess bytes from K are discarded. 2.6. Ciphers For hashing(*) we use GHASH with a DIG_KEY_LEN-bit key. We write this as Digest(K,M) where K is the key and M the message to be hashed. We use AES with an ENC_KEY_LEN-bit key. For AES encryption (resp., decryption) we write E(K,X) (resp., D(K,X)) where K is an ENC_KEY_LEN-bit key and X the block to be encrypted (resp., decrypted). For a stream cipher, unless otherwise specified, we use ENC_KEY_LEN-bit AES in counter mode, with a nonce that is generated as explained below. We write this as Encrypt(K,N,X) (resp., Decrypt(K,N,X)) where K is the key, N the nonce, and X the message to be encrypted (resp., decrypted). (*) The terms hash and digest are used interchangeably. 3. Routing relay cells 3.1. Forward Direction The forward direction is the direction that CREATE/CREATE2 cells are sent. 3.1.1. Routing from the Origin Let n denote the integer representing the destination node. For I = 1...n+1, T'_{I} is initialized to the 128-bit string consisting entirely of '0's. When an OP sends a relay cell, they prepare the cell as follows: The OP prepares the authentication part of the message: C_{n+1} = M T_{n+1} = Digest(Khf_n,T'_{n+1}||C_{n+1}) N_{n+1} = T_{n+1} ^ E(Ktf_n,T_{n+1} ^ 0) T'_{n+1} = T_{n+1} Then, the OP prepares the multi-layered encryption: For I=n...1: C_I = Encrypt(Kf_I,N_{I+1},C_{I+1}) T_I = Digest(Khf_I,T'_I||C_I) N_I = T_I ^ E(Ktf_I,T_I ^ N_{I+1}) T'_I = T_I The OP sends C_1 and N_1 to node 1. 3.1.2. Relaying Forward at Onion Routers When a forward relay cell is received by OR I, it decrypts the payload with the stream cipher, as follows: 'Forward' relay cell: T_I = Digest(Khf_I,T'_I||C_I) N_{I+1} = T_I ^ D(Ktf_I,T_I ^ N_I) C_{I+1} = Decrypt(Kf_I,N_{I+1},C_I) T'_I = T_I The OR then decides whether it recognizes the relay cell as described below. If the OR recognizes the cell, it processes the contents of the relay cell. Otherwise, it passes C_{I+1}||N_{I+1} along the circuit if the circuit continues. For more information, see section 4 below. 3.2. Backward Direction The backward direction is the opposite direction from CREATE/CREATE2 cells. 3.2.1. Relaying Backward at Onion Routers When a backward relay cell is received by OR I, it encrypts the payload with the stream cipher, as follows: 'Backward' relay cell: T_I = Digest(Khb_I,T'_I||C_{I+1}) N_I = T_I ^ E(Ktb_I,T_I ^ N_{I+1}) C_I = Encrypt(Kb_I,N_I,C_{I+1}) T'_I = T_I with C_{n+1} = M and N_{n+1}=0. Once encrypted, the node passes C_I and N_I along the circuit towards the OP. 3.2.2. Routing to the Origin When a relay cell arrives at an OP, the OP decrypts the payload with the stream cipher as follows: OP receives relay cell from node 1: For I=1...n, where n is the end node on the circuit: C_{I+1} = Decrypt(Kb_I,N_I,C_I) T_I = Digest(Khb_I,T'_I||C_{I+1}) N_{I+1} = T_I ^ D(Ktb_I,T_I ^ N_I) T'_I = T_I If the payload is recognized (see Section 4.1), then: The sending node is I. Stop, process the payload and authenticate. 4. Application connections and stream management 4.1. Relay cells Within a circuit, the OP and the end node use the contents of RELAY packets to tunnel end-to-end commands and TCP connections ("Streams") across circuits. End-to-end commands can be initiated by either edge; streams are initiated by the OP. The payload of each unencrypted RELAY cell consists of: Relay command [1 byte] 'Recognized' [2 bytes] StreamID [2 bytes] Length [2 bytes] Data [PAYLOAD_LEN-23 bytes] The 'recognized' field is used as a simple indication that the cell is still encrypted. It is an optimization to avoid calculating expensive digests for every cell. When sending cells, the unencrypted 'recognized' MUST be set to zero. When receiving and decrypting cells the 'recognized' will always be zero if we're the endpoint that the cell is destined for. For cells that we should relay, the 'recognized' field will usually be nonzero, but will accidentally be zero with P=2^-16. If the cell is recognized, the node moves to verifying the authenticity of the message as follows(*): forward direction (executed by the end node): T_{n+1} = Digest(Khf_n,T'_{n+1}||C_{n+1}) Tag = T_{n+1} ^ D(Ktf_n,T_{n+1} ^ N_{n+1}) T'_{n+1} = T_{n+1} The message is authenticated (i.e., M = C_{n+1}) if and only if Tag = 0 backward direction (executed by the OP): The message is authenticated (i.e., C_{n+1} = M) if and only if N_{n+1} = 0 The old Digest field is removed since sufficient information for authentication is now included in the nonce part of the payload. (*) we should consider dropping the 'recognized' field altogether and always try to authenticate. Note that this is an optimization question and the crypto works just as well either way. The 'Length' field of a relay cell contains the number of bytes in the relay payload which contain real payload data. The remainder of the payload is padding bytes. 4.2. Appending the encrypted nonce and dealing with version-homogenic and version-heterogenic circuits When a cell is prepared to be routed from the origin (see Section 3.1.1) the encrypted nonce N is appended to the encrypted cell (occupying the last 16 bytes of the cell). If the cell is prepared to be sent to a node supporting the new protocol, S is combined with other sources to generate the layer's nonce. Otherwise, if the node only supports the old protocol, n is still appended to the encrypted cell (so that following nodes can still recover their nonce), but a synchronized nonce (as per the old protocol) is used in CTR-mode. When a cell is sent along the circuit in the 'backward' direction, nodes supporting the new protocol always assume that the last 16 bytes of the input are the nonce used by the previous node, which they process as per Section 3.2.1. If the previous node also supports the new protocol, these cells are indeed the nonce. If the previous node only supports the old protocol, these bytes are either encrypted padding bytes or encrypted data. 5. Security 5.1. Resistance to crypto-tagging attacks A crypto-tagging attack involves a circuit with two colluding nodes and at least one honest node between them. The attack works when one node makes a change to the cell (tagging) in a way that can be undone by the other colluding party. In between, the tagged cell is processed by honest nodes which do not detect the change. The attack is possible due to the malleability property of CTR-mode: a change to a ciphertext bit effects only the respective plaintext bit in a predicatble way. This proposal frustrates the crypto-tagging attack by linking the nonce to the encrypted message such that any change to the ciphertext results in a random nonce and hence, random plaintext. Let us consider the following 3-hop scenario: the entry and end nodes are malicious and colluding and the middle node is honest. 5.1.1. forward direction Suppose that node I tags the ciphertext part of the message (C'_{I+1} != C_{I+1}) then forwards it to the next node (I+1). As per Section 3.1.2. Node I+1 digests C'_{I+1} to generate T_{I+1} and N_{I+2}. Since C'_{I+2} is different than it should be, so are the resulting T_{I+1} and N_{I+2}. Hence, decrypting C'_{I+2} using these values results in a random string for C_{I+2}. Since C_{I+2} is now just a random string, it is decrypted into a random string and cannot be 'recognized' nor authenticated. Furthermore, since C'_{I+1} is different than what it should be, T'_{I+1} (i.e., the running digest of the middle node) is now out of sync with that of the OP, which means that all future cells sent through this node will decrypt into garbage (random strings). Likewise, suppose that instead of tagging the ciphertext, Node I node tags the encrypted nonce N'_{I+1} != N_{I+1}. Now, when Node I+1 digests the payload the tweak T_{I+1} is find, but using it to decrypt N'_{I+1} again results in a random nonce for N_{I+2}. This random nonce is used to decrypt C_{I+1} into a random C'_{I+2} which is not recognized by the end node. Since C_{I+2} is now a random string, the running digest of the end node is now out of sync, which prevents the end node from decrypting further cells. 5.1.2. Backward direction In the backward direction the tagging is done by Node I+2 untagging by the Node I. Suppose first that Node I+2 tags the ciphertext C_{I+2} and sends it to Node I+1. As per Section 3.2.1, Node I+1 first digests C_{I+2} and uses the resulting T_{I+1} to generate a nonce N_{I+1}. From this it is clear that any change introduced by Node I+2 influences the entire payload and cannot be removed by Node I. Unlike in Section 5.1.1., the cell is blindly delivered by Node I to the OP which decrypts it. However, since the payload leaving the end node was modified, the message cannot be authenticated by the OP which can be trusted to tear down the circuit. Suppose now that tagging is done by Node I+2 to the nonce part of the payload, i.e., N_{I+2}. Since this value is encrypted by Node I+1 to generate its own nonce N_{I+1}, again, a random nonce is used which affects the entire keystream of CTR-mode. The cell again cannot be authenticated by the OP and the circuit is torn down. We note that the end node can modify the plain message before ever encrypting it and this cannot be discovered by the Tor protocol. This vulnerability is outside the scope of this proposal and users should always use TLS to make sure that their application data is encrypted before it enters the Tor network. 5.2. End-to-end authentication Similar to the old protocol, this proposal only offers end-to-end authentication rather than per-hop authentication. However, unlike the old protocol, the ADL-construction is non-malleable and hence, once a non-authentic message was processed by an honest node supporting the new protocol, it is effectively destroyed for all nodes further down the circuit. This is because the nonce used to de/encrypt all messages is linked to (a digest of) the payload data. As a result, while honest nodes cannot detect non-authentic messages, such nodes still destroy the message thus invalidating its authentication tag when it is checked by edge nodes. As a result, security against crypto-tagging attacks is ensured as long as an honest node supporting the new protocol processes the message between two dishonest ones. 5.3 The Running Digest Unlike the old protocol, the running digest is now computed as the output of a GHASH call instead of a hash function call (SHA256). Since GHASH does not provide the same type of security guarantees as SHA256, it is worth discussing why security is not lost from computing the running digest differently. The running digets is used to ensure that if the same payload is encrypted twice, then the resulting ciphertext does not remain the same. Therefore, all that is needed is that the digest should repeat with low probability. GHASH is a universal hash function, hence it gives such a guarantee assuming its key is chosen uniformly at random.

3 4