From joachim at strombergson.com Tue Sep 1 05:44:44 2026 From: joachim at strombergson.com (=?utf-8?q?Joachim_Str=C3=B6mbergson?=) Date: Tue, 01 Sep 2026 11:44:44 +0200 Subject: [Cryptography] creating test vectors In-Reply-To: <3631448.QJadu78ljV@puma> References: <3631448.QJadu78ljV@puma> Message-ID: <0F7A0C07-89FB-48F9-A711-04E4B2602FE7@strombergson.com> Typically you see: - ?abc? - all zero, all ones - every even, every odd bit set - Known text snippets. Makes it easy to read when decrypted - Test vectors that verify block boundaries, any padding schemes (like forcing one extra block in the case of SHA-256 for example.). Edge cases - Test vectors that check specified requirements, limits, constraints - Long runs - 1M blocks for block cipher, hash function On 31 Aug 2026, at 10:55, Pierre Abbat wrote: > I have some 96-byte > keys which differ in the last byte, which will result in only a few bytes > different in the ciphertext. That sounds _very_ concerning. /JS -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 870 bytes Desc: OpenPGP digital signature URL: From phma at bezitopo.org Wed Sep 2 04:27:37 2026 From: phma at bezitopo.org (Pierre Abbat) Date: Wed, 02 Sep 2026 04:27:37 -0400 Subject: [Cryptography] creating test vectors In-Reply-To: <0F7A0C07-89FB-48F9-A711-04E4B2602FE7@strombergson.com> References: <3631448.QJadu78ljV@puma> <0F7A0C07-89FB-48F9-A711-04E4B2602FE7@strombergson.com> Message-ID: <2086219.8hb0ThOEGa@puma> On Tuesday, September 1, 2026 5:44:44 AM EDT Joachim Str?mbergson wrote: > Typically you see: > > - ?abc? > - all zero, all ones I've done this. > - every even, every odd bit set I haven't used these; I guess I should also use Thue-Morse (0x69969669). > - Known text snippets. Makes it easy to read when decrypted Check > - Test vectors that verify block boundaries, any padding schemes (like > forcing one extra block in the case of SHA-256 for example.). Edge cases - For Twistree, a hash function with a 32-byte block, I used 31-byte, 96-byte, and 33-byte known text snippets. A plaintext whose size is a multiple of 32 has a whole block of padding added. These are the texts: text31 = "?????? ??? ????? " #-start of Bible text33 = "?rv?zt?r? t?k?rf?r?g?pek" key96 = "????????????????????????.???????????????????????!" # key96 is also used as a plaintext for hashing because 32|96. In text31, it looks like there's a space before the first letter, but it's actually after the last; I cut it off after the space between "Elohim" and "et". > Test vectors that check specified requirements, limits, constraints > - Long runs - 1M blocks for block cipher, hash function I use a 59049-byte plaintext for testing Twistree. I can check the whole hash, which is 32 bytes long regardless of how much text is hashed. For a cipher, though, I'd have to spot-check it: if you take every 8191st byte, it should be such and such. > That sounds _very_ concerning. This is just a test vector. In actual use, you wouldn't use a 96-byte key to encrypt a 39-byte plaintext; you'd use a shorter key, like 16 to 32 bytes, and make the plaintext long enough that the key is finished with at least a round or two left; the remaining rounds will use the key passed through an LFSR, so a change in the last byte of the key will result in many bytes of scheduled key being changed. This is not a problem with Wring and Twistree, which have a completely different key schedule that derives the S-boxes from the key. I made sure that changing the last byte of a 96-byte key results in completely different S- boxes. Pierre -- I believe in Yellow when I'm in Sweden and in Black when I'm in Wales. From cryptography at mdpi.com Wed Sep 2 23:04:03 2026 From: cryptography at mdpi.com (Cryptography Editorial Office) Date: Thu, 3 Sep 2026 11:04:03 +0800 Subject: [Cryptography] (IF 2.4, CiteScore 6.4) Selected Papers in Volume 8, Issue 4 In-Reply-To: References: <1b8aba93-8ffb-5395-075f-bdf4f66eb76c@mdpi.com> <2dfffa04-f8fe-dbd7-b5a7-0022fa8ecf86@mdpi.com> <7b4b011a-473c-45f2-aa35-1d325d2091ed@mdpi.com> <60fa0ef2-008f-1bba-9108-6c19a3980563@mdpi.com> <0b15e2da-b4bd-321e-c601-642fb7c207dc@mdpi.com> <7b64deeb-6a2b-33d0-0281-978e39a75a67@mdpi.com> <7f95109a-ad6f-08dd-070e-991b2e79bcc3@mdpi.com> Message-ID: We are sharing with you some selected papers published in the open access journal /Cryptography/ (https://www.mdpi.com/journal/cryptography) Volume 8, Issue 4, which are free to access and can be downloaded here: 1. Implantable Medical Device Security https://www.mdpi.com/2410-387X/8/4/53 2. A Matrix Multiplication Approach to Quantum-Safe Cryptographic Systems https://www.mdpi.com/2410-387X/8/4/56 3. A Secure Approach Out-of-Band for e-Bank with Visual Two-Factor Authorization Protocol https://www.mdpi.com/2410-387X/8/4/51 4. Post-Quantum Secure ID-Based (Threshold) Linkable Dual-Ring Signature and Its Application in Blockchain Transactions https://www.mdpi.com/2410-387X/8/4/48 5. Lightweight Mutually Authenticated Key Exchange with Physical Unclonable Functions https://www.mdpi.com/2410-387X/8/4/46 6. Partial Exposure Attacks on a New RSA Variant https://www.mdpi.com/2410-387X/8/4/44 See this full volume via https://www.mdpi.com/2410-387X/8. Additionally, we welcome your submissions if you have relevant papers to be submitted. Please contact the journal editorial office cryptography at mdpi.com. Best regards, Xue Cheng Managing Editor -- MDPI Branch Office, Wuhan Cryptography Editorial Office https://www.mdpi.com/journal/cryptography MDPI, Grosspeteranlage 5, 4052 Basel, Switzerland Twitter: @Cryptogr_MDPI https://twitter.com/Cryptogr_MDPI LinkedIn: Cryptography-MDPI From cryptskii at proton.me Thu Sep 3 08:50:10 2026 From: cryptskii at proton.me (cryptskii at proton.me) Date: Thu, 03 Sep 2026 12:50:10 +0000 Subject: [Cryptography] DSM: deterministic state machine (edge, post-quantum, no public ledger/consensus) In-Reply-To: References: Message-ID: Hey everyone, I feel like this may be the most worthwhile share that I have provided this mailing list. It took me a while, but I believe I finally got something that is explaining the system in a way that should click with most, if not everyone, in this mailing list. It's a long paper, but it's something that you can just pick back up and continue reading. It still has a good pace to it, but you can be the judge of that yourselves. https://www.deterministicstatemachine.org/DSM_High_Level_Explainer.pdf Best, Brandon From labyrinth-chall at proton.me Thu Sep 3 12:48:57 2026 From: labyrinth-chall at proton.me (labyrinth-chall) Date: Thu, 03 Sep 2026 16:48:57 +0000 Subject: [Cryptography] =?utf-8?q?LABYRINTH_=E2=80=94_a_new_state-evolvin?= =?utf-8?q?g_encryption_scheme=2C_public_challenge_with_a_cash_prize?= Message-ID: <6yT3Y232WXL-SWJ8QEHlKo2mWvCig8gP2_-Ii1kGruKJviVx3odxDcgQAlClKRSPsLAVFujiwCgr2l6uTUIG36JT0Nm5A9gOFAeJufk_tUc=@proton.me> Hello, I would like to submit for the list's evaluation a symmetric encryption algorithm, LABYRINTH?, together with a public cryptanalysis challenge built around it. LABYRINTH is based on an internal state of 1,000,000 bytes (large-scale homophonic substitution), whose evolution is driven by three parameters derived from a 512-bit key. The state evolves through block exchange and cyclic rotation, with a variable transition frequency tied to the session NONCE. The challenge has already been launched, on September 3, 2026, and is currently open. The full technical documentation, the ciphertext for the challenge, and the challenge rules (prize: USD 20,000 for the first person to recover the plaintext) are available at www.cifrare-documenti.com I'm well aware that the real test of an algorithm is independent analysis, not the designer's own claims. I welcome any critical feedback, on the challenge itself or on the underlying design. Thank you for your attention, Giuseppe Corallo labyrinth-chall at proton.me --- Inviato con la posta elettronica sicura [Proton Mail](https://proton.me/mail/home). -------------- next part -------------- An HTML attachment was scrubbed... URL: From phma at bezitopo.org Thu Sep 3 19:00:24 2026 From: phma at bezitopo.org (Pierre Abbat) Date: Thu, 03 Sep 2026 19:00:24 -0400 Subject: [Cryptography] =?utf-8?q?LABYRINTH_=E2=80=94_a_new_state-evolvin?= =?utf-8?q?g_encryption_scheme=2C_public_challenge_with_a_cash_prize?= In-Reply-To: <6yT3Y232WXL-SWJ8QEHlKo2mWvCig8gP2_-Ii1kGruKJviVx3odxDcgQAlClKRSPsLAVFujiwCgr2l6uTUIG36JT0Nm5A9gOFAeJufk_tUc=@proton.me> References: <6yT3Y232WXL-SWJ8QEHlKo2mWvCig8gP2_-Ii1kGruKJviVx3odxDcgQAlClKRSPsLAVFujiwCgr2l6uTUIG36JT0Nm5A9gOFAeJufk_tUc=@proton.me> Message-ID: <6830581.K2JlShyGXD@puma> On Thursday, September 3, 2026 12:48:57 PM EDT labyrinth-chall via cryptography wrote: > Hello, > > I would like to submit for the list's evaluation a symmetric encryption > algorithm, LABYRINTH?, together with a public cryptanalysis challenge built > around it. Where's the source code? Pierre -- li fi'u vu'u fi'u fi'u du li pa From mis at seiden.com Fri Sep 4 09:09:53 2026 From: mis at seiden.com (Mark Seiden) Date: Fri, 4 Sep 2026 15:09:53 +0200 Subject: [Cryptography] fyi: workforce reductions at bletchley park Message-ID: https://www.museumsassociation.org/museums-journal/news/2026/09/bletchley-park-to-reduce-its-workforce-by-12/#msdynmkt_trackingcontext=0c4e4d41-1c0e-4e87-a7d8-fac33dbb0200? Bletchley Park to reduce its workforce by 12% museumsassociation.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture1-e1788437397126.jpeg Type: image/jpeg Size: 28402 bytes Desc: not available URL: From hbaker1 at pipeline.com Fri Sep 4 15:05:13 2026 From: hbaker1 at pipeline.com (Henry Baker) Date: Fri, 04 Sep 2026 19:05:13 +0000 Subject: [Cryptography] Blockchained/digitally signed *MAPS* ? Message-ID: <0960881c-a9d1-717e-db57-bf6ca7fb5099@pipeline.com> The recent incident with Lake Ontario has proven how weak our digital maps are from censorship/manipulation/hacking. Two $4+ trillion market cap companies folded in less than few days last week to pressure from the US White House to make certain modifications to their (our ?) maps. So far, MaqQuest has not folded, but it remains to be seen how long Google and Apple will deign to allow MapQuest to remain available in their app stores. I haven't heard the kind of backlash about this mapping issue that it deserves. 1. If a Great Lake can be renamed overnight, what other changes *that we don't know about* have already been made to Google and Apple maps ? It might appear that such changes are *routine*, and the machinery was already in place to accede to government interference. Some possibilities come to mind, some quite nasty: if you fall out of favor, your business disappears from the map so your customers can't find you; if your precinct voted the wrong way in the last election, your precinct disappears from the map (so much for trying to vote in-person instead of by-mail). 2. The vast majority of wars since civilization invented maps in the first place have been fought over what those maps should say. Just ask an Israeli, a Palestinian, a Czech, a Taiwanese, a Ukrainian. We're talking about *billions* of people killed, maimed or displaced by casual changes to maps. 3. Digital maps have completely replaced paper maps, and most of us are literally lost without them. We routinely allow our GPS's to guide us to school, to a grocery store, to a gas station, to visit our relatives. People worry about LPR's surveilling us, but don't (yet) worry about a bigger problem: can we continue *trusting* our maps that guide us around in the first place ? ---- What can we do, when governments -- the traditional makers of "official" maps -- can no longer be trusted to provide accurate information ? There is OSM ("Open Street Map"), which is a crowd-sourced effort independent (as far as I can tell) of government censorship/manipulation/hacking. But given the stakes, it would appear that OSM's maps will require some sort of block-chaining and digital signatures to prove that they haven't been censored/manipulated/hacked. What can this crypto community do to develop *trusted* crowd-sourced maps like OSM ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandromontana at tutamail.com Sat Sep 5 17:37:52 2026 From: alejandromontana at tutamail.com (alejandromontana at tutamail.com) Date: Sat, 5 Sep 2026 23:37:52 +0200 (CEST) Subject: [Cryptography] Test flying Message-ID: https://github.com/efir369999/montana_messenger ? Alejandro ??You can?t parallelize your way out of time.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandromontana at tutamail.com Mon Sep 7 06:26:57 2026 From: alejandromontana at tutamail.com (alejandromontana at tutamail.com) Date: Mon, 7 Sep 2026 12:26:57 +0200 (CEST) Subject: [Cryptography] TimeChain In-Reply-To: References: Message-ID: The heart rate monitor is your best TimeChain. It measures your time. What do your colleagues think? ? Alejandro ??You can?t parallelize your way out of time.? Sep 6, 2026 at 23:58 by cryptography at metzdowd.com: > https://github.com/efir369999/montana_messenger > > ? > Alejandro > > ??You can?t parallelize your way out of time.? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sub0 at octade.net Mon Sep 7 22:43:39 2026 From: sub0 at octade.net (Byrl Raze Buckbriar) Date: Tue, 8 Sep 2026 02:43:39 -0000 Subject: [Cryptography] Syfer Sangraal : Holy Grail of Cryptography in the Arc of the Combinant Message-ID: <20260908024339.799c2f20.sub0@octade.net> Syfer Sangraal : Holy Grail of Cryptography in the Arc of the Combinant DOI : 10.5281/zenodo.22158384 == SUMMARY == Embark on the quest for the Syfer Sangraal system, or the holy grail of cryptography hidden in the arc of the combinant. One system to roll them all is the holy grail of cryptography. One algorithm to perform every kind of cryptographic function is the new wine within the Syfer Sangraal system. -- OCTADE | https://octade.net From johnl at iecc.com Tue Sep 8 04:02:45 2026 From: johnl at iecc.com (John Levine) Date: 8 Sep 2026 10:02:45 +0200 Subject: [Cryptography] Blockchained/digitally signed *MAPS* ? In-Reply-To: <0960881c-a9d1-717e-db57-bf6ca7fb5099@pipeline.com> References: <0960881c-a9d1-717e-db57-bf6ca7fb5099@pipeline.com> Message-ID: <20260908080245.6EB5011E56A9D@ary.local> It appears that Henry Baker said: >1. If a Great Lake can be renamed overnight, what other changes *that we don't know about* have already been made to Google >and Apple maps ? It might appear that such changes are *routine*, and the machinery was already in place to accede to >government interference. Changes to maps *are* routine. Cities and states build new roads, rebuild and reroute them. They rename streets and squares and even bodies of water all the time for entirely benign reasons like renaming something for a recently deceased local worthy. States renumber highways more often than you might think, again for benign reasons. For example, a highway near me which has been NY 17 since the 1920s is being piecewise renamed to I-86 as they upgrade it. A highway in New Jersey which was route 69 was renumbered to 31 because drunken students kept stealing the signs. I don't know any mechanical way to pick out the stupid ones from the normal ones. R's, John From hbaker1 at pipeline.com Tue Sep 8 09:46:53 2026 From: hbaker1 at pipeline.com (Henry Baker) Date: Tue, 08 Sep 2026 13:46:53 +0000 Subject: [Cryptography] Blockchained/digitally signed *MAPS* ? Message-ID: <174e34ba-8ee3-1c7e-f9c0-bb0508e3cf8b@pipeline.com> ve -----Original Message----- From: John Levine Sent: Sep 8, 2026 1:02 AM To: Cc: Subject: Re: [Cryptography] Blockchained/digitally signed *MAPS* ? It appears that Henry Baker said: >1. If a Great Lake can be renamed overnight, what other changes *that we don't know about* have already been made to Google >and Apple maps ? It might appear that such changes are *routine*, and the machinery was already in place to accede to >government interference. Changes to maps *are* routine. Cities and states build new roads, rebuild and reroute them. They rename streets and squares and even bodies of water all the time for entirely benign reasons like renaming something for a recently deceased local worthy. States renumber highways more often than you might think, again for benign reasons. For example, a highway near me which has been NY 17 since the 1920s is being piecewise renamed to I-86 as they upgrade it. A highway in New Jersey which was route 69 was renumbered to 31 because drunken students kept stealing the signs. I don't know any mechanical way to pick out the stupid ones from the normal ones. R's, John Uhhh, crypto signatures ? We have many of the same problems with other open source projects; parties who have become untrusted can no longer provide updates. It becomes a little harder when the untrusted party is a government, but this is also not a new problem. We have to start providing a crypto infrastructure that can provide levels of trust for mapping data. You may recall that all the street signs in southern England were removed during WWII in order to frustrate a possible invasion. You might also recall the episode in "Patton" when the street signs in northern France were spoofed (apparently a true story?). In the modern digital world, these things seem quite quaint, but we're going to be in far worse shape if someone could actually control all digital maps. From johnl at iecc.com Wed Sep 9 06:25:00 2026 From: johnl at iecc.com (John Levine) Date: 9 Sep 2026 12:25:00 +0200 Subject: [Cryptography] Blockchained/digitally signed *MAPS* ? In-Reply-To: <174e34ba-8ee3-1c7e-f9c0-bb0508e3cf8b@pipeline.com> References: <174e34ba-8ee3-1c7e-f9c0-bb0508e3cf8b@pipeline.com> Message-ID: <20260909102501.0D4F911E69751@ary.local> It appears that Henry Baker said: >>Changes to maps *are* routine. Cities and states build new roads, rebuild and >>reroute them. They rename streets and squares and even bodies of water all the >>time for entirely benign reasons like renaming something for a recently deceased >>local worthy. ... >>I don't know any mechanical way to pick out the stupid ones from the normal ones. >Uhhh, crypto signatures ? The normal changes and the stupid changes are distributed the same way and would have the same signatures. Like I said, I don't know any mechanical way to tell them apart. See, for example, https://support.google.com/mapcontentpartners/answer/10187434 R's, John From zeb at qtt.se Wed Sep 9 15:24:48 2026 From: zeb at qtt.se (zeb at qtt.se) Date: Wed, 09 Sep 2026 21:24:48 +0200 Subject: [Cryptography] Blockchained/digitally signed *MAPS* ? In-Reply-To: <20260909102501.0D4F911E69751@ary.local> References: <174e34ba-8ee3-1c7e-f9c0-bb0508e3cf8b@pipeline.com> <20260909102501.0D4F911E69751@ary.local> Message-ID: <3615de402cfcac1b2814b7705f82d57e@qtt.se> On 2026-09-09 12:25, John Levine wrote: > ... I don't know any mechanical way to tell them apart. I think that boils down to "people don't always agree on what's stupid vs normal". There are, of course, mechanical ways to give an answer, e.g. freeze an LLM (or a PRNG) and ask "Is this name change stupid or normal, answer with 'yes' or 'no' only". -------------- next part -------------- An HTML attachment was scrubbed... URL: From leichter at lrw.com Wed Sep 9 21:51:55 2026 From: leichter at lrw.com (Jerry Leichter) Date: Wed, 9 Sep 2026 21:51:55 -0400 Subject: [Cryptography] Blockchained/digitally signed *MAPS* ? In-Reply-To: <0960881c-a9d1-717e-db57-bf6ca7fb5099@pipeline.com> References: <0960881c-a9d1-717e-db57-bf6ca7fb5099@pipeline.com> Message-ID: > The recent incident with Lake Ontario has proven how weak our digital maps are from censorship/manipulation/hacking. Sorry, but no. The US maintains a database of the official names of various geographic features. It is within the President's authority to change the names. Whether the change is made for good reasons or bad, the fact is that this isn't censorship, manipulation, or hacking. Stupidity, yes - but the theoretical intelligence or rightness of an action has nothing to do with its legitimacy. > Two $4+ trillion market cap companies folded in less than few days last week to pressure from the US White House to make certain modifications to their (our ?) maps. > Both Google and Apple have long-established policies about how to name things. They pick up the names from the official databases in each country in which they operate. Where there's a dispute about naming, they have standard ways to indicate the appropriate naming for users nominally based in each country. Ultimately, this is no different from calling a central European country Germany when the selected language is English and Deutschland when the language is set to German. That one is non-controversial, but there are cases (Macedonia was one - Greece objected to Macedonia calling itself that because they view Macedonia as a region of Greece; I gather that got settled when the country renamed itself to North Macedonia) where the naming of whole countries is controversial. So Apple and Google didn't "fold" - they chose to leave their existing policies in place rather than get into a pissing contest with DJT. Would I have felt some admiration for them had they chosen to fight this fight, as MapQuest did? Sure, but the whole trend of corporations making random political statements cuts both ways: If you're happy with them making statements you agree with, you have to at least accept when they make statements you find offensive. All these political statements have led to ever more polarization, with calls for boycotts from both sides. This does none of us any good. And, BTW, the battles between Disney and the state of Florida - and specifically with its governor - looked great at first - when Disney was winning - but ended up costing Disney. Was it worth it? Many companies are looking at the costs and saying no, it's not a war we want to fight. > So far, MaqQuest has not folded, but it remains to be seen how long Google and Apple will deign to allow MapQuest to remain available in their app stores. > My prediction: Indefinitely. Not everything is about politics. > What can we do, when governments -- the traditional makers of "official" maps -- can no longer be trusted to provide accurate information ? > There's exactly one thing we can do: Throw the bastards out. This is one of government's jobs, and has been for a very long time. If there is going to be some kind of digital signing or other guarantee of authenticity, then it will of course be the government who will sign to say "yes, this is the official map." If you want an *un*official map - no one stops you from making one. There are tons of local place names that have no official existence but are widely used by those living in an area. That doesn't seem to bother anyone. (The Post Office will generally deliver mail using the unofficial names - the local postal workers know them as well as anyone else - but if you use their database to "normalize" an address, you'll get the official name.) -- Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: From adelyngutierrez9b1987 at tuta.io Thu Sep 10 05:45:52 2026 From: adelyngutierrez9b1987 at tuta.io (adelyngutierrez9b1987 at tuta.io) Date: Thu, 10 Sep 2026 11:45:52 +0200 (CEST) Subject: [Cryptography] Zcash's privacy by default with DAG architecture Message-ID: ZKas is a one month old cryptocurrency that combines Kaspa's GHOSTDAG BlockDAG - fast, parallel, proof-of-work block production with Zcash's Orchard shielded protocol, so that every amount, sender, and recipient is hidden by construction. Zcash's privacy is considered to be the most advanced but it's not enabled by default, so receives criticism from people (e.g. Edward Snowden). Kaspa's DAG?achievements enable it to produce 100 blocks per second but it's a transparent ledger.? ZKas combines Kaspa's and Zcash's work and creates the fastest privacy network with 1 second block time and mandatory hardest encryption. ZKas combines Orchard's confidentiality with a GHOSTDAG BlockDAG. This is workable because an Orchard transaction is self-contained: it balances its own value through homomorphic Pedersen commitments of the form cv = [v]G + [rcv]H (G, H generators on Pallas) and proves its own validity in zero knowledge, independent of the order of other transactions. Only two structures are globally order-sensitive: the set of spent-note nullifiers N and the Merkle tree of note commitments T. A BlockDAG already linearizes its accepted transactions, and ZKas advances N and T along that existing order. Confidentiality therefore adds little latency, and the problem that usually makes a private chain hard ? keeping global state consistent under parallel block production ? reduces to reusing an ordering the engine already computes. The privacy layer is Orchard, Zcash's third-generation shielded protocol, reused through the audited orchard crate rather than re-implemented. Orchard's Action (a merged spend-and-output) uses Pedersen value commitments (homomorphic, so the circuit simply enforces sum vin = sum vout), Sinsemilla note commitments cm = SinsemillaCommit_rcm(g_d || pk_d || v || ? || ?) where g_d is the diversified base, forming a depth-32 Merkle tree, and nullifiers nf = Extract_P([PRF^{nf}_{nk}(?) + ?] ? G + cm). These are adopted as-is. Critically, Orchard has no interstitial treestates: transactions within a block do not chain tree state to one another, which is what makes the three-tier construction of ?6 possible. Statements are proven in Halo 2 over the Pallas/Vesta (Pasta) curve cycle. Halo 2 needs no trusted setup ? a decisive property for a coin with no trusted-setup ceremony and no privileged parties ? because its polynomial commitments are inner-product arguments (transparent, discrete-log based). The IPA also supports efficient batch verification of many proofs at once and recursive composition, the two levers ZKas uses to make shielded verification scale. Only two structures must be globally consistent. The nullifier set N holds every nullifier ever spent; it is append-only and checkable forever, so a repeat is a double-spend. The note-commitment tree T is a fixed depth-32 Sinsemilla Merkle tree of all note commitments (2^{32} leaves), and its root is the anchor. Everything else in a shielded transaction is self-contained: each transaction balances its own value locally via the Pedersen homomorphism, and Orchard's absence of interstitial treestates means transactions in a block do not chain tree state to each other. Hence the only ordering that matters is at the level of these two structures. Shielded state on a DAG ? the core construction This is the one component of ZKas that is genuinely new. The note-commitment tree is built in three layers so that the only serialized step is as small as possible. The bundle subtree is built entirely by the wallet from a single transaction's new commitments (a small Sinsemilla Merkle tree over the Action outputs), with no consensus involvement and complete order-independence. The chain-block subtree is accumulated when a block is processed from the bundle contributions it carries (another Sinsemilla Merkle of those bundle roots); parallel blocks build their own subtrees with zero contention. The global tree is advanced only inside the virtual processor by appending finalized chain-block subtree roots in GHOSTDAG accepted order, yielding the single global root rt = MerkleSinsemilla(rtblock1, rtblock2, ?). This is the single serialized operation, and the engine already produces that exact order. Zcash's early pools (Sprout, Sapling) needed a trusted setup ceremony in which a group generated secret randomness to build the proving parameters and then destroyed it, because anyone who kept that toxic waste could counterfeit coins undetectably. ZKAS has no ceremony and no trusted setup at all. It uses Orchard/Halo 2 (Zcash's own post-2022 system), whose parameters are derived from public, reproducible formulas (Pasta curve constants and the IPA generators). There is no secret that ever exists, so there is nothing to leak and nothing to trust. It shares the same privacy lineage as Zcash but is built entirely on the setup-free generation, so the counterfeiting risk that the ceremony existed to mitigate simply does not apply. Enthusiasts and developers are welcomed. https://zkas.info/whitepaper.html https://zkas.info/https://github.com/firecash/zkas-rusty https://discord.com/invite/jysMS4XNFT -------------- next part -------------- An HTML attachment was scrubbed... URL: From overdrevetfedmetodologi at pm.me Sat Sep 12 04:09:33 2026 From: overdrevetfedmetodologi at pm.me (Viktor S. Kristensen) Date: Sat, 12 Sep 2026 08:09:33 +0000 Subject: [Cryptography] Zcash's privacy by default with DAG architecture In-Reply-To: References: Message-ID: <7ts_qwoYHXnQQmVXV7DIve-1f_ZBRUefjNQsnUTpXqUHToRnFCWna4rvJe06HrrECVq-KzpLlE4EpTCnDD45JXwfUQQp0pkXm98L-PiiYHw=@pm.me> Interesting design ? reusing the orchard crate as-is and only serializing the two order-sensitive structures is the right cut. One question on the construction. Anchors are Merkle roots of the global tree, and the global tree is appended in GHOSTDAG accepted order. If a chain-block subtree root gets reordered (a block moves within?the blue set before it is final), every leaf position after it shifts, so a spend proof built against an anchor that included that block no longer opens. How far behind the tip does an anchor have to be?for its path to be stable, and does that distance eat the 1-second latency? (I hit the same thing on my own chain ? nullifiers that bind to an in-tree position force you to scope the spent set per epoch.) The other thing I would think about early is a cryptographically relevant quantum computer, because a privacy chain is the harvest-now-decrypt-later target par excellence: the whole ledger is public?ciphertext by design. Under Shor, three parts of Orchard go at once ? the note encryption (ECDH on Pallas, so every past transaction gets decrypted retroactively), RedPallas spend authorization (theft),?and the IPA commitment in Halo 2 (discrete-log binding, so forged proofs = undetectable inflation). Pedersen hiding is information-theoretic, so amounts stay hidden, but binding does not. It is a little?ironic that the trusted-setup toxic waste your whitepaper is proud to have removed gets replaced by a discrete-log assumption with a known quantum break. I went the other way on https://sigilgraph.org ? shielded notes whose spend proofs are hash-based STARKs (transparent, no curve, no pairing), so at least the proof system has no known quantum attack; the?rest of the stack is being moved the same way. Whether full-scale machines are five years away or always five years away (the New Scientist piece:?https://www.newscientist.com/article/2582565-why-full-fledged-quantum-computers-might-always-be-five-years-away/) matters less for a privacy coin than for a payment coin, because the recorded ciphertext?waits. Unrelated plug, since your repo is Rust: if compile times hurt, https://fluxapp.xyz is a Rust build platform I built and dogfood; SIGIL is compiled with it. ? -- Viktor Really important if something matters Afsendt med Proton Mail sikker e-mail. fredag den 11. september 2026 kl. 20:56, skrev zikky via cryptography : > ZKas is a one month old cryptocurrency that combines Kaspa's GHOSTDAG BlockDAG - fast, parallel, proof-of-work block production with Zcash's Orchard shielded protocol, so that every amount, sender, and recipient is hidden by construction. > > Zcash's privacy is considered to be the most advanced but it's not enabled by default, so receives criticism from people (e.g. Edward Snowden). > Kaspa's DAG?achievements enable it to produce 100 blocks per second but it's a transparent ledger.? > > ZKas combines Kaspa's and Zcash's work and creates the fastest privacy network with 1 second block time and mandatory hardest encryption. > > ZKas combines Orchard's confidentiality with a GHOSTDAG BlockDAG. This is workable because an Orchard transaction is self-contained: it balances its own value through homomorphic Pedersen commitments of the form cv = [v]G + [rcv]H (G, H generators on Pallas) and proves its own validity in zero knowledge, independent of the order of other transactions. Only two structures are globally order-sensitive: the set of spent-note nullifiers N and the Merkle tree of note commitments T. A BlockDAG already linearizes its accepted transactions, and ZKas advances N and T along that existing order. Confidentiality therefore adds little latency, and the problem that usually makes a private chain hard ? keeping global state consistent under parallel block production ? reduces to reusing an ordering the engine already computes. > > The privacy layer is Orchard, Zcash's third-generation shielded protocol, reused through the audited orchard crate rather than re-implemented. Orchard's Action (a merged spend-and-output) uses Pedersen value commitments (homomorphic, so the circuit simply enforces sum vin = sum vout), Sinsemilla note commitments cm = SinsemillaCommit_rcm(g_d || pk_d || v || ? || ?) where g_d is the diversified base, forming a depth-32 Merkle tree, and nullifiers nf = Extract_P([PRF^{nf}_{nk}(?) + ?] ? G + cm). These are adopted as-is. Critically, Orchard has no interstitial treestates: transactions within a block do not chain tree state to one another, which is what makes the three-tier construction of ?6 possible. > > Statements are proven in Halo 2 over the Pallas/Vesta (Pasta) curve cycle. Halo 2 needs no trusted setup ? a decisive property for a coin with no trusted-setup ceremony and no privileged parties ? because its polynomial commitments are inner-product arguments (transparent, discrete-log based). The IPA also supports efficient batch verification of many proofs at once and recursive composition, the two levers ZKas uses to make shielded verification scale. > > Only two structures must be globally consistent. The nullifier set N holds every nullifier ever spent; it is append-only and checkable forever, so a repeat is a double-spend. The note-commitment tree T is a fixed depth-32 Sinsemilla Merkle tree of all note commitments (2^{32} leaves), and its root is the anchor. Everything else in a shielded transaction is self-contained: each transaction balances its own value locally via the Pedersen homomorphism, and Orchard's absence of interstitial treestates means transactions in a block do not chain tree state to each other. Hence the only ordering that matters is at the level of these two structures. > > Shielded state on a DAG ? the core construction > > This is the one component of ZKas that is genuinely new. > > The note-commitment tree is built in three layers so that the only serialized step is as small as possible. The bundle subtree is built entirely by the wallet from a single transaction's new commitments (a small Sinsemilla Merkle tree over the Action outputs), with no consensus involvement and complete order-independence. The chain-block subtree is accumulated when a block is processed from the bundle contributions it carries (another Sinsemilla Merkle of those bundle roots); parallel blocks build their own subtrees with zero contention. The global tree is advanced only inside the virtual processor by appending finalized chain-block subtree roots in GHOSTDAG accepted order, yielding the single global root rt = MerkleSinsemilla(rtblock1, rtblock2, ?). This is the single serialized operation, and the engine already produces that exact order. > > Zcash's early pools (Sprout, Sapling) needed a trusted setup ceremony in which a group generated secret randomness to build the proving parameters and then destroyed it, because anyone who kept that toxic waste could counterfeit coins undetectably. ZKAS has no ceremony and no trusted setup at all. It uses Orchard/Halo 2 (Zcash's own post-2022 system), whose parameters are derived from public, reproducible formulas (Pasta curve constants and the IPA generators). There is no secret that ever exists, so there is nothing to leak and nothing to trust. It shares the same privacy lineage as Zcash but is built entirely on the setup-free generation, so the counterfeiting risk that the ceremony existed to mitigate simply does not apply. > > > Enthusiasts and developers are welcomed. > > https://zkas.info/whitepaper.html > https://zkas.info/ > https://github.com/firecash/zkas-rusty > https://discord.com/invite/jysMS4XNFT -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - overdrevetfedmetodologi at pm.me - 0x5F4716BA.asc Type: application/pgp-keys Size: 1722 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 603 bytes Desc: OpenPGP digital signature URL: From natusor at tutamail.com Mon Sep 14 04:25:43 2026 From: natusor at tutamail.com (natusor at tutamail.com) Date: Mon, 14 Sep 2026 10:25:43 +0200 (CEST) Subject: [Cryptography] Spending needs a leaf from a local entropy file. Not just the key Message-ID: I have built a proof-of-work chain and ended up with a spend authorisation scheme I cannot place in the literature so I would be grateful for pointing to papers that I should be start reading. The rest of the chain is ordinary Proof of work unspent output model, Merkle trees, difficulty retargeting every 2016 blocks. I put just? together what I found like Lego so the main new part is the shield that protects coins from spending by anyone who does not have a noise file created for the wallet. I wanted anyone with an ordinary laptop to keep the full history of the chain but SSD prices keep going up and in 2026 drives above two terabytes are still not standard in home computers. Heavy system requirements would mean that hardware capable of running it stops being affordable for most people. So I built it to run even on old computers because then if it runs on old hardware then it will be run as well? i hope so in future on much better newer ones and I wanted something light that will not clog the network. So every wallet holds a local file of entropy gathered from physical measurements on the machine that created it from electron movement, semiconductor vibrations, temperature changes. Then that file is cut into slices called leaves and the chain stores nothing but the Merkle root of that file. To spend an input must be revealed one leaf together with a proof binding it to that exact transaction. Such a leaf is never used again and the signature on its own cannot authorise anything. Good thing is that so any future improvement to entropy collection can be introduced without changing the consensus rules because chain does not check where the noise came from. Private users and institutions alike can build their own modules collecting entropy from sources such as sandstorms, radar data or anything else. That could create a market for external devices supplying entropy and everyone could pick a source that? they like it most.? About one year ago I built it on WOTS one-time signatures and that worked but the proof sizes were unsustainable and when I tested that version I do not remember exactly but? I think it was around 1750 bytes against 64 bytes for Ed25519 and with a large number of confirmations a wave built up that clogged the blocks. To fit it was needed much larger blocks but then an ordinary user cannot keep a full node on their disk and has to prune the history. In such a construction the whole history would live only on government or corporate servers because only they can afford that. With small blocks there was a risk that nodes would be busy with confirmations alone and users would not get new transactions through. WOTS is a good solution just not in this place so I simplified it down to an entropy file cut into leaves. My approach was inspired by the fragments I found about Russian stream communication systems from? soviet union era. I know this might be controversial but their approach back then was based on simplicity and effectiveness. Theirs always rested on the greatest possible simplicity and that convinced me. By the way I am not a professional cryptographer so I spent two years on successive versions of this. But If? an attacker who recovers the private key still is not able to moves coins? and that includes an attacker with a quantum computer even though the Ed25519 signatures themselves would not survive Shor then i like it.?I really want to point out here that this is not a one-time pad and I do not claim it is. The only thing that ties it to the OTP is the creation of the entropy file from sources that cannot produce the same results twice. Such a material is used for authorisation rather than encryption and it is bound to a commitment published on the chain. There is one scenario I worry about. If Alice sends a transaction to Bob. Then attacker who has already managed to compute her private key sees that transaction and he copies the leaf out of it and pushes his own transaction with a higher fee using that same leaf. I assume this does not work because the leaf proof is verified against the hash of the transaction it sits in. The attacker's transaction has different outputs so a different hash and verification should fail and leaf spent once cannot be used again. But that is my assumption not the result of independent analysis or of testing on the live network. The same question applies to WOTS. I also do not know how long a quantum computer would need to compute a private key. I assume thirty minutes but that is just a guesswork. Questions I cannot answer myself is:Does this construction have a name? It feels close to a commitment to a set of one-time authenticators but I have not found it described that way. Has anyone analysed its weak points? The obvious ones are not entropy quality because If the entropy is derived from sources with unpredictable behavior it should be high-quality entropy. However the only issue I see for now is the risk of the noise file being stolen.? That? risk that can be mitigated by storing the file on external media and using it only when performing a transaction. This could enable a multi party authentication system where one person holds the noise file, another has the password for that file, and a third holds the private keys. In this way none of these individuals could transfer the funds on their own. As well the implementation refuses to create entropy file when the timing measurements do not vary enough. On an Android phone under a compatibility layer on UserLand? it found six distinct values in 256 samples and refused. I would welcome any opinions on whether host timing noise is a defensible source for something carrying this much weight. The code is public under the MIT licence if anyone wants to look at the construction itself. https://github.com/natusor/MONEU/blob/main/MONEU-White-Paper_EN.md natusor -------------- next part -------------- An HTML attachment was scrubbed... URL: From adelyngutierrez9b1987 at tuta.io Tue Sep 15 04:15:08 2026 From: adelyngutierrez9b1987 at tuta.io (adelyngutierrez9b1987 at tuta.io) Date: Tue, 15 Sep 2026 10:15:08 +0200 (CEST) Subject: [Cryptography] Zcash's privacy by default with DAG architecture Message-ID: Thanks for the notes. Both points are real. On the GHOSTDAG reordering: ZKas already solves it exactly like that. Spends never anchor to the tip. The anchor has to be matured, age at least shielded_anchor_depth (about 10 min, 600 BPS) and no older than max_shielded_anchor_age (around 7.5 hours). Confirmation stays 1 second, the spend lands at the tip. The delay is only on re-spending a fresh note, same as coinbase maturity. It is shorter than full finality on purpose. Resolution comes from all producer blocks of that root, not last-write-wins, and it fails closed. Bad or expired anchors just drop the spend, never inflate. On quantum and HNDL: you are right. ZKas inherits Orchard ECDH note encryption (the HNDL risk), RedPallas, and Halo2 IPA. No PQ mitigation yet, same as Zcash and every other Sapling/Orchard chain. STARKs only fix the proof binding. They do nothing for harvest-now-decrypt-later of the notes themselves. That needs a PQ KEM. Spend-auth theft needs PQ signatures. Full PQ for a privacy coin is three separate swaps. Your proof system is a good start on one of them, not the whole thing. The trusted-setup vs quantum framing is different kinds of risk. One is present, the other is future and shared by the whole field. Appreciate the right questions. -------------- next part -------------- An HTML attachment was scrubbed... URL: