From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 21 May 2025 04:20:09 -0700 Received: from mail-oi1-f187.google.com ([209.85.167.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uHhUW-0008Et-Bo for bitcoindev@gnusha.org; Wed, 21 May 2025 04:20:09 -0700 Received: by mail-oi1-f187.google.com with SMTP id 5614622812f47-40343c606dcsf9043722b6e.1 for ; Wed, 21 May 2025 04:20:08 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1747826403; cv=pass; d=google.com; s=arc-20240605; b=d+LEKx/+Kj82Pr8mByBsZrb7eeLE1zxLFxNZPYEjrXHOtaMdzgpzkByO6OINuGT0nP RcM26kKH8q48/g8kirs327oEp990m27ONDpZTi6Lt4BUxZMNhUPyRTLS8G79yiXCRC0/ kTOQ2KXUYxuqqxLXPAz4qRKynak6KE8JzFjk6mjaLXmuKlb6/wAwa8Q+BC66heMy3JMG BZQvMHQ1MssBhM+J3bKBHS+mL/q2tYggklqEC1r51MPyRTCfKotVL+a+GXCMlj5nDuPC F7m9LpAic6gH7kT8dIVWRrehXaUhXQUS4q+N0Qe3m/orE5FWhorgHLecCBxJD48Z5uWY f56w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:mime-version:dkim-signature; bh=f6jZxxHn6LWol4YpEizRtUtidabkc42FECEpnD+BfiM=; fh=VoqNcDGO8TBauaKkMYId5UkjRsV8hkZ0JnLVObYlom8=; b=Ka4vxOP4gCRfNwAnaTa0sfJ0XrGo3KPf4zV2qvotrcsJeCNVBkKKW+D0Kc7NF27vmj KR9a0Y10KxjGmwJ8BfCgrBpCYVF1DLhRZhu5CUBGWKsyObQNn0SPwWQKh55ufJ/oFQ3i 4wfJwvy/nuMGOfqUUsJ7w2108h9s6f1XHmlUPGSHE2N8QsIJ1vYkhpnVbDiA1VBGZswE xABbTpm9/aG6OuXabh2NmU3kEj/cs8hvKo8CRRrN56fIt59NR0gxbOhfo+sJONuBWU+m rZloLuYkyoy/chWPoNkqv53NgfdcwsptWC4Ij9dClqsrov3NX7z7Jm7HwJzrJVd+JQB8 Q/bg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@cloudflare.com header.s=google09082023 header.b=SmpfPs7t; spf=pass (google.com: domain of bas@cloudflare.com designates 2607:f8b0:4864:20::b30 as permitted sender) smtp.mailfrom=bas@cloudflare.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cloudflare.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1747826402; x=1748431202; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:to:subject :message-id:date:from:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=f6jZxxHn6LWol4YpEizRtUtidabkc42FECEpnD+BfiM=; b=a9P+Zz/Rr2Wuy9U68RtV2G3iGrzpWgQ4GEvLMj4oTSgaqXRZt/lkRzf2S+mAY59OCq WKH/qEQhnsa+DllysmrcYrs+G6pCHQFRLdizzqfdwDRqV0kEgZoXVNp+BaWnB9ycaKdH O/Igy7ioiE5aTsF4pMvmqKS/mji5x77/qxS2w10LxBwEzDw8s4pgh7IS6aiQckFZHQf1 Yv03F4ToNKdRpdkvSLLryRCxS/ZZrYezhCNZ9kT2BC3PFSpfRIaYgswLDHDnyPzyRhIh DA9h+2jnNvbiZhdqLC2lhidhVVhwHVuOMTUCJk0IcOWdBsQbQ4RyKE4+ESNJ20qywskT lRfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747826402; x=1748431202; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:to:subject :message-id:date:from:mime-version:x-beenthere:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=f6jZxxHn6LWol4YpEizRtUtidabkc42FECEpnD+BfiM=; b=wRRZhNJ4tEf1P+R9NE/y9Ee8nQESKPYdiWUosDOi0CDOha3CDkPkhEzJQeEkcpzjTR tpSiAS+Qmd3tupR7OVx5SMep52+f//QdXP91OpqPGh8IxkNWzNy9DIV0OwSxJpO/x21D aFwlXmzAHTwG4FL+xsQFn6NvtG67l5ONNvGT41esKse/utKU88WAezswcfATIBUBuFuE 9ClT5MhSMyN66TmbU+THBU4W5fO8EEnLCJPj5sOZiruDW1ks3KkFglfS8scTCXfC0djY meBwpaJiMJ7ozo6b8dJ7Phk3tKGpUcThcg3TQuAhN05zjumxOcrEwu06iQIVPPcP2STk noiA== X-Forwarded-Encrypted: i=2; AJvYcCVgaUb/oc0RGvMDXoBwjX1Vc7N8eWXYyJQFvCkpGADWKRnA+ZMt/+Y62Damju9NfO9sX/CaY3iELMPX@gnusha.org X-Gm-Message-State: AOJu0YwVBezAldm2BXF0NFuxHgFool5Y57PvSO3BNwEzfk7CM39D1WDV 5LhLM2qbU05redohM7Uws3vX0d8PrvSPVs1W3WGiT58Abx6hHDoekfBk X-Google-Smtp-Source: AGHT+IEyyY7T5ljs5isP8ZQ+NtpX39L2V3tYSktS+adQRKFsC9mdq33TXOAZ7vAiGlJEe9pglR+Iyg== X-Received: by 2002:a05:6808:398c:b0:401:bb4c:af33 with SMTP id 5614622812f47-404d885e0c9mr12750602b6e.27.1747826402616; Wed, 21 May 2025 04:20:02 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBHoI2FOR9XslPAtvKJEzj11S10tZlW0owOgdrUpKNifPQ== Received: by 2002:a05:6820:828b:b0:609:1093:ed15 with SMTP id 006d021491bc7-609ea3111c4ls1210239eaf.0.-pod-prod-09-us; Wed, 21 May 2025 04:19:59 -0700 (PDT) X-Received: by 2002:a05:6808:6a85:b0:404:78f9:771a with SMTP id 5614622812f47-404d8856929mr13593738b6e.26.1747826398950; Wed, 21 May 2025 04:19:58 -0700 (PDT) Received: by 2002:a05:6808:82c7:b0:3f6:a384:eb6f with SMTP id 5614622812f47-404da00d5efmsb6e; Wed, 21 May 2025 03:32:46 -0700 (PDT) X-Received: by 2002:a17:90b:1846:b0:30e:7afd:1a56 with SMTP id 98e67ed59e1d1-30e7d5bb449mr25798605a91.34.1747823565703; Wed, 21 May 2025 03:32:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1747823565; cv=none; d=google.com; s=arc-20240605; b=ftl54Y8T1KTg9eZaYyjj3i970C+n0V4GK+qxeJq56T+0ipLH5XJpysxIa6rYwr75qs YnUfBYSt0/t2VlB5yu3F/q5bKdVD2+IXzQqFapASqi2+azqGmI4P0vVAgOQULh5Gc0Lo 55hHlu8Bs9LSCg+UMALXiKMshEge7oo8mZ5XCLeb16wwqTZEjE/UHKpMXPgqW25g2u7Y GxRLzI1gH5uzCoQKrHfRWrOQpZ236ojmJJha1CZ3NWmUYhVEXqYgKdd+ODi3n0dAvxas gI1RQHWb8oTf/VcWFu8uOWFYkS2uOoLpG1gHW2Y7KpqhqKvUlKSMZZvZl/G4i10jNn2Z lwRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=y+5lhaSj99VHxQCzrc0RmqoE6VlpYJdqsMyWIU1NLqo=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=eDtAD6JX3A+8xkHXZVrxk9pge4C7a+6vBKSuX9YM+wQOIUG8J5EF2DGCwO4YTKNai1 MdsQCXLkNPnnqDGQMsrJBIaYWc6/xCP6PqRbzGHKVi0lY3bBwWx/PBrTuJSlkHh1Z7We 6nx8fhHxNl7Mvmb3YehwSJHtmUuShfQUdMMbEQ2YKMuXwxr1Zl8nsnr4RgKcmkbGkVhH EPkl99HgdzzbDvpeksw94STf6H3EpVdNC33YMAcEUPz+O/ZcyFK6F7W4n5p+huhgPxgL C3m/88609k4R/ymP8CpAd5CveYD1bPkavbva5L5ofY3rKaMguMjpRXoRoHQCkUIiCG1x 8dHw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@cloudflare.com header.s=google09082023 header.b=SmpfPs7t; spf=pass (google.com: domain of bas@cloudflare.com designates 2607:f8b0:4864:20::b30 as permitted sender) smtp.mailfrom=bas@cloudflare.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cloudflare.com; dara=pass header.i=@googlegroups.com Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com. [2607:f8b0:4864:20::b30]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-30e5c14b62dsi1024389a91.0.2025.05.21.03.32.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 May 2025 03:32:45 -0700 (PDT) Received-SPF: pass (google.com: domain of bas@cloudflare.com designates 2607:f8b0:4864:20::b30 as permitted sender) client-ip=2607:f8b0:4864:20::b30; Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-e740a09eb00so5848247276.0 for ; Wed, 21 May 2025 03:32:45 -0700 (PDT) X-Gm-Gg: ASbGncsFwYqC6jpTI5XF1t9O/VuDBKH0WJbuxsqE9wUNUzFsOKphV6naEb5DA+qXkIh sobwJPptDGz2he+Y7oTpMczFNLYzQ7oP/gk/RWyjq0jLujuUXw23waJuUOtGt+c2t9+rpxOIrC6 Wpn/2Tl9jDluMIylVViRYv2LYVfmptZxqzRgRNbd2kF3dvR+yR38c= X-Received: by 2002:a05:6902:2201:b0:e7b:8dec:7ef5 with SMTP id 3f1490d57ef6-e7b8dec7ff0mr20212144276.27.1747823564821; Wed, 21 May 2025 03:32:44 -0700 (PDT) MIME-Version: 1.0 From: "'Bas Westerbaan' via Bitcoin Development Mailing List" Date: Wed, 21 May 2025 12:32:33 +0200 X-Gm-Features: AX0GCFtQ7G07iDDYBFkGiZ9czondlFXOpvelh_R6aD9VaES_FyZtOMOCnHQ2t_Q Message-ID: Subject: [bitcoindev] jpeg resistance of various post-quantum signature schemes To: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000b635280635a2e275" X-Original-Sender: bas@cloudflare.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@cloudflare.com header.s=google09082023 header.b=SmpfPs7t; spf=pass (google.com: domain of bas@cloudflare.com designates 2607:f8b0:4864:20::b30 as permitted sender) smtp.mailfrom=bas@cloudflare.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cloudflare.com; dara=pass header.i=@googlegroups.com X-Original-From: Bas Westerbaan Reply-To: Bas Westerbaan Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 2.2 (++) --000000000000b635280635a2e275 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, My colleague Ethan asked me the fun question which post-quantum signature schemes have the following security property, which he called jpeg resistance. Attacker wins if for a (partially specified) signature and full message, they can find a completed signature and public key, such that the completed signature verifies under the public key. A naive hash-based signature is not jpeg resistant. Schoolbook Winternitz one-time signatures, forest-of-trees few-time signatures, and Merkle trees all validate signatures (/authentication paths) by recomputing the public key (/Merkle tree root) from the signature and the message, and checking whether the recomputed public key matches the actual public key. That means we can pick anything for the signature, and just set the public key to the recomputed public key. The situation is more subtle for actual standardized hash-based signatures. RFC 8391 XMSS doesn=E2=80=99t sign the message itself, but first hashes in = (among others) the public key. Basically the best we can do for XMSS (except for setting the signature randomizer) is to guess the public key. Thus it=E2=80= =99s pretty much jpeg resistant. The situation is different again for RFC 8391 XMSSMT. XMSSMT is basically a certificate chain of XMSS signatures. An XMSSMT public key is an XMSS public key. An XMSSMT signature is a chain of XMSS signatures: the XMSSMT public key signs another XMSS public key; which signs another public XMSS public key; =E2=80=A6; which signs the message. Again the top XMSSMT public= key is hashed into the message signed, but that only binds the first XMSS signature. We can=E2=80=99t mess with the first signature, but the other si= gnatures we can choose freely, as those roots are not bound. Thus XMSSMT with two subtrees is only half jpeg resistant and it gets worse with more subtrees. Similarly SLH-DSA (FIPS 205, n=C3=A9e SPHINCS+) is a certificate chain of (= a variant of) XMSS signing another XMSS public key, which signs another XMSS public key, etc, which signs a FORS public key, which signs the final message. The SLH-DSA public key is the first XMSS public key. From the message and the public key it derives the FORS key pair (leaf) in the hyper tree to use to sign, and the message to actually sign. This means we can=E2= =80=99t mess with the first XMSS keypair. Thus to attack SLH-DSA we honestly generate the first XMSS keypair. Then given a message, we just pick the signature arbitrarily for all but the first XMSS signature. We run the verification routine to recompute the root to sign by the first XMSS keypair. Then we sign it honestly. It depends a bit on the parameters, but basically we get to pick roughly =E2=85=9E of the signature for free. ML-DSA (FIPS 204, n=C3=A9e Dilithium) is a Fiat=E2=80=93Shamir transform of= a (module-)lattice identification scheme. In the identification scheme the prover picks a nonce y, and sends the commitment w1 =3D HighBits(A y) to th= e verifier, where A is a matrix that=E2=80=99s part of the public key and Hig= hBits drops the lower bits (of the coefficients of the polynomials in the vector). The verifier responds with a challenge c, to which the prover returns the response z =3D y + c s1, where s1 is part of the private key. T= he verifier checks, among other things, whether HighBits(Az-ct) =3D w1, where = t =3D As1+s2 is part of the public key. As usual with Fiat=E2=80=93Shamir, in= ML-DSA the challenge c is the hash of the commitment, message, and public key. The scheme has commitment recovery, so the signature itself consists of the response z and the challenge c. (There is also a hint h, but that=E2=80=99s= small and we can ignore it.) If we set s1 to zero, then z=3Dy, which is free to choose. So we can freely choose z, which is by far the largest part of the signature. Such a public key t is easy to detect, as it has small coefficients. Instead we can set s1 to zero on only a few components. That allows us to choose z arbitrarily for those components, still breaking jpeg resistance, while being hard to detect. There could well be other approaches here. Falcon. A Falcon private key are small polynomials f,g. Its public key is h =3D g f-1. With the private key, for any polynomial c, we can compute small= s1 and s2 with s1 + s2h =3D c. A Falcon signature is a pair r, s2 where s1 =3D H(r, m) - s2 h is small. s2 is Guassian distributed, and is encoded using an Elias=E2=80=93Fano approach. It=E2=80=99s then padded to make signatures= fixed-length. Clearly the randomizer r can be set arbitrarily, but it=E2=80=99s only 40 b= ytes. Putting arbitrary bytes in most of the encoding of s2 will likely yield a sufficiently small s2. Now, I thought about using this s2 as a new g and construct a signature that way by finding s=E2=80=991 and s=E2=80=992 with = s=E2=80=991 + s=E2=80=992s1f-1 =3D H(r,m), but my brother suggested a simpler approach. s2 is likely invertible and we can set h =3D H(r, m)/s2. Both approaches would be thwart= ed by using H(H(h), r, m) instead of H(r, m). I do not know if there is still another attack. Best, Bas --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CAMjbhoU%3DPCUwbhWFbqCbOdZc%2BybmREJmmt1K1TuHrCTncKH6VA%40mail.gmail.com. --000000000000b635280635a2e275 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi all,


My colleague Ethan asked me the fun question w= hich post-quantum signature schemes have the following security property, w= hich he called jpeg resistance.


Attacker wins if for a (partially specified) signature and full messa= ge, they can find a completed signature and public key, such that the compl= eted signature verifies under the public key.


A naive hash-based s= ignature is not jpeg resistant. Schoolbook Winternitz one-time signatures, = forest-of-trees few-time signatures, and Merkle trees all validate signatur= es (/authentication paths) by recomputing the public key (/Merkle tree root= ) from the signature and the message, and checking whether the recomputed p= ublic key matches the actual public key. That means we can pick anything fo= r the signature, and just set the public key to the recomputed public key.<= /span>


The situation is more subtle for actual standardized hash-based si= gnatures. RFC 8391 XMSS doesn=E2=80=99t sign the messag= e itself, but first hashes in (among others) the public key. Basically the = best we can do for XMSS (except for setting the signature randomizer) is to= guess the public key. Thus it=E2=80=99s pretty much jpeg resistant.=


The situation is different again for RFC 8391 XMSSMT. XMSSMT= is basically a certificate chain of XMSS signatures. An XMSSMT public key is an XMSS= public key. An XMSS= MT signature is a chain of XMSS signatures: the XMSSMT public key signs anot= her XMSS public key; which signs another public XMSS public key; =E2=80=A6;= which signs the message. Again the top XMSSMT public key is hashed into the message s= igned, but that only binds the first XMSS signature. We can=E2=80=99t mess = with the first signature, but the other signatures we can choose freely, as= those roots are not bound. Thus XMSSMT with two subtrees is only half jpeg resistant = and it gets worse with more subtrees.


Similarly = SLH-DSA (FIPS 205, n=C3=A9e SPHINCS+) is a certificate chain of (a variant of) XMSS = signing another XMSS public key, which signs another XMSS public key, etc, = which signs a FORS public key, which signs the final message. The SLH-DSA p= ublic key is the first XMSS public key. From the message and the public key= it derives the FORS key pair (leaf) in the hyper tree to use to sign, and = the message to actually sign. This means we can=E2=80=99t mess with the fir= st XMSS keypair. Thus to attack SLH-DSA we honestly generate the first XMSS= keypair. Then given a message, we just pick the signature arbitrarily for = all but the first XMSS signature. We run the verification routine to recomp= ute the root to sign by the first XMSS keypair. Then we sign it honestly. I= t depends a bit on the parameters, but basically we get to pick roughly =E2= =85=9E of the signature for free.


ML-DSA (FIPS 2= 04, n=C3=A9e Dilithium) is a Fiat=E2=80=93Shamir transform of a (module-)la= ttice identification scheme. In the identification scheme the prover picks = a nonce y, and sends the commitment w1 =3D HighBits(A y) to the verifier, where A is a m= atrix that=E2=80=99s part of the public key and HighBits drops the lower bi= ts (of the coefficients of the polynomials in the vector). The verifier res= ponds with a challenge c, to which the prover returns the response z =3D y = + c s1, where= s1 is part o= f the private key. The verifier checks, among other things, whether HighBit= s(Az-ct) =3D w1= , where t =3D As1+s2 is = part of the public key. As usual with Fiat=E2=80=93Shamir, in ML-DSA the ch= allenge c is the hash of the commitment, message, and public key. The schem= e has commitment recovery, so the signature itself consists of the response= z and the challenge c. (There is also a hint h, but that=E2=80=99s small a= nd we can ignore it.) If we set s1 to zero, then z=3Dy, which is free to choose. So we c= an freely choose z, which is by far the largest part of the signature. Such= a public key t is easy to detect, as it has small coefficients. Instead we= can set s1 t= o zero on only a few components. That allows us to choose z arbitrarily for= those components, still breaking jpeg resistance, while being hard to dete= ct. There could well be other approaches here.


Fal= con. A Falcon private key are small polynomials f,g. Its public key is h = =3D g f-1. = With the private key, for any polynomial c, we can compute small s1 and s2 with s1 + s2h =3D c. A Falcon signature is a pair = r, s2 where s= 1 =3D H(r, m)= - s2 h is sm= all. s2<= span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);= background-color:transparent;font-variant-numeric:normal;font-variant-east-= asian:normal;font-variant-alternates:normal;vertical-align:baseline"> is Gu= assian distributed, and is encoded using an Elias=E2=80=93Fano approach. It= =E2=80=99s then padded to make signatures fixed-length. Clearly the randomi= zer r can be set arbitrarily, but it=E2=80=99s only 40 bytes. Putting arbit= rary bytes in most of the encoding of s2 will likely yield a sufficiently small s= 2. Now, I thought ab= out using this s2 as a new g and construct a signature that way by finding s=E2=80=99<= span style=3D"font-size:0.6em;vertical-align:sub">1 and s=E2=80=99= 2 with s=E2= =80=991<= span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);= background-color:transparent;font-variant-numeric:normal;font-variant-east-= asian:normal;font-variant-alternates:normal;vertical-align:baseline"> + s= =E2=80=992s= 1f-1 =3D H(r,m), but my br= other suggested a simpler approach. s2 is likely invertible and we can set h =3D H(r, m)= /s2. Both app= roaches would be thwarted by using H(H(h), r, m) instead of H(r, m). I do n= ot know if there is still another attack.


Best,


=C2=A0Bas=


--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/= d/msgid/bitcoindev/CAMjbhoU%3DPCUwbhWFbqCbOdZc%2BybmREJmmt1K1TuHrCTncKH6VA%= 40mail.gmail.com.
--000000000000b635280635a2e275--