<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 7/11/25 16:22, Pierre Abbat wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:5602035.Lt9SDvczpP@puma">
      <pre wrap="" class="moz-quote-pre">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. </pre>
    </blockquote>
    <p>First, you should know: grants are almost never awarded for
      proposed ciphers, hashes, or cryptographic protocols. </p>
    <p>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. <br>
    </p>
    <p>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. <br>
    </p>
    <p>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.<br>
    </p>
    <p><br>
    </p>
    <p>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. <br>
    </p>
    <p><br>
    </p>
    <p>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.</p>
    <p>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. </p>
    <p>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.<span style="white-space: pre-wrap">
</span></p>
    <blockquote type="cite" cite="mid:5602035.Lt9SDvczpP@puma">
      <pre wrap="" class="moz-quote-pre">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. </pre>
    </blockquote>
    <p>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. <br>
    </p>
    <p>Second, you're describing a well-known property of Synchronous
      Stream Ciphers.  That property is why Self-Synchronizing stream
      ciphers have already been invented. <br>
    </p>
    <p>See <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Stream_cipher">https://en.wikipedia.org/wiki/Stream_cipher</a> for relevant
      discussion. <br>
    </p>
    <p>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. <br>
    </p>
    <p><br>
    </p>
    <p>Bear</p>
    <p>---</p>
    <p>"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."<br>
    </p>
    <p><br>
    </p>
    <br>
  </body>
</html>