Prev: Using an Asymmetric cipher the opposite way round.
Next: Note on general application of Feistel's technique
From: Fiziwig on 20 Jul 2010 13:22
Just for the fun of it (I'm retired with nothing better to do with my
time :) I've created a new code (not cipher) based on a variation of
Huffman coding but using the Roman alphabet instead of binary bits to
encode English words instead of bytes of data. The code words are
variable length, but self-segregating so decoding is unambiguous in
all cases.

Encoded, the average is 2.35 Roman letters per English word, or about
half the size of the same message in English plaintext.

Complete description and downloadable 10,000 word code book at
http://fiziwig.com/crypto/huffcode.html

And remember, this is just for fun. Although with a software coder/
decoder it could be a semi-practical way to encrypt emails to friends.
Especially if an optional keyword-based enciphering layer were used.

--gary
From: Paulo Marques on 20 Jul 2010 13:47

Hi,

Fiziwig wrote:
> Just for the fun of it (I'm retired with nothing better to do with my
> time :) I've created a new code (not cipher) based on a variation of
> Huffman coding but using the Roman alphabet instead of binary bits to
> encode English words instead of bytes of data. The code words are
> variable length, but self-segregating so decoding is unambiguous in
> all cases.
>
> Encoded, the average is 2.35 Roman letters per English word, or about
> half the size of the same message in English plaintext.
>
> Complete description and downloadable 10,000 word code book at
> http://fiziwig.com/crypto/huffcode.html

This seems like a cute project, but I don't understand why you didn't
use a standard huffman code to build the tables instead of using ad-hoc
rules. There are even projects available for building n-ary huffman trees:

http://sourceforge.net/projects/huffman-ta/

This will certainly decrease the average word size, since huffman is
optimal for discrete encodings with known frequencies.

(I'm sorry if I'm raining on your parade, though :( )

> And remember, this is just for fun. Although with a software coder/
> decoder it could be a semi-practical way to encrypt emails to friends.
> Especially if an optional keyword-based enciphering layer were used.

Don't even think about going there! :)

This group takes cryptography seriously and your description just sounds
like an extremely "weak" cypher...

If you want a practical way to encrypt/decrypt emails to/from friends,
just take a look at gpg.

--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"This version has many new and good features. Sadly, the good ones are
not new and the new ones are not good."
From: Mok-Kong Shen on 20 Jul 2010 14:06
Fiziwig wrote:

> Encoded, the average is 2.35 Roman letters per English word, or about
> half the size of the same message in English plaintext. [snip]

Question: Would the efficiency be better if a larger alphabet, e.g.
both upper and lower case, be used?

(BTW, a different line of thought is in my post "A scheme of dictionary
coding of English words" of 29.06.2010.)

M. K. Shen
From: Fiziwig on 20 Jul 2010 16:52
On Jul 20, 10:47 am, Paulo Marques <pmarq...(a)grupopie.com> wrote:
> Hi,
>
> Fiziwig wrote:
> > Just for the fun of it (I'm retired with nothing better to do with my
> > time :)
> > Encoded, the average is 2.35 Roman letters per English word, or about
> > half the size of the same message in English plaintext.
>
> This seems like a cute project, but I don't understand why you didn't
> use a standard huffman code to build the tables instead of using ad-hoc
> rules. There are even projects available for building n-ary huffman trees:
>
> http://sourceforge.net/projects/huffman-ta/
>
> This will certainly decrease the average word size, since huffman is
> optimal for discrete encodings with known frequencies.

I wanted to keep it as simple as possible for a human being using a
hard copy code book and pencil and paper. More optimal encodings,
while more efficient, would necessarily be more complex for use by
mere humans. And don't forget, if the empire falls and civilization
crumbles, future feudal lords and kings will once again have to rely
on paper and pencil cryptography. ;-)

> (I'm sorry if I'm raining on your parade, though :( )

No need. This is just for fun, and there's no ego invested in it. I
just wanted to see how far I could go with a modern remake of the old
telegrapher's code book idea.

> This group takes cryptography seriously and your description just sounds
> like an extremely "weak" cypher...

Yes, very weak indeed. But I'm enjoying the project all the same. And
besides, Byrne's "weak" cipher resisted cracking for many decades.
(See my functional equivalent of the Choacipher machine at
http://fiziwig.com/crypto/tile1.html )

> If you want a practical way to encrypt/decrypt emails to/from friends,
> just take a look at gpg.

yes, there are better ways to encrypt email for security, but this is
a pencil and paper system, which appeals to my retro nature.

--gary
From: Fiziwig on 20 Jul 2010 16:57
On Jul 20, 11:06 am, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote:
> Fiziwig wrote:
> > Encoded, the average is 2.35 Roman letters per English word, or about
> > half the size of the same message in English plaintext. [snip]
>
> Question: Would the efficiency be better if a larger alphabet, e.g.
> both upper and lower case, be used?
>
> (BTW, a different line of thought is in my post "A scheme of dictionary
> coding of English words" of 29.06.2010.)
>
> M. K. Shen

I'm sure the compression would be better using upper and lower case,
however, as a paper-and-pencil system there is too much room for
confusion over uppercase and lower case hand-printed letters. In
particular Cc, Kk, Ll, Oo, Pp, Ss, Uu, Vv, Xx, Yy, Zz. Since it is
meant to be a paper-and-pencil system, that would make it too error-
prone.

I looked at your system. Very compact, but again, I prefer to stick to
all upper case Roman letters for hand-written clarity.

--gary
 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Using an Asymmetric cipher the opposite way round.
Next: Note on general application of Feistel's technique