[Cryptography] Uses for novel or unusual kinds of cryptographic primitives

[Ray Dillinger]

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: <https://www.metzdowd.com/pipermail/cryptography/attachments/20250714/f72af028/attachment.htm>