A new cipher?

[Jeff L]

First time poster here. I tried reading the FAQs, and to be honest,
nearly everything I read might as well be Greek. I have no background
at all in cryptology and even the most elementary stuff to most of you
is probably beyond me. Having said that: I invented a code many
decades ago when I was a teenager and forgot about it until recently
when I found an example of it. In looking at it I find it hard to
believe anyone could crack it without a computer, and I am curious how
difficult it would be to crack even with one.

It is a very simple code that doesn't rely on a key or whatever it is
that programs use these days. I've searched through the lists of types
of codes and I don't see anything like it, but then again I don't know
what the description would even look like. The other problem is that
apparently the preferred method to see how secure a code is, is to
post an example of the code with a key and a description and then see
if anyone can crack it. I can't do that or it would never be useful
again. There is no key, just a few simple rules. So my simple question
is this- if I post an example of a couple of common phrases or
sentences in my code, is there any chance someone on here would be up
for the challenge of trying to break it both with and without a
computer, just to satisfy my decades long curiosity about whether it
has any merit or not?

110210112013102110220131221132301230110220013122113230123012013201201101201312013201312023201311013012132110212112332213112012121311102012132120231102201311011011102101120131021211232023120132012121311020

Thanks

Jeff

[Klaus Pommerening]

Jeff L invented a cipher:
> ... So my simple question

> is this- if I post an example of a couple of common phrases or
> sentences in my code, is there any chance someone on here would be up

> for the challenge of trying to break it ...

The ultimative answer is here:
http://www.schneier.com/crypto-gram-9810.html#cipherdesign
--
Klaus Pommerening

[Jeff L]

Thanks Klaus- I had seen something similar but I thought maybe
somebody could run it through their program and determine how robust
it was depending on if it took the computers a short amount of time,
or longer. Or, maybe instead of doing a Sudoku puzzle, or some other
hobby for a couple of minutes that they could try this. I'm just
trying to satisfy a youngster's curiosity, and figured someone might
be up for the challenge of seeing if they could crack a 13 year old's
code without a computer.

[xxein]

xxein: I can make it look like this if you want.

