From phma at bezitopo.org Fri Jul 11 19:22:20 2025 From: phma at bezitopo.org (Pierre Abbat) Date: Fri, 11 Jul 2025 19:22:20 -0400 Subject: [Cryptography] Uses for novel or unusual kinds of cryptographic primitives Message-ID: <5602035.Lt9SDvczpP@puma> A friend of mine is trying to get me a grant for some ideas I have, including two ciphers and a hash function. They are a whole-message cipher, a keyed hash, and a self-synchronizing byte stream cipher. I'd like to include possible uses in the grant application. A whole-message cipher is like a block cipher, except that the block can be arbitrarily long. The one I've invented is Wring, which I've mentioned here before. Wring is an iterated product cipher with four steps, but one could make a whole-message Feistel cipher with a 4?4 S-box for the odd nybble, or other kinds. If you encrypt a 1 MB message with a 16 byte block cipher in CBC mode, every bit of plaintext influences every block of ciphertext from there on, but the last byte of plaintext has no influence on the first byte of ciphertext. In a whole-message cipher, every byte of ciphertext depends on every byte of plaintext. It can be used as an all-or-nothing transform. What are some other uses of whole-message ciphers (besides, of course, encrypting)? Twistree, which I've also mentioned here, is a keyed hash function. It's not a construction in which the key is concatenated with the message and then they're hashed together; rather, the key determines the S-boxes used in the compression function. Is there any protocol in which keying like this is important? I've also invented a self-synchronizing byte stream cipher named Daphne. Most stream ciphers I've heard of, including pre-computer ones like Enigma, are synchronous ciphers: if a byte or letter gets corrupted in transmission, that byte or letter, and no other, will be corrupt on decrypting, and if a byte or letter is lost, the decryption produces garbage from then on. In a self- synchronizing cipher, a byte or letter being corrupted or dropped from ciphertext results in several or many bytes or letters being corrupted in the plaintext, then the cipher recovers and produces correct plaintext. When would this property be important? Pierre -- .i toljundi do .ibabo mi'afra tu'a do .ibabo damba do .ibabo do jinga .icu'u la ma'atman. From bear at sonic.net Mon Jul 14 13:08:44 2025 From: bear at sonic.net (Ray Dillinger) Date: Mon, 14 Jul 2025 10:08:44 -0700 Subject: [Cryptography] Attacks on Fiat-Shamir transformation (Pseudorandom Oracles based on Hash Functions) Message-ID: <4e445207-a2c4-40bf-88f7-941e4d4ed1a3@sonic.net> Are people aware of this paper? It came out in January but I hadn't heard of it yet. https://eprint.iacr.org/2025/118 Researchers at the Ethereum Foundation have formulated an attack on "Random Oracles" formulated as hash functions on nonrandom data. This is applicable to the specific case where such a Pseudorandom Oracle is used for the randomness needed to construct cryptographic proofs-of-knowledge. The attack allows the construction of non-interactive solutions to such proofs-of-knowledge, meaning essentially that someone can "prove they know" something which they do not in fact know. I haven't done the math in detail but I don't see anything that would indicate it's a non-feasible attack given the capabilities of an ordinary desktop computer.? It could still turn out to be a false alarm if the authors are wrong.? The authors call it a "practical attack" but acknowledge that as far as they know, no protocols in widespread use depend on this particular construction. This could break a couple of block chain designs I've heard of but I don't know whether those designs were implemented nor which are affected if they were. It definitely does not affect Bitcoin or Ethereum.? It affects a capability that someone was considering adding to Ethereum, but which had not been deployed. Any block chains enabling transactions that rely on this construction are either dead in the water, or if they still exist urgently need redesign. But it looks like nothing else breaks right now (or broke in January) even if the authors are right about the attack. It would become the latest example of constructions formerly thought secure, which pros have to look out for.? In-house and homebrew crypto implementors basing their work on everything published before this attack became widely known, will be very confidently getting it wrong for the next decade at least. Meanwhile attention must be paid to making sure that the authors are right. If they are right, then attention must be paid to putting warnings about it into the next generation of textbooks, updating the errata for current textbooks, combing the archives for papers that must be rebutted or retracted, updating widely available crypto tools and libraries to specifically detect and/or prevent this use of the Fiat-Shamir, and trying to find ways to extend the attack or apply it in different domains (and thus finding other constructions that must be warned against, rebutted, or retracted). Whatever else is good, bad, or ugly about block chain protocols, they have spurred a surprising amount of research and practical experience with things that were up to now fairly esoteric and theoretical cryptographic constructions. Bear --- "Well, that's the problem, isn't it?" Burroughs said. "You've got your toves out of control all over the place, and when you go ask the Borogroves for some help, you find that they've gone all mimsy on you. Seems to happen at about this time every year." From bear at sonic.net Mon Jul 14 15:22:41 2025 From: bear at sonic.net (Ray Dillinger) Date: Mon, 14 Jul 2025 12:22:41 -0700 Subject: [Cryptography] Uses for novel or unusual kinds of cryptographic primitives In-Reply-To: <5602035.Lt9SDvczpP@puma> References: <5602035.Lt9SDvczpP@puma> Message-ID: <939de991-11e6-4a84-a06b-15d7a2e75bdc@sonic.net> On 7/11/25 16:22, Pierre Abbat wrote: > A friend of mine is trying to get me a grant for some ideas I have, including > two ciphers and a hash function. They are a whole-message cipher, a keyed > hash, and a self-synchronizing byte stream cipher. I'd like to include > possible uses in the grant application. > > A whole-message cipher is like a block cipher, except that the block can be > arbitrarily long. First, you should know: grants are almost never awarded for proposed ciphers, hashes, or cryptographic protocols. Nothing you or I come up with will see any significant use or generate any significant value anywhere until somebody well-known with lots of cryptographic experience and prior successes in cracking things, spends a good long time trying hard to crack it and comes up with no feasible attacks. These professionals are unlikely to examine a proposal coming from a relatively unknown source. Such people are rare and the number of proposed ciphers and hashes per year is more than a hundred times the number they could reasonably investigate. They concentrate their efforts mostly on things already in use, things developed by well-known people with established history of developing secure things, or proposals which have already been examined by other professionals and are now getting more attention because some standards committee somewhere is considering adopting them. Honestly your best bet of getting your proposals a reasonably serious evaluation is to find a university professor who is teaching a cryptanalysis class. It is reasonable for such an instructor to give his students a dozen proposals of unknown quality and award credit to students for developing attacks on them. That said, cryptanalysis courses and professors teaching them? are also quite rare, and most are taught without such a "practicum" project. Second, constructing a _secure_ cipher is not too hard once basic principles like the Feistel construction and nonlinearity are understood. But it requires deep art to construct a secure cipher which is also competitive in compute power, memory requirements, flexibility, and speed. You need to evaluate your proposed ciphers and hashes and do the easy work of comparing their merits on those other requirements. Demonstrate that at least in some combination of requirements, they are equal or superior, before attempting to occupy anyone's time and effort in determining the much harder question of whether they provide comparable security. Third, I think most cryptographers implement a whole-message cipher at some point. I certainly did, as an exercise.? But the general consensus is that conventional (block) ciphers are secure in practice, cheaper in compute power (particularly memory and the burden of handling memory securely), and more flexible in application because they can be used in a pipeline or as a filter allowing decryption of blocks as they are received instead of delaying decryption until the whole message is complete and its length is known. And it's easy to use an existing block cipher as a whole-message cipher if needed; simply encrypt using CBC mode, take the mode state remaining after the last block, and use it as the initialization vector (starting CBC state) to re-encrypt the ciphertext from the start. Easy or not, this "cipher doubling mode" is not used in practice, mostly due to the above practical concerns. It is at least double the CPU requirement and imposes an additional memory requirement the size of the whole message. But if someone determines that they need a whole-message cipher, for any reason, they will most likely use this cipher-doubling mode. So its burdens in memory cost, compute power, etc, should be your baseline for comparison when you're determining whether, even in the very obscure case where someone wants a whole-message cipher, your proposal is potentially superior to an off-the-shelf solution and therefore worth someone's effort to actually evaluate its security. > I've also invented a self-synchronizing byte stream cipher named Daphne. Most > stream ciphers I've heard of, including pre-computer ones like Enigma, are > synchronous ciphers: if a byte or letter gets corrupted in transmission, that > byte or letter, and no other, will be corrupt on decrypting, and if a byte or > letter is lost, the decryption produces garbage from then on. First your characterization of stream ciphers is incorrect, or uses a technical term incorrectly.? One *garbled* character does not affect the rest of the message; it simply results in one garbled character of output.? One *missing* character would affect the rest of the message because after missing a character the sender and receiver are at different points in the keystream. Second, you're describing a well-known property of Synchronous Stream Ciphers.? That property is why Self-Synchronizing stream ciphers have already been invented. See https://en.wikipedia.org/wiki/Stream_cipher for relevant discussion. Third, if you examine the existing solution provided in that encyclopedia article, you'll see that this is essentially the use of the CFB block cipher mode, applied to a block cipher whose "block" is one character long.? A missing character in a self-synchronizing stream cipher results in two garbled characters at output. Bear --- "The time has come, the walrus said, to speak of many things: of shoes and ships and sealing wax, and cabbages and kings.? And why the sea is boiling hot, and whether pigs have wings." -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.gjosteen at ntnu.no Wed Jul 16 06:36:05 2025 From: kristian.gjosteen at ntnu.no (=?utf-8?B?S3Jpc3RpYW4gR2rDuHN0ZWVu?=) Date: Wed, 16 Jul 2025 10:36:05 +0000 Subject: [Cryptography] Attacks on Fiat-Shamir transformation (Pseudorandom Oracles based on Hash Functions) In-Reply-To: <4e445207-a2c4-40bf-88f7-941e4d4ed1a3@sonic.net> References: <4e445207-a2c4-40bf-88f7-941e4d4ed1a3@sonic.net> Message-ID: 14. juli 2025 kl. 19:08 skrev Ray Dillinger : > Are people aware of this paper? It came out in January but I hadn't heard of it yet. > > https://eprint.iacr.org/2025/118 > > Researchers at the Ethereum Foundation have formulated an attack on "Random Oracles" formulated as hash functions on nonrandom data. This is applicable to the specific case where such a Pseudorandom Oracle is used for the randomness needed to construct cryptographic proofs-of-knowledge. > > The attack allows the construction of non-interactive solutions to such proofs-of-knowledge, meaning essentially that someone can "prove they know" something which they do not in fact know. I have had a brief look at the paper. I expect it to be correct. I think it is nice. It has made me think a bit. That?s nice, too. Unfortunately, results of this kind - on the soundness of the random oracle heuristic - are hard to interpret. One possible interpretation is that as long as the circuits used are chosen independently from the hash functions used for Fiat-Shamir, everything should be ok-ish. I am not entirely sure about this interpretation. That said, I do not think this breaks everything. It may not break anything currently in use. But I could be wrong about that. And how do you know that the circuits used in practice are chosen independently from the hash functions? Well, fortunately everyone in the relevant user space is a domain expert: nobody is messing with black magic they don?t understand. Also, the relevant user space is well-known for honesty and moral uprightness: no crooks anywhere to be found. Anyway, I like the paper. I think the authors did great work here. By the way, the paper has been accepted for Crypto 2025, which is no big surprise. PS. The paper has no bearing on ?traditional? applications of Fiat-Shamir. It does not affect anything I have ever worked on. -- Kristian Gj?steen From cryptography at mdpi.com Wed Jul 16 22:58:31 2025 From: cryptography at mdpi.com (cryptography) Date: Thu, 17 Jul 2025 10:58:31 +0800 Subject: [Cryptography] Advances in Privacy, Security, and Trust: Cryptographic Perspectives from PST2025 - Call for Paper In-Reply-To: <3e8445e5-ba38-7cc8-38f3-9c917e4c13b5@mdpi.com> References: <3e8445e5-ba38-7cc8-38f3-9c917e4c13b5@mdpi.com> Message-ID: The Special Issue "Advances in Privacy, Security, and Trust: Cryptographic Perspectives from PST2025" of journal /Cryptography/ (https://www.mdpi.com/journal/Cryptography) will comprise mainly extended versions of papers presented at the 22nd Annual International Conference on Privacy, Security, and Trust (PST2025, 26-28 August 2025, Fredericton, Canada). https://pstnet.ca/pst2025/ The submission deadline of special issue is 31 December 2025 and papers may be submitted immediately or at any point till the date, as papers will be published on an ongoing basis. For more information, please see: https://www.mdpi.com/journal/cryptography/special_issues/M81T8HF4DD Specific topics of interest include, but are not limited to: Privacy Preserving/Enhancing Technologies; Critical Infrastructure Protection; Network and Wireless Security; Cloud Security, Web Security and Privacy; Internet of Things (IoT) Security and Privacy; Security Analytics and Data Mining; Cryptographic Technologies; Zero-Day Vulnerabilities, Continuous Authentication; Security and Privacy Challenges in Blockchain; Identity and Trust Management; Privacy, Traceability, and Anonymity; Anonymity and Privacy vs. Accountability; Access Control and Capability Delegation; Generative AI security, privacy, and trust; Quantum Key Distribution (QKD) Protocols; Post-quantum cryptography Guest editors: Prof. Dr. Rongxing Lu Prof. Dr. Ali Ghorbani Cryptography is a scientific peer-reviewed open access journal of cryptography published quarterly online by MDPI. It is covered by Scopus (Elsevier), Emerging Sources Citation Index (ESCI-Web of Science), etc. It received an Impact Factor for 2024 of 2.1 (ranking in Q2 in "Computer Science, Theory & Methods"), and a CiteScore of 5.0 (ranking in Q1 in "Applied Mathematics"). 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 Recommended Papers: Divisions and Square Roots with Tight Error Analysis from Newton-Raphson Iteration in Secure Fixed-Point Arithmetic https://www.mdpi.com/2410-387X/7/3/43 Matrix Encryption Walks for Lightweight Cryptography https://www.mdpi.com/2410-387X/7/3/41 Twitter: @Cryptogr_MDPI https://twitter.com/Cryptogr_MDPI LinkedIn: Cryptography-MDPI From rmverma2 at Central.UH.EDU Sat Jul 19 12:43:55 2025 From: rmverma2 at Central.UH.EDU (Verma, Rakesh M) Date: Sat, 19 Jul 2025 16:43:55 +0000 Subject: [Cryptography] Updated CFP for ICISS 2025 Message-ID: Hi, My apologies for the mistake, the submission deadline has been extended to July 25, 2025. Please share the updated CFP instead of the previous one. Thanks, Rakesh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: iciss2025.txt URL: From H3Xcberus0X at proton.me Mon Jul 21 11:00:52 2025 From: H3Xcberus0X at proton.me (H3Xcberus0X at proton.me) Date: Mon, 21 Jul 2025 15:00:52 +0000 Subject: [Cryptography] =?utf-8?q?=5BWhitepaper=5D_ShadowNet_=E2=80=93_De?= =?utf-8?q?centralized_AI-Powered_Privacy_Network?= Message-ID: <8noJvZ7hcdv5yQTjRHZf5WRuQTg_nUnQW35GuHPyuBSCdUrzAvocqX0invxAQ_6yTomqy0xFzaL5zv7MdWUyPLI0iHBBBB0tce3Xj3sDkgM=@proton.me> Dear cryptography community, I?m excited to share with you the whitepaper for a new decentralized privacy project called ShadowNet. ShadowNet is a distributed AI-powered network designed to provide total anonymity, secure communication, and blockchain-based routing through advanced cryptographic protocols. It introduces: - PhantomNet (a decentralized overlay mesh) - Cerberus AI Core (locally-run traffic mimicry engine) - ECC-based identity encryption - S-Token (a bandwidth incentive crypto) - Obfuscation Nodes to disrupt traffic analysis This project is an open call for freedom in the digital age. Your feedback, critiques, and thoughts are highly appreciated. ? Whitepaper (PDF on GitHub): https://github.com/H3Xcuberus0X/ShadowNet-Whitepaper/blob/main/ShadowNet_Whitepaper.pdf Looking forward to your thoughts and engagement. Sincerely, H3X From yuvraj467229 at proton.me Wed Jul 23 02:49:35 2025 From: yuvraj467229 at proton.me (yuvraj) Date: Wed, 23 Jul 2025 06:49:35 +0000 Subject: [Cryptography] [Prototype Paper] A Peer-to-Peer Cloud Gaming System Message-ID: Dear Cryptography Community, I am excited to share a research prototype that explores a new application of decentralized consensus mechanisms, this time not for finance ? but for gaming. **"A Peer-to-Peer Cloud Gaming System Using Distributed CPU Sharing and Token-Based Incentives"** In this paper, I propose a way for gamers to run games through distributed computing power donated by others in the network, incentivized through tokens. The architecture draws heavily from blockchain concepts such as Proof-of-Work, Timestamping, and Decentralized Incentives ? but adapts them to suit cloud gaming's real-time and latency-critical requirements. This system is currently in **prototype phase**, and your insights, feedback, and critique would be deeply appreciated. I believe, with community involvement, this can grow into something impactful ? maybe even as disruptive as Bitcoin. Thank you all for your time and your legacy. Warm regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Peer_to_Peer_Cloud_Gaming_System.pdf Type: application/pdf Size: 15054 bytes Desc: not available URL: