[tor-dev] [RFC] Proposal: "Res tokens: Anonymous Credentials for Onion Service DoS Resilience"

Christopher Wood caw at heapingbits.net
Tue Feb 23 21:58:10 UTC 2021

Nice work, George! In case folks are interested, I wrote up a very similar proposal independently:


Perhaps we should converge? :-)


On Thu, Feb 11, 2021, at 3:36 PM, George Kadianakis wrote:
> Hello all,
> after lots of investigation on anonymous credentials, we are glad to
> present you with a draft of the onion services anti-DoS proposal using
> tokens.
> While the basic idea of the proposal should remain reasonably solid,
> there are various XXX sprinkled around the proposal and some of them
> definitely need to be addressed before the proposal becomes truly
> usable.
> We are particularly looking forward to feedback about:
> - Token issuance services
> - The anonymous credential scheme chosen
> - The XXXs and design decisions of the proposal
> Hope you have a pleasant read!
> ---
> ```
> Filename: 331-res-tokens-for-anti-dos.md
> Title: Res tokens: Anonymous Credentials for Onion Service DoS Resilience
> Author: George Kadianakis, Mike Perry
> Created: 11-02-2021
> Status: Draft
> ```
>                   +--------------+           +------------------+
>                   | Token Issuer |           | Onion Service    |
>                   +--------------+           +------------------+
>                          ^                            ^
>                          |        +----------+        |
>                 Issuance |  1.    |          |   2.   | Redemption
>                          +------->|  Alice   |<-------+
>                                   |          |
>                                   +----------+
> # 0. Introduction
>   This proposal specifies a simple anonymous credential scheme based on Blind
>   RSA signatures designed to fight DoS abuse against onion services. We call
>   the scheme "Res tokens".
>   Res tokens are issued by third-party issuance services, and are verified by
>   onion services during the introduction protocol (through the INTRODUCE1
>   cell).
>   While Res tokens are used for denial of service protection in this proposal,
>   we demonstrate how they can have application in other Tor areas as well, like
>   improving the IP reputation of Tor exit nodes.
> # 1. Motivation
>   Denial of service attacks against onion services have been explored 
> in the past
>   and various defenses have been proposed:
>   - Tor proposal #305 specifies network-level rate-limiting mechanisms.
>   - Onionbalance allows operators to scale their onions horizontally.
>   - Tor proposal #327 increases the attacker's computational 
> requirements (not implemented yet).
>   While the above proposals in tandem should provide reasonable protection
>   against many DoS attackers, they fundamentally work by reducing the assymetry
>   between the onion service and the attacker. This won't work if the attacker
>   is extremely powerful because the assymetry is already huge and cutting it
>   down does not help.
>   we believe that a proposal based on cryptographic guarantees -- like Res
>   tokens -- can offer protection against even extremely strong attackers.
> # 2. Overview
>   In this proposal we introduce an anonymous credential scheme -- Res tokens --
>   that is well fitted for protecting onion services against DoS attacks. We
>   also introduce a system where clients can acquire such anonymous credentials
>   from various types of Token Issuers and then redeem them at the onion service
>   to gain access even when under DoS conditions.
>   In section [TOKEN_DESIGN], we list our requirements from an anonymous
>   credential scheme and provide a high-level overview of how the Res token
>   scheme works.
>   In section [PROTOCOL_SPEC], we specify the token issuance and 
> redemption protocols,
>   as well as the mathematical operations that need to be conducted for 
> these to work.
>   In section [TOKEN_ISSUERS], we provide a few examples and guidelines for
>   various token issuer services that could exist.
>   In section [DISCUSSION], we provide more use cases for Res tokens as well as
>   future improvements we can conduct to the scheme.
> # 3. Design [TOKEN_DESIGN]
>   In this section we will go over the high-level design of the system, and on
>   the next section we will delve into the lower-level details of the protocol.
> ## 3.1. Anonymous credentials
>   Anonymous credentials or tokens are cryptographic identifiers that allow
>   their bearer to maintain an identity while also preserving anonymity.
>   Clients can acquire a token in a variety of ways (e.g. registering on a
>   third-party service, solving a CAPTCHA, completing a PoW puzzle) and then
>   redeem it at the onion service proving this way that work was done, but
>   without linking the act of token acquisition with the act of token
>   redemption.
> ## 3.2. Anonymous credential properties
>   The anonymous credential literature is vast and there are dozens of
>   credential schemes with different properties [REF_TOKEN_ZOO], in this section
>   we detail the properties we care about for this use case:
>   - Public Verifiability: Because of the distributed trust properties of the
>       Tor network, we need anonymous credentials that can be issued by one
>       party (the token issuer) and verified by a different party (in this case
>       the onion service).
>   - Perfect unlinkability: Unlinkability between token issuance and token
>       redemption is vital in private settings like Tor. For this reason we want
>       our scheme to preserve its unlinkability even if its fundamental security
>       assumption is broken. We want unlinkability to be protected by
>       information theoretic security or random oracle, and not just
>       computational security.
>   - Small token size: The tokens will be transfered to the service through the
>       INTRODUCE1 cell which is not flexible and has only a limited amount of
>       space (about 200 bytes) [REF_INTRO_SPACE]. We need tokens to be small.
>   - Quick Verification: Onions are already experiencing resource starvation
>       because of the DoS attacks so it's important that the process of
>       verifying a token should be as quick as possible. In section [TOKEN_PERF]
>       we will go deeper into this requirement.
>   After careful consideration of the above requirements, we have leaned 
> towards
>   using Blind RSA as the primitive for our tokens, since it's the 
> fastest
>   scheme by far that also allows public verifiability. See also 
> Appendix B
>   [BLIND_RSA_PROOF] for a security proof sketch of Blind RSA perfect 
> unlinkability.
> ## 3.3. Other security considerations
>   Apart from the above properties we also want:
>   - Double spending protection: We don't want Malory to be able to double spend
>       her tokens in various onion services thereby amplifying her attack. For
>       this reason our tokens are not global, and can only be redeemed at a
>       specific destination onion service.
>   - Metadata: We want to encode metadata/attributes in the tokens. In
>       particular, we want to encode the destination onion service and an
>       expiration date. For more information see section [DEST_DIGEST]. For
>       blind RSA tokens this is usually done using "partially blind signatures"
>       but to keep it simple we instead encode the destination directly in the
>       message to be blind-signed and the expiration date using a set of
>       rotating signing keys.
>   - One-show: There are anonymous credential schemes with multi-show support
>       where one token can be used multiple times in an unlinkable
>       fashion. However, that might allow an adversary to use a single token to
>       launch a DoS attack, since revocation solutions are complex and
>       inefficient in anonymous credentials. For this reason, in this work we
>       use one-show tokens that can only be redeemed once. That takes care of
>       the revocation problem but it means that a client will have to get more
>       tokens periodically.
> ## 3.4. Res tokens overview
>   Throughout this proposal we will be using our own token scheme, named "Res",
>   which is based on blind RSA signatures. In this modern cryptographic world,
>   not only we have the audacity of using Chaum's oldest blind signature scheme
>   of all times, but we are also using RSA with a modulus of 1024 bits...
>   The reason that Res uses only 1024-bits RSA is because we care most about
>   small token size and quick verification rather than the unforgeability of the
>   token. This means that if the attacker breaks the issuer's RSA signing key
>   and issues tokens for herself, this will enable the adversary to launch DoS
>   attacks against onion services, but it won't allow her to link users (because
>   of the "perfect unlinkability" property).
>   Furthermore, Res tokens get a short implicit expiration date by having the
>   issuer rapidly rotate issuance keys every few hours. This means that even if
>   an adversary breaks an issuance key, she will be able to forge tokens for
>   just a few hours before that key expires.
>   For more ideas on future schemes and improvements see section [FUTURE_RES].
> ## 3.5. Token performance requirements [TOKEN_PERF]
>   As discussed above, verification performance is extremely important in the
>   anti-DoS use case. In this section we provide some concrete numbers on what
>   we are looking for.
>   In proposal #327 [REF_POW_PERF] we measured that the total time spent by the
>   onion service on processing a single INTRODUCE2 cell ranges from 5 msec to 15
>   msecs with a mean time around 5.29 msec. This time also includes the launch
>   of a rendezvous circuit, but does not include the additional blocking and
>   time it takes to process future cells from the rendezvous point.
>   We also measured that the parsing and validation of INTRODUCE2 cell ("top
>   half") takes around 0.26 msec; that's the lightweight part before the onion
>   service decides to open a rendezvous circuit and do all the path selection
>   and networking.
>   This means that any defenses introduced by this proposal should add minimal
>   overhead to the above "top half" procedure, so as to apply access control in
>   the lightest way possible.
>   For this reason we implemented a basic version of the Res token scheme in
>   Rust and benchmarked the verification and issuance procedure [REF_RES_BENCH].
>   We measured that the verification procedure from section [RES_VERIFY] takes
>   about 0.104 ms, which we believe is a reasonable verification overhead for
>   the purposes of this proposal.
>   We also measured that the issuance procedure from [RES_ISSUANCE] takes about
>   0.614 ms.
> # 4. Specification [PROTOCOL_SPEC]
>                   +--------------+           +------------------+
>                   | Token Issuer |           | Onion Service    |
>                   +--------------+           +------------------+
>                          ^                            ^
>                          |        +----------+        |
>                 Issuance |  1.    |          |   2.   | Redemption
>                          +------->|  Alice   |<-------+
>                                   |          |
>                                   +----------+
> ## 4.0. Notation
>   Let `a || b` be the concatenation of a with b.
>   Let `a^b` denote the exponentiation of a to the bth power.
>   Let `a == b` denote a check for equality between a and b.
>   Let FDH_N(msg) be a Full Domain Hash (FDH) of 'msg' using SHA256 and
>   stretching the digest to be equal to the size of an RSA modulus N.
> ## 4.1. Token issuer setup
>   The Issuer creates a set of ephemeral RSA-1024 "issuance keys" that will be
>   used during the issuance protocol. Issuers will be rotating these ephemeral
>   keys every 6 hours.
>   The Issuer exposes the set of active issuance public keys through a REST HTTP
>   API that can be accessed by visiting /issuers.keys.
>   Tor directory authorities periodically fetch the issuer's public keys and
>   vote for those keys in the consensus so that they are readily available by
>   clients. The keys in the current consensus are considered active, whereas the
>   ones that have fallen off have expired.
>   XXX how many issuance public keys are active each time? how does overlapping
>       keys work? clients and onions need to know precise expiration date for
>       each key. this needs to be specified and tested for robustness.
>   XXX every how often does the fetch work? how does the voting work? which
>       issuers are considered official? specify consensus method.
>   XXX An alternative approach: Issuer has a long-term ed25519 certification key
>       that creates expiring certificates for the ephemeral issuance keys. Alice
>       shows the certificate to the service to prove that the token comes from
>       an issuer. The consensus includes the long-term certification key of the
>       issuers to establish ground truth.
>       This way we avoid the synchronization between dirauths and issuers, and
>       the multiple overlapping active issuance keys. However, certificates
>       might not fit in the INTRODUCE1 cell (prop220 certs take 104 bytes on
>       their own).  Also certificate metadata might create a vector for
>       linkability attacks between the issuer and the verifier.
> ## 4.2. Onion service signals ongoing DoS attack
>   When an onion service is under DoS attack it adds the following line in the
>   "encrypted" (inner) part of the v3 descriptor as a way to signal to its
>   clients that tokens are required for gaining access:
>     "token-required" SP token-type SP issuer-list NL
>     [At most once]
>     token-type: Is the type of token supported ("res" for this proposal)
>     issuer: A comma separated list of issuers which are supported by 
> this onion service
> ## 4.3. Token issuance
>   When Alice visits an onion service with an active "token-required" line in
>   its descriptor it checks whether there are any tokens available for this
>   onion service in its token store. If not, it needs to acquire some and hence
>   the token issuance protocol commences.
> ### 4.3.1. Client preparation [DEST_DIGEST]
>   Alice first chooses an issuer supported by the onion service depending on her
>   preferences by looking at the consensus and her Tor configuration file for
>   the current list of active issuers.
>   After picking a supported issuer, she performs the following preparation
>   before contacting the issuer:
>   1) Alice extracts the issuer's public key (N,e) from the consensus
>   2) Alice computes a destination digest as follows:
>            dest_digest = FDH_N(destination || salt)
>               where:
>               - 'destination' is the 32-byte ed25519 public identity 
> key of the destination onion
>               - 'salt' is a random 32-byte value,
>   3) Alice samples a blinding factor 'r' uniformly at random from [1, N)
>   4) Alice computes:
>            blinded_message = dest_digest * r^e (mod N)
>   After this phase is completed, Alice has a blinded message that is tailored
>   specifically for the destination onion service. Alice will send the blinded
>   message to the Token Issuer, but because of the blinding the Issuer does not
>   get to learn the dest_digest value.
>   XXX Is the salt needed? Reevaluate.
> ### 4.3.3. Token Issuance [RES_ISSUANCE]
>   Alice now initiates contact with the Token Issuer and spends the resources
>   required to get issued a token (e.g. solve a CAPTCHA or a PoW, create an
>   account, etc.). After that step is complete, Alice sends the blinded_message
>   to the issuer through a JSON-RPC API.
>   After the Issuer receives the blinded_message it signs it as follows:
>         blinded_signature = blinded_message ^ d (mod N)
>           where:
>           - 'd' is the private RSA exponent.
>   and returns the blinded_signature to Alice.
>   XXX specify API (JSON-RPC? Needs SSL + pubkey pinning.)
> ### 4.3.4. Unblinding step
>   Alice verifies the received blinded signature, and unblinds it to get the
>   final token as follows:
>         token = blinded_signature * r^{-1} (mod N)
>               = blinded_message ^ d * r^{-1] (mod N)
>               = (dest_digest * r^e) ^d * r^{-1} (mod N)
>               = dest_digest ^ d * r * r^{-1} (mod N)
>               = dest_digest ^ d (mod N)
>           where:
>           - r^{-1} is the multiplicative inverse of the blinding factor 'r'
>   Alice will now use the 'token' to get access to the onion service.
>   By verifying the received signature using the issuer keys in the consensus,
>   Alice ensures that a legitimate token was received and that it has not
>   expired (since the issuer keys are still in the consensus).
> ## 4.4. Token redemption
> ### 4.4.1. Alice sends token to onion service
>   Now that Alice has a valid 'token' it can request access to the onion
>   service. It does so by embedding the token into the INTRODUCE1 cell to the
>   onion service.
>   To do so, Alice adds an extension to the encrypted portion of the INTRODUCE1
>   cell by using the EXTENSIONS field (see [PROCESS_INTRO2] section in
>   rend-spec-v3.txt). The encrypted portion of the INTRODUCE1 cell only gets
>   read by the onion service and is ignored by the introduction point.
>   We propose a new EXT_FIELD_TYPE value:
>     [02] -- ANON_TOKEN
>   The EXT_FIELD content format is:
>        TOKEN_VERSION    [1 byte]
>        ISSUER_KEY       [4 bytes]
>        DEST_DIGEST      [32 bytes]
>        TOKEN            [128 bytes]
>        SALT             [32 bytes]
>   where:
>    - TOKEN_VERSION is the version of the token ([0x01] for Res tokens)
>    - ISSUER_KEY is the public key of the chosen issuer (truncated to 4 bytes)
>    - DEST_DIGEST is the 'dest_digest' from above
>    - TOKEN is the 'token' from above
>    - SALT is the 32-byte 'salt' added during blinding
>   This will increase the INTRODUCE1 payload size by 199 bytes since the data
>   above is 197 bytes, the extension type and length is 2 extra bytes, and the
>   N_EXTENSIONS field is always present. According to ticket #33650, INTRODUCE1
>   cells currently have more than 200 bytes available so we should be able to
>   fit the above fields in the cell.
>   XXX maybe we don't need to pass DEST_DIGEST and we can just derive it
>   XXX maybe with a bit of tweaking we can even use a 1536-bit RSA 
> signature here...
> ### 4.4.2. Onion service verifies token  [RES_VERIFY]
>   Upon receiving an INTRODUCE1 cell with the above extension the service
>   verifies the token. It does so as follows:
>   1) The service checks its double spend protection cache for an element that
>      matches DEST_DIGEST. If one is found, verification fails.
>   2) The service checks: DEST_DIGEST == FDH_N(service_pubkey || SALT), where
>      'service_pubkey' is its own long-term identity pubkey.
>   3) The service finds the corresponding issuer pubkey 'e' based on ISSUER_KEY
>      from the consensus or its configuration file
>   4) The service checks: TOKEN ^ e == DEST_DIGEST
>   Finally the onion service adds the DEST_DIGEST to its double spend protection
>   cache to avoid the same token getting redeemed twice.  Onion services keep a
>   double spend protection cache by maintaining a sorted array of truncated
>   DEST_DIGEST elements.
>   If any of the above steps fail, the verification process aborts and the
>   introduction request gets discarded.
>   If all the above verification steps have been completed successfully, the
>   service knows that this a valid token issued by the token issuer, and that
>   the token has been created for this onion service specifically. The service
>   considers the token valid and the rest of the onion service protocol carries
>   out as normal.
> # 5. Token issuers [TOKEN_ISSUERS]
>   In this section we go over some example token issuers. While we can have
>   official token issuers that are supported by the Tor directory authorities,
>   it is also possible to have unofficial token issuers between communities that
>   can be embedded directly into the configuration file of the onion service and
>   the client.
>   In general, we consider the design of token issuers to be independent from
>   this proposal so we will touch the topic but not go too deep into it.
> ## 5.1. CAPTCHA token issuer
>   A use case resembling the setup of Cloudflare's PrivacyPass would be to have
>   a CAPTCHA service that issues tokens after a successful CAPTCHA solution.
>   Tor Project, Inc runs https://ctokens.torproject.org which serves hCaptcha
>   CAPTCHAs. When the user solves a CAPTCHA the server gives back a list of
>   tokens. The amount of tokens rewarded for each solution can be tuned based on
>   abuse level.
>   Clients reach this service via a regular Tor Exit connection, 
> possibly via a
>   dedicated exit enclave-like relay that can only connect to 
> https://ctokens.torproject.org.
>   Upon receiving tokens, Tor Browser delivers them to the Tor client via the
>   control port, which then stores the tokens into a token cache to be used when
>   connecting to onion services.
>   In terms of UX, most of the above procedure can be hidden from the user by
>   having Tor Browser do most of the things under the scenes and only present
>   the CAPTCHA to the user if/when needed (if the user doesn't have tokens
>   available for that destination).
>   XXX specify control port API between browser and tor
> ## 5.2. PoW token issuer
>   An idea that mixes the CAPTCHA issuer with proposal#327, would be to have a
>   token issuer that accepts PoW solutions and provides tokens as a reward.
>   This solution tends to be less optimal than applying proposal#327 directly
>   because it doesn't allow us to fine-tune the PoW difficulty based on the
>   attack severity; which is something we are able to do with proposal#327.
>   However, we can use the fact that token issuance happens over HTTP to
>   introduce more advanced PoW-based concepts. For example, we can design token
>   issuers that accept blockchain shares as a reward for tokens. For example, a
>   system like Monero's Primo could be used to provide DoS protection and also
>   incentivize the token issuer by being able to use those shares for pool
>   mining [REF_PRIMO].
> ## 5.3. Onion service self-issuing
>   The onion service itself can also issue tokens to its users and then use
>   itself as an issuer for verification. This way it can reward trusted users by
>   giving it tokens for the future. The tokens can be rewarded from within the
>   website of the onion service and passed to the Tor Client through the control
>   port, or they can be provided in an out-of-bands way for future use
>   (e.g. from a journalist to a future source using a QR code).
>   Unfortunately, the anonymous credential scheme specified in this proposal is
>   one-show, so the onion service cannot provide a single token that will work
>   for multiple "logins". In the future we can design multi-show credential
>   systems that also have revocation to further facilitate this use case (see
>   [FUTURE_RES] for more info).
> # 6. User Experience
>   This proposal has user facing UX consequences.
>   Ideally we want this process to be invisible to the user and things 
> to "just
>   work". This can be achieved with token issuers that don't require 
> manual work
>   by the user (e.g. the PoW issuer, or the onion service itself), since 
> both the
>   token issuance and the token redemption protocols don't require any 
> manual work.
>   In the cases where manual work is needed by the user (e.g. solving a CAPTCHA)
>   it's ideal if the work is presented to the user right before visiting the
>   destination and only if it's absolutely required. An explanation about the
>   service being under attack should be given to the user when the CAPTCHA is
>   provided.
> # 7. Security
>   In this section we analyze potential security threats of the above system:
>   - An evil client can hoard tokens for hours and unleash them all at once to
>     cause a denial of service attack. We might want to make the key rotation
>     even more frequent if we think that's a possible threat.
>   - A trusted token issuer can always DoS an onion service by forging tokens.
>   - Overwhelming attacks like "top half attacks" and "hybrid attacks" from
>     proposal#327 is valid for this proposal as well.
>   - A bad RNG can completely wreck the linkability properties of this proposal.
>   XXX Actually analyze the above if we think there is merit to listing them
> # 8. Discussion [DISCUSSION]
> ## 8.1. Using Res tokens on Exit relays
>   There are more scenarios within Tor that could benefit from Res tokens
>   however we didn't expand on those use cases to keep the proposal short.  In
>   the future, we might want to split this document into two proposals: one
>   proposal that specifies the token scheme, and another that specifies how to
>   use it in the context of onion servicves, so that we can then write more
>   proposals that use the token scheme as a primitive.
>   An extremely relevant use case would be to use Res tokens as a way to protect
>   and improve the IP reputation of Exit relays. We can introduce an exit pool
>   that requires tokens in exchange for circuit streams. The idea is that exits
>   that require tokens will see less abuse, and will not have low scores in the
>   various IP address reputation systems that now govern who gets access to
>   websites and web services on the public Internet. We hope that this way we
>   will see  less websites blocking Tor.
> ## 8.2. Future improvements to this proposal [FUTURE_RES]
>   The Res token scheme is a pragmatic scheme that works for the space/time
>   constraints of this use case but it's far from ideal for the greater future
>   (RSA? RSA-1024?).
>   After Tor proposal#319 gets implemented we will be able to pack more data in
>   RELAY cells and that opens the door to token schemes with bigger token
>   sizes. For example, we could design schemes based on BBS+ that can provide
>   more advanced features like multi-show and complex attributes but currently
>   have bigger token sizes (300+ bytes). That would greatly improve UX since the
>   client won't have to solve multiple CAPTCHAs to gain access. Unfortunately,
>   another problem here is that right now pairing-based schemes have
>   significantly worse verification performance than RSA (e.g. in the order of
>   4-5 ms compared to <0.5 ms). We expect pairing-based cryptography performance
>   to only improve in the future and we are looking forward to these advances.
>   When we switch to a multi-show scheme, we will also need revocation support
>   otherwise a single client can abuse the service with a single multi-show
>   token. To achieve this we would need to use blacklisting schemes based on
>   accumulators (or other primitives) that can provide more flexible revocation
>   and blacklisting; however these come at the cost of additional verification
>   time which is not something we can spare at this time. We warmly welcome
>   research on revocation schemes that are lightweight on the verification side
>   but can be heavy on the proving side.
> ## 8.3. Other uses for tokens in Tor
>   There is more use cases for tokens in Tor but we think that other token
>   schemes with different properties would be better suited for those.
>   In particular we could use tokens as authentication mechanisms for logging
>   into services (e.g. acquiring bridges, or logging into Wikipedia). However
>   for those use cases we would ideally need multi-show tokens with revocation
>   support. We can also introduce token schemes that help us build a secure name
>   system for onion services.
>   We hope that more research will be done on how to combine various token
>   schemes together, and how we can maintain agility while using schemes with
>   different primitives and properties.
> # 9. Acknowledgements
>   Thanks to Jeff Burdges for all the information about Blind RSA and anonymous
>   credentials.
>   Thanks to Michele Orrù for the help with the unlinkability proof and for the
>   discussions about anonymous credentials.
>   Thanks to Chelsea Komlo for pointing towards anonymous credentials in
>   the context of DoS defenses for onion services.
> ---
> # Appendix A: RSA Blinding Security Proof [BLIND_RSA_PROOF]
>   This proof sketch was provided by Michele Orrù:
>   ```
>   RSA Blind Sigs: 
> https://en.wikipedia.org/wiki/Blind_signature#Blind_RSA_signatures
>   As you say, blind RSA should be perfectly blind.
>   I tried to look at Boneh-Shoup, Katz-Lindell, and Bellare-Goldwasser 
> for a proof, but didn't find any :(
>   The basic idea is proving that:
>   for any  message "m0" that is blinded with "r0^e" to obtain "b" (that 
> is sent to the server), it is possible to freely choose another message 
> "m1" that blinded with another opening "r1^e" to obtain the same "b".
>   As long as r1, r0 are chosen uniformly at random, you have no way of 
> telling if what message was picked and therefore it is *perfectly* 
> blind.
>   To do so:
>   Assume the messages ("m0" and "m1") are invertible mod N=pq (this 
> happens at most with overwhelming probability phi(N)/N if m is 
> uniformly distributed as a result of a hash, or you can enforce it at 
> signing time).
>   Blinding happens by computing:
>      b = m0 * (r0^e).
>   However, I can also write:
>      b = m0 * r0^e = (m1/m1) * m0 * r0^e = m1 * (m0/m1*r0^e).
>   This means that r1 = (m0/m1)^d * r0 is another valid blinding factor 
> for b, and it's distributed exactly as r0 in the group of invertibles 
> (it's unif at random, because r0 is so).
>   ```
> ---
> [REF_TOKEN_ZOO]: https://tokenzoo.github.io/
> https://gitlab.torproject.org/legacy/trac/-/issues/33650#note_2350910
> [REF_CHAUM]: https://eprint.iacr.org/2001/002.pdf
> [REF_PRIMO]: https://repo.getmonero.org/selene/primo
>              https://www.monerooutreach.org/stories/RPC-Pay.html
> https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/327-pow-over-intro.txt#L1050
> [REF_RES_BENCH]: https://github.com/asn-d6/res_tokens_benchmark
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

More information about the tor-dev mailing list