DUew*:K\n 1DUew*;K]o!2EVhz->Qcv(9K^n!2BTfv(9L]o#4EXj}/
@Reu(:J[n"2CUev)9J\l}}2CUev+=M^q$6FXk}/@Sdu'8K[l 1DVgx*<M_p#5H[m!2EVgy
+<N_q$7HYjz.>Oar'9J\l 3DUeww+;L_p#3DUev):J\m}0ASct):J\m!2CUhz,>Qbt&7J
\l}1BTex+<L^nn

[xxein]

On May 4, 5:03 am, Klaus Pommerening <pomme...@uni-mainz.de> wrote:

xxein: That website is self-regulatory garbage. Why does a cipher
have to be built from an algorithm?

[David Eather]

So that it can be understood and tested. You might understand how and why
you coded your encryption function a particular way but nobody else will.
To try, they would have to unravel your code bit by bit and then try to
fit it into a bigger picture of what it is doing and then try to figure
out why.

Properly stating an algorithms put it the other way. Overview first, then
the major steps. It is much easier and much clearer.



--
We have failed to address the fundamental truth that endless growth is
impossible in a finite world.

[Bryan]

Jeff L wrote:
> Thanks Klaus- I had seen something similar but I thought maybe
> somebody could run it through their program and determine how robust
> it was depending on if it took the computers a short amount of time,
> or longer. Or, maybe instead of doing a Sudoku puzzle, or some other
> hobby for a couple of minutes that they could try this.

Yes "somebody could". I nominate you, Jeff. Fair point that we long-
term sci.crypt participants have dropped balls. The FAQ is way out of
date. Still, their are lessons one could take.

> I'm just
> trying to satisfy a youngster's curiosity, and figured someone might
> be up for the challenge of seeing if they could crack a 13 year old's
> code without a computer.

Ah, "without a computer" is not what sci.crypt was ever about. We
occasionally touch on historical problems, but antiques are not the
focus. Those computer things turned out to be kind of useful. Keeping
up is a challenge, and frankly, we old-timers have more of an excuse
than the 13 year old.

-bry

[Jeff L]

On May 5, 11:12 am, "David Eather" <eat...@tpg.com.au> wrote:
<snip>

You might understand how and why
> you coded your encryption function a particular way but nobody else will.

Isn't that the idea behind encyrpting something? If the fact that a
cipher isn't based on an algorithm makes it harder to break, isn't
that a good thing?

[Jeff L]

On May 6, 4:26 am, Bryan <bryanjugglercryptograp...@yahoo.com> wrote:
> Jeff L wrote:
> > Thanks Klaus- I had seen something similar but I thought maybe
> > somebody could run it through their program and determine how robust
> > it was depending on if it took the computers a short amount of time,
> > or longer. Or, maybe instead of doing a Sudoku puzzle, or some other
> > hobby for a couple of minutes that they could try this.
>
> Yes "somebody could". I nominate you, Jeff. Fair point that we long-
> term sci.crypt participants have dropped balls. The FAQ is way out of
> date. Still, their are lessons one could take.

Where would I go about finding such software and trying to use it?

>
> > I'm just
> > trying to satisfy a youngster's curiosity, and figured someone might
> > be up for the challenge of seeing if they could crack a 13 year old's
> > code without a computer.
>
> Ah, "without a computer" is not what sci.crypt was ever about. We
> occasionally touch on historical problems, but antiques are not the
> focus. Those computer things turned out to be kind of useful. Keeping
> up is a challenge, and frankly, we old-timers have more of an excuse
> than the 13 year old.
>
> -bry

As a general question: is there a certain minimum number of characters
that have to be present to break a cipher? Say two friends decide that
they are going to communicate in code by subtracting 1 letter from the
first character that is transmitted, and 2 from the 2nd letter, 3
from, the third, etc. The first guy asks a question and 2nd guy tells
him he will respond in an email. He answers with "X,C,P". I would
think if someone intercepted that message that there would be no way
they could ever determine what it meant. Now, if they write a full
page of letters I would think that there would be a way to break the
code. So, how many characters does it generally take to break a cipher
that is not based on some fancy algorithm? Although I guess that
technically that cipher is based on an algorithm if my understanding
of algos is correct.

[FireXware]

No, see: http://en.wikipedia.org/wiki/Kerckhoffs's_principle

[Jeff L]

I'm note trying to be argumentative, but I don't see how anyone knows
that K's principle is necessarily the gospel truth. Using his
principle, one of the most famous and effective methods of passing
coded messages in history would be considered a failure. I'm speaking
of course about the U.S. using Native Americans to pass messages
during the WWII.

Part of me understands the theory behind the axiom, and the need for
the method to still work even if the secret of it is discovered, but
the other part of me says how different is that than the enemy
discovering the key instead of the algorithm.

[FireXware]

On 05/06/2012 08:02 PM, Jeff L wrote:
> On May 6, 9:18 pm, FireXware <n...@none.invalid> wrote:
>> On 05/06/2012 05:22 PM, Jeff L wrote:
>>
>>> On May 5, 11:12 am, "David Eather" <eat...@tpg.com.au> wrote:
>>> <snip>
>>> You might understand how and why
>>>> you coded your encryption function a particular way but nobody else will.
>>
>>> Isn't that the idea behind encyrpting something? If the fact that a
>>> cipher isn't based on an algorithm makes it harder to break, isn't
>>> that a good thing?
>>
>> No, see:http://en.wikipedia.org/wiki/Kerckhoffs's_principle
>
> I'm note trying to be argumentative, but I don't see how anyone knows
> that K's principle is necessarily the gospel truth. Using his
> principle, one of the most famous and effective methods of passing
> coded messages in history would be considered a failure. I'm speaking
> of course about the U.S. using Native Americans to pass messages
> during the WWII.

Relative to our time, they are insecure. That doesn't mean they are/were
useless, it just means we can/should do better. I am not familiar with
that bit of American history, but I think I can safely assume it would
have been more secure to transmit messages over a copper wire encrypted
with AES. History has shown very well that trying to keep the algorithm
secret more often than not leads to failure (Enigma, GSM, etc.)

>
> Part of me understands the theory behind the axiom, and the need for
> the method to still work even if the secret of it is discovered, but
> the other part of me says how different is that than the enemy
> discovering the key instead of the algorithm.

If you COULD keep the algorithm a complete secret (and by complete
secret, I mean that no matter how many chosen plaintexts and chosen
ciphertexts an attacker is able to get, he doesn't learn a single bit
about what the algorithm does), then it could be as secure as keeping a
key secret. The problem with that is it's MUCH harder to keep an
algorithm secret than a key, and when the algorithm is compromised, you
have to design a whole new algorithm instead of just generating another
random key.

For example, if you are communicating with soldiers on the battlefield,
it's very likely that their devices will be captured by the enemies and
analyzed. If your algorithm's security depends on its secrecy, the enemy
can now listen in on your communications. If OTOH, your algorithm has
been public for 10 years and experienced cryptographers have been
putting a lot of effort into trying to break it, you don't have to worry
so much about the enemy capturing the crypto devices. If you keep the
algorithm secret and try to cryptanalyze it yourself, you still have to
worry because the enemy might have better cryptanalysts.

[bert]

On Monday, May 7, 2012 12:32:03 AM UTC+1, Jeff L wrote:

> So, how many characters does it generally take to break a cipher
> that is not based on some fancy algorithm?

You're quite right. If the message is short enough,
then even if you know the encryption system, you
can find different keys that each decrypt the cipher
to different equally-plausible messages.

Search Wikipedia for the topic "unicity distance".
--

[David Eather]

I'm not sure where others are up to....

You are hung up on the word 'algorithm' - substitute the the word 'method'
and you have the idea. An algorithm is just the steps you go through to
encrypt (or decrypt) something - whatever you are doing there is an
algorithm, even if you haven't been able to write it out properly.

[Gordon Burditt]

> As a general question: is there a certain minimum number of characters
> that have to be present to break a cipher? Say two friends decide that
> they are going to communicate in code by subtracting 1 letter from the
> first character that is transmitted, and 2 from the 2nd letter, 3
> from, the third, etc. The first guy asks a question and 2nd guy tells
> him he will respond in an email. He answers with "X,C,P". I would
> think if someone intercepted that message that there would be no way
> they could ever determine what it meant. Now, if they write a full

There are very few sensible 3-character messages, especially if you
have reason to believe that the answer is in English. It might not
be unreasonable to assume, at least on a trial basis, that a
2-character message was NO and a 3-character message was YES,
although other sensible possibilities exist, like OK, NG, 3PM, and
4Q.

If I see the *same* 3-character and 2-character messages repeated,
I'm likely to conclude at least on a trial basis that they are YES and
NO, and then start looking for patterns. For a simple pattern like
you indicated, that might be enough to break it, if that pattern made
sense of the encrypted question I also intercepted.

There's a reason why padding messages so the length of the ciphertext
does not reveal the length of the plaintext is a good idea.

[lur...@gmail.com]

On Friday, May 4, 2012 12:06:46 AM UTC-5, Jeff L wrote:
....
110210112013102110220131221132301230110220013122113230123012013201201101201312013201312023201311013012132110212112332213112012121311102012132120231102201311011011102101120131021211232023120132012121311020
>
Jeff, Putting your Ct in some sort of grouping is helpful, standard groups of 5(most common), 8, 10, 16, or other. A program would need to ignore the spaces but often programmers don't follow that tradition.

When I see a pattern like above, I first see a series of trits not bits.

All ciphers can be graded as to relative strength based on a common range of Ct size needed to verify solution:

SSS#

This Strength Scale for ciphers is constructed using logs base 27 whereas the SSS# for a particular cipher is the empirical amount of ciphertext, corrected to base 27, normally required for a confirmed solution. Values: 0 to 1 for Trivial or Very Weak; 1 to 2 is Weak; 2 to 3 is Marginally Strong; 3 to 4 is Strong; and 4+ is Very Strong. Most algorithms can be rated according to this scale although such ratings may be as a Range of experienced and practical strengths rather that a specific value. This formula is an extention of the Unicity Concept named by Claude Shannon but based on historical experience of which he surely was or should have been aware.

WTShaw

[Bryan]

Jeff L wrote:
> Where would I go about finding such software and trying to use it?

The software I like for exploring cryptology is the standard Python
distribution. Python 2 was popular among some notable cytologists, and
Python 3 is an improvement.
http://www.python.org/

> As a general question: is there a certain minimum number of characters
> that have to be present to break a cipher?

Yes, and cytologists need to know, but don't get too hung up on it.
The seminal paper is still worth reading for the theory. On the other
hand, had someone pointed me to the research literature when I was 13,
it would probably have put me off crypto for life. Shannon's paper,
particular the half on theoretical security, is excellent for its
clarity, but definitely college-level reading. Maybe grad school. For
AP credit you can find it at:
http://netlab.cs.ucla.edu/wiki/files/shannon1949.pdf

Well as Shannon's work stands, the world has advanced. For public-key
ciphers, the unicity distance, the "minimum number of characters that
have to be present to break a cipher", is zero.

--
--Bryan