Delivery-date: Sat, 03 May 2025 05:08:00 -0700
Sender: bitcoindev@googlegroups.com
Date: Sat, 3 May 2025 05:02:12 -0700 (PDT)
From: Greg Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <fbf06c5b-57b6-4615-99bb-3a7ea31ebf22n@googlegroups.com>
In-Reply-To: <CAExE9c8XfEH__onX3DhUQh0OnvpoOLwRRp8+Z6PozyKGtqpspw@mail.gmail.com>
References: <CAPv7TjaM0tfbcBTRa0_713Bk6Y9jr+ShOC1KZi2V3V2zooTXyg@mail.gmail.com>
 <cc2dfa79-89f0-4170-9725-894ea189a0e2n@googlegroups.com>
 <CAPv7TjaDGr4HCdQ0rR6_ma5zh2umU9r3_529szdswn_GjjnuCw@mail.gmail.com>
 <69194329-4ce6-4272-acc5-fd913a7986f3n@googlegroups.com>
 <CAExE9c8XfEH__onX3DhUQh0OnvpoOLwRRp8+Z6PozyKGtqpspw@mail.gmail.com>
Subject: Re: [bitcoindev] Re: SwiftSync - smarter synchronization with hints
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_114048_2047070228.1746273732107"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_114048_2047070228.1746273732107
Content-Type: multipart/alternative; 
	boundary="----=_Part_114049_1352252162.1746273732107"

------=_Part_114049_1352252162.1746273732107
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Saturday, May 3, 2025 at 11:55:28=E2=80=AFAM UTC Sanket Kanjalkar wrote:

> hash(UTXO_A||salt) + hash(UTXO_B||salt) - hash(UTXO_C||salt) -=20
hash(UTXO_D||salt) =3D=3D 0 (proving (A=3D=3DC && B=3D=3DD) || (A=3D=3DD &&=
 B=3D=3DC))

What if instead of hash we encrypt with AES and modular add/subs? I cannot=
=20
prove it; but I also don't see a clear way this is broken.=20

1. Sample random symmetric key `k`
2. Instead of above; AES_k(UTXO_A) + AES_k(UTXO_B) - AES_k(UTXO_C) -=20
AES(UTXO_D) =3D=3D 0 =3D>  (proving (A=3D=3DC && B=3D=3DD) || (A=3D=3DD && =
B=3D=3DC))?


AES in CTR mode is, I'm not sure about other modes? Obviously CTR mode=20
would be unsuitable! (I mean sure modular add/sub and xor are different=20
operations but they are quite close).  I think that in many modes the=20
collision resistance would have to at least be restricted by the birthday=
=20
bound with the small block size. I think CMC might be needed to avoid that=
=20
sort of issue.

=20

--=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/=
fbf06c5b-57b6-4615-99bb-3a7ea31ebf22n%40googlegroups.com.

------=_Part_114049_1352252162.1746273732107
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">On Saturday, May 3, 2025 at 11:55:28=E2=80=AFAM UTC =
Sanket Kanjalkar wrote:<br /></div><blockquote style=3D"margin: 0px 0px 0px=
 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div=
 dir=3D"ltr">&gt; hash(UTXO_A||salt) + hash(UTXO_B||salt) - hash(UTXO_C||sa=
lt) - hash(UTXO_D||salt) =3D=3D 0 (proving (A=3D=3DC &amp;&amp; B=3D=3DD) |=
| (A=3D=3DD &amp;&amp; B=3D=3DC))<br /><br /></div><div dir=3D"ltr">What if=
 instead of hash we encrypt with AES and modular add/subs? I cannot prove i=
t; but I also don't see a clear way this is broken.=C2=A0<br /><br />1. Sam=
ple random symmetric key `k`<br />2. Instead of above; AES_k(UTXO_A) + AES_=
k(UTXO_B) - AES_k(UTXO_C) - AES(UTXO_D) =3D=3D 0 =3D&gt;=C2=A0=C2=A0(provin=
g (A=3D=3DC &amp;&amp; B=3D=3DD) || (A=3D=3DD &amp;&amp; B=3D=3DC))?</div><=
/blockquote><div><br /></div><div>AES in CTR mode is, I'm not sure about ot=
her modes? Obviously CTR mode would be unsuitable! (I mean sure modular add=
/sub and xor are different operations but they are quite close).=C2=A0 I th=
ink that in many modes the collision resistance would have to at least be r=
estricted by the birthday bound with the small block size. I think CMC migh=
t be needed to avoid that sort of issue.</div><div><br /></div><div>=C2=A0<=
/div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/fbf06c5b-57b6-4615-99bb-3a7ea31ebf22n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/fbf06c5b-57b6-4615-99bb-3a7ea31ebf22n%40googlegroups.com</a>.<br />

------=_Part_114049_1352252162.1746273732107--

------=_Part_114048_2047070228.1746273732107--