Encrypting Images Using Fractals

[gary huntress]

Hi Everyone,

I've been playing with an image encryption algorithm that I think is
pretty interesting. I'd be interested in hearing any feedback about
it. In a nutshell, I do the following to encrypt and decrypt an image:

1) format the plaintext image as a square matrix
2) generate a square encyption matrix of equal size using a key
generated from a fractal (chaotic) equation
3) encrypt the plaintext with simple matrix multiplication and
send to the recipient
4) The encryption matrix is not sent to the recipient, but
rather the fractal parameters are sent via a secure means.
5) The recipient regenerates the encryption matrix using the
fractal key, inverts the matrix, and decrypts the encrypted data to
obtain the plaintext.

As an example, I encrypted and decrypted a 400x400 pixel image. I used
a generic mandelbrot fractal to generate the 400 x 400 encryption
matrix. In order to regenerate this encryption matrix, it is only
necessary to store the fractal parameters (like the mandelbrot loop
count, initial condition, and coordinates of the corners). Obviously
there are implementation issues, like ensuring that the encryption
matrix is invertable, but that isn't too difficult.

I dont make any claims that this is a method of "stronger" encryption,
because I have no means to determine the strength of an encryption
algorithm. Rather, I think that it is an "efficient" method, in that
the sender only had to provide the fractal key parameters, not the
significantly larger encryption matrix.

Fractals and encryption is a fascinating topic! Is there active
research in this area?

Regards,

Gary Huntress
hun...@ibm.net

[Henry Lewsal]

Interesting ideas, thank you for posting them here. It seems that
image compression (jpeg) cannot be used because it spoils the
squareness of the array. Then the color, 400x400 has 480,000 bytes
in the file, when jpeg would be much smaller.

Also, what range do the key parameters take? Do these parameters
provide up to 2^80 choices?

The Mandelbrot loop count is for each pixel, right? If it is, then
how is it useful for all matrix elements? Or maybe you mean the
"maximum count" allowed for each pixel before a result reaches
the "4" or "2" which is common for Mandelbrot calculation.

Also, please show a little math as background for what I have
forgotten about Mandelbrot sets.

Thanx, Henry

[wtshaw]

> Fractals and encryption is a fascinating topic! Is there active
> research in this area?
>

> Gary Huntress
> hun...@ibm.net

Since you are doing it, I guess there is. Make it actually work in code
if you can, and, as simply as you can, before trying to write the
ultimate; something generic might be scaled up.

I've seen fractals come up before, mainly requests for info.
--
I hear that some right-wing Republicans are even looking into President Clinton's past lives so as not to leave any stone unthrown; a disparaging end result justifying any obscure means.

[Coen Visser]

jgf...@vgrknf.arg (wtshaw) writes:

>> Fractals and encryption is a fascinating topic! Is there active
>> research in this area?

>> Gary Huntress
>> hun...@ibm.net

>Since you are doing it, I guess there is. Make it actually work in code
>if you can, and, as simply as you can, before trying to write the
>ultimate; something generic might be scaled up.

>I've seen fractals come up before, mainly requests for info.

The problem with using chaotic systems (and fractals) for encryption is that
they have many stable points/area's with regular behaviour. So not just
any chaotic system can be turned into an encryption system.

Regards,

Coen Visser

[gary huntress]

yes, I ran into that....but I found that if the encryption matrix was full rank,
then there was no problem. The stable "uninteresting" areas of the fractal
didn't have full rank, and did not result in an invertable encryption matrix,
and so I moved to a new region of the fractal image (with different key
parameters)

Gary

[pancak...@gmail.com]

Gary,

are you still working with this idea? I myself have begun to work in this area as well. Feel free to email me.

[Chris M. Thomasson]

On 6/19/2019 4:14 PM, pancak...@gmail.com wrote:
> Gary,
>
> are you still working with this idea? I myself have begun to work in this area as well. Feel free to email me.
>

For what its worth, here is a crude online example, however it has a
security problem:

http://funwithfractals.atspace.cc/ffe

The problem is that I did not create a means to get a completely
different ciphertext if a single plaintext bit is altered. This is bad!
However, it can be fixed.

Also, there is another way to accomplish fractal encryption. That is to
encode data directly into complex numbers, we can encode into the Julia
set. Well, here is some example code that encrypts into the unit circle:

https://groups.google.com/d/topic/comp.lang.c++/kuEV7aZhNUs/discussion

This goes to the unit circle. Adding a Julia is fairly straight forward.
Actually, it is interesting to look the renderings of fractals that have
data stored within them.

Here is some example C code for my online example:

https://github.com/ChrisMThomasson/fractal_cipher/blob/master/FFE/ffe.c

This is an experimental full blown command line program. It should
compile right up and run. It has full usage information.

[pancak...@gmail.com]

Thank you very much for the reply. In terms of the world of post quantum encryption, do you find this a possible viability once refined?

[pancak...@gmail.com]

I will be working on a fork with your code here to solve some of the issues and hopefully reach an acceptable standard and proof of concept.

But only with your permission!

[Chris M. Thomasson]

On 6/19/2019 4:23 PM, Chris M. Thomasson wrote:
> On 6/19/2019 4:14 PM, pancak...@gmail.com wrote:
>> Gary,
>>
>> are you still working with this idea? I myself have begun to work in
>> this area as well. Feel free to email me.
>>
>
> For what its worth, here is a crude online example, however it has a
> security problem:
>
> http://funwithfractals.atspace.cc/ffe
>
> The problem is that I did not create a means to get a completely
> different ciphertext if a single plaintext bit is altered. This is bad!
> However, it can be fixed.

Another Self-SLAP (tm)! I got that backwards. I meant to say, I failed
to provide the functionality to create a completely different plaintext
_if_ a single bit of the _CIPHERTEXT_ was altered. Sorry.

Think of Eve mutating a ciphertext, person-in-the-middle-attack style,
then Bob42 decrypts the "loaded" message. Well, this is not secure with
the current state of my fractal cipher. I fixed it, using the advise of
the smart people on this group, to my HMAC cipher. However, I can fix my
fractal cipher the same way.

I can use an external HMAC, but I want to try to make this internal, and
use an external HMAC to boot.

[...]

[Chris M. Thomasson]

On 6/19/2019 4:14 PM, pancak...@gmail.com wrote:

> Gary,
>
> are you still working with this idea? I myself have begun to work in this area as well. Feel free to email me.
>

Compile and run this:

https://pastebin.com/raw/D7N4vBWa

It still has the problem of Eve being able to mutate the ciphertext.
HMAC it?

This is some old code. It should compile right up. If you are willing,
perhaps we can get on the same page wrt defining a key, and
encrypting/decrypting some plaintext.

[ao40...@gmail.com]

> Fractals and encryption is a fascinating topic! Is there active
> research in this area?
>

> Regards,
>
> Gary Huntress
> hun...@ibm.net

Yes Gary - Dare I comment on a topic that I am not sufficiently au fait with. My own wish would be to somehow bring the specifically defined plane (A variable) that contains the fractal into the algorithm also - Good Luck

Austin O'Byrne

[ao40...@gmail.com]

This would be tantamount to specifying the plane that contains the Argand Diagram - which to my mind does not have to be any old 'XY' plane despite being always taken for that.

AOB

[ao40...@gmail.com]

This means a fractal would have an 'attitude' in three-dimensional space. The set of integer points that delineate the fractal are then defined by their position vectors relative to the universal origin at (0,0,0).

This of course is a variation of my displacement cryptography - not a good one however.

Austin O'Byrne

[Chris M. Thomasson]

On 6/27/2019 11:41 PM, ao40...@gmail.com wrote:
> On Thursday, 27 June 2019 00:40:55 UTC+1, ao40...@gmail.com wrote:
>> On Wednesday, 26 June 2019 16:30:07 UTC+1, ao40...@gmail.com wrote:
>>> On Wednesday, 3 March 1999 08:00:00 UTC, gary huntress wrote:
>>>> Hi Everyone,
>>>>
>>>> I've been playing with an image encryption algorithm that I think is
>>>> pretty interesting. I'd be interested in hearing any feedback about
>>>> it. In a nutshell, I do the following to encrypt and decrypt an image:

[...]

>
> This means a fractal would have an 'attitude' in three-dimensional space. The set of integer points that delineate the fractal are then defined by their position vectors relative to the universal origin at (0,0,0).

If you want a nice fractal in 3d space, take a look at the Mandelbulb:

https://en.wikipedia.org/wiki/Mandelbulb

[ao40...@gmail.com]

Yes mate - The imagery is captivating - I wish I could do it but can't - what is needed from fractals as applied to cryptography in my view is a process that turns fractals into *fonts* - I honestly don't think that is feasible - anyway , fractals are far too nice as they are to waste on such a nefarious business as cryptography.

Austin O'Byrne

[Chris M. Thomasson]

Why not? Each Glyph can be a Julia Set.

[ao40...@gmail.com]

Go for it.

[Chris M. Thomasson]

Let me start with two letters... A and B. Say, A is equal to:


http://paulbourke.net/fractals/logspiral

Paul created some nice renderings using my formula. Well, this can be
the glyph for A. The following can be B:

http://paulbourke.net/fractals/fractionalpowers

C can be:

http://paulbourke.net/fractals/cubicjulia

There. I defined a potential A, B and C. These symbols can be put into
an L-system. ;^)

Btw, thanks to Paul Bourke for creating high-resolution renderings using
my formulas! :^)

[ao40...@gmail.com]

I love what I see but the reality is that these are still scalar transformations and they will inevitably leave what I call a 'statistical footprint' in the ciphertext that can be mapped to the original encryption alphabet - not easily I concede but there for the finding by dedicated cryptanalysts who possess the latest supercomputers (Currently in the hands of the Chinese - nothing especially sinister about that... but)and who can write copious search engines for running on these computers.

I still say - "Keep these beautiful fractals for their more spiritual benefit" and forget any application to cryptography.

Austin.

[Chris M. Thomasson]

On 6/29/2019 10:48 PM, ao40...@gmail.com wrote:
> On Saturday, 29 June 2019 21:50:05 UTC+1, Chris M. Thomasson wrote:
>> On 6/29/2019 7:32 AM, ao40...@gmail.com wrote:

[...]

>> Btw, thanks to Paul Bourke for creating high-resolution renderings using
>> my formulas! :^)
>
> I love what I see but the reality is that these are still scalar transformations and they will inevitably leave what I call a 'statistical footprint' in the ciphertext that can be mapped to the original encryption alphabet - not easily I concede but there for the finding by dedicated cryptanalysts who possess the latest supercomputers (Currently in the hands of the Chinese - nothing especially sinister about that... but)and who can write copious search engines for running on these computers.
>
> I still say - "Keep these beautiful fractals for their more spiritual benefit" and forget any application to cryptography.

I think there is some promise... Keep in mind that each glyph is
infinitely scalable. By the way, my existing highly experimental fractal
encryption, with a security flaw, does no use fractals as literal visual
glyphs. It works with each pixel in the plane to mutate the plaintext.
Here... What does this say:

The Ciphertext is between the lines:
____________________________________________
0.09511585947780479 0.30439578877093465
0.21327345502923412 0.39825179188566434

6F 21 C2 57 B5 E3 2D 8A 33 50 E2 09 3C 38 46 F7 9A 13 F7 6E 31 42 86 25
D0 14 40 E9 19 16 07 B8 27 A9 A3 36 42 5A 25 75 E2 F2 A5 95 0F 55 1F 3C
3C 3F 11 8E 63 6F 06 A6 0D 7B 0A DE E1 34 CA
____________________________________________

It was encrypted using the default key from:

http://funwithfractals.atspace.cc/ffe

copy-and-paste the ciphertext into the ciphertext textbox, click decrypt...

;^)

[ao40...@gmail.com]

Off the top of my head I can say that in there somewhere in the ciphertext there is sufficient residual structure (a footprint in other words) that can be used to render out the original plaintext that it represents. There will probably be some reduction process that is used by cryptanalysts comprised of specialist lexicologists and computer scientists working together with supercomputers who will suss out the probability of a messagetext.

I say it again , leave these beautiful fractals out of the nefarious business of cryptography. Instead, by analogy let us stop and smell the flowers on the way - I quote some famous golfer.

Austin.

[Chris M. Thomasson]

Yeah. Plotting the ciphertext is a bitc%! This is why I created the
following:

http://funwithfractals.atspace.cc/ct_cipher

Let me get bold:

I dare you to crack this!

lol. ;^)

[Chris M. Thomasson]

It does not create the fractal rendering, but can have some hidden
meaning. If Rich remembers, I asked him to find a "Palm Tree" fractal
shape, wrt red and green pixels out of the ciphertext, some years ago. I
gave him a cheat sheet that showed the greed on red. The ciphertext was
all red. Hard to find!

[ao40...@gmail.com]

Smacks a bit of Steganography wouldn't you say.

Austin O'Byrne

[Chris M. Thomasson]

Wrt the fractal, I might have to agree with this in a sense. Wrt my HMAC
cipher, well, that is a different ballgame. See, I can use my special
sauce HMAC thing with an experimental fractal hash thing. Part of the
secret key is literally an user defined hash algorihtm! So, this can be
anything... It can be private to Alice and Bob42.

[ao40...@gmail.com]

I wouldn't even attempt it - it would be too difficult for me with my limited resources but that is no criterion. At the design stage a cryptographer must think at the level of the very utmost challenge (which yours isn't by a long chalk)i.e. the cipher they are preparing must be impervious to a team of lexicologists and computer scientists who are continuously making non-stop searches using off-the-shelf previously designed test engines and using the utmost in current supercomputers.

My displacement cryptography easily resists all of that. I don't think your's does.

Austin O'byrne

[Chris M. Thomasson]

On 6/30/2019 3:34 AM, ao40...@gmail.com wrote:
> On Sunday, 30 June 2019 09:52:36 UTC+1, Chris M. Thomasson wrote:
>> On 6/30/2019 12:54 AM, ao40...@gmail.com wrote:

[...]

>>>>> This is why I created the
>>>>> following:
>>>>>


>>>>> http://funwithfractals.atspace.cc/ct_cipher

[...]

> <><><> I dare you to crack this!
> I wouldn't even attempt it - it would be too difficult for me with my limited resources but that is no criterion. At the design stage a cryptographer must think at the level of the very utmost challenge (which yours isn't by a long chalk)i.e. the cipher they are preparing must be impervious to a team of lexicologists and computer scientists who are continuously making non-stop searches using off-the-shelf previously designed test engines and using the utmost in current supercomputers.
>
> My displacement cryptography easily resists all of that.

Does it? How? Iirc, there was a ciphertext only attack here by Richard,
right?

> I don't think your's does.

So far, afaict, it should boil down to cracking the underlying hmac and
hash algorihtm. The initial hash digest is the main target of Eve wrt my
work. A couple of people have told me they think it is secure as long as
the initial digest is large enough... 1024 bytes comprised of several
hash digests is nice ;^)

Wrt my ciphertext itself, well it gets some damn good numbers with
programs like ent:

http://www.fourmilab.ch/random

Have you run your ciphertext through anything like this?

My algorihtm allows one to prepend a number of TRNG bytes. This makes
things "appear" to be random, in a sense. The user needs to use at least
enough TRNG bytes to cover the hash digest, preferably more. Also, my
ciphertext is immune to alterations. If one bit is mutated then Bob42
will decrypt gibberish. I added this "feature" as a pure experiment.

[Richard Heathfield]

On 01/07/2019 09:03, Chris M. Thomasson wrote:
> On 6/30/2019 3:34 AM, ao40...@gmail.com wrote:
>> On Sunday, 30 June 2019 09:52:36 UTC+1, Chris M. Thomasson  wrote:

<snip>

>>> I dare you to crack this!
>> I wouldn't even attempt it - it would be too difficult for me with my
>> limited resources but that is no criterion.  At the design stage a
>> cryptographer must think at the level of the very utmost challenge
>> (which yours isn't by a long chalk)i.e. the cipher they are preparing
>> must be impervious to a team of lexicologists and computer scientists
>> who are continuously making non-stop searches using off-the-shelf
>> previously designed test engines and using the utmost in current
>> supercomputers.
>>
>> My displacement cryptography easily resists all of that.
>
> Does it? How? Iirc, there was a ciphertext only attack here by Richard,
> right?

Yes, but I can take hardly any of the credit, which rightly belongs to
others.

The attack was based on two weaknesses in AOB's cryptosystem.

The first weakness is endemic to all the AOB cryptosystems I've seen so
far, and was therefore already widely known to everyone except AOB, who
still refuses to acknowledge it.

The second weakness was spotted not by me but by someone else (I forget
who, but it would probably have been MM or Rich or wizzofozz).

All I did was to show how Eve could use those two weaknesses, taken
together, to reveal several different plaintexts all at once.

AOB does not understand the attack. (He tends to respond to such attacks
by posting one ciphertext and saying "go on then, crack that if you're
so clever" or words to that effect, and there could be no clearer way of
admitting that he doesn't understand the attack.)

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[Rich]

Chris M. Thomasson <invalid_chris_t...@invalid.com> wrote:
> On 6/30/2019 3:34 AM, ao40...@gmail.com wrote:
>> On Sunday, 30 June 2019 09:52:36 UTC+1, Chris M. Thomasson wrote:
>>> On 6/30/2019 12:54 AM, ao40...@gmail.com wrote:
> [...]
>>>>>> This is why I created the
>>>>>> following:
>>>>>>
>
>
>>>>>> http://funwithfractals.atspace.cc/ct_cipher
>
>
> [...]
>> <><><> I dare you to crack this!
>> I wouldn't even attempt it - it would be too difficult for me with
>> my limited resources but that is no criterion. At the design stage
>> a cryptographer must think at the level of the very utmost challenge
>> (which yours isn't by a long chalk)i.e. the cipher they are
>> preparing must be impervious to a team of lexicologists and computer
>> scientists who are continuously making non-stop searches using
>> off-the-shelf previously designed test engines and using the utmost
>> in current supercomputers.
>>
>> My displacement cryptography easily resists all of that.
>
> Does it? How? Iirc, there was a ciphertext only attack here by Richard,
> right?
>
>
>> I don't think your's does.
>
> So far, afaict, it should boil down to cracking the underlying hmac and
> hash algorihtm.

Please note the obvious in his statements:

1) your algorithm - does not resist "all of that"
2) his algorithm - does resist "all of that"

With no explanation nor supporting evidence or argument as to how
either statement is true.

[ao40...@gmail.com]

Absolute rubbish but he will get his chance to demonstrate his claim later when I am not so busy - promise.
AOB

[Chris M. Thomasson]

Whats rubbish? My work, the attacks against yours or both? I need a
clarification. Btw, have you run your ciphertext through any
"randomness" tests, so to speak?

> but he will get his chance to demonstrate his claim later when I am not so busy - promise.

Who? Richard? The WIZ; MM; Rich, ect...? Richard mentioned that he got a
lot of help from others, then used his excellent coding skills to create
a nice little Eve program... :^)

[Richard Heathfield]

On 01/07/2019 16:11, ao40...@gmail.com wrote:
> On Monday, 1 July 2019 09:03:24 UTC+1, Chris M. Thomasson wrote:
>> On 6/30/2019 3:34 AM, ao40...@gmail.com wrote:

<snip>

>>>
>>> My displacement cryptography easily resists all of that.
>>
>> Does it? How? Iirc, there was a ciphertext only attack here by Richard,
>> right?
>>

<snip>

>
> Absolute rubbish but he will get his chance to demonstrate his claim later when I am not so busy - promise.

Already demonstrated, me ol' flower.

https://groups.google.com/forum/#!topicsearchin/sci.crypt/subject$3ACT-ONLY$20AND$20subject$3ABREAK$20AND$20subject$3Aof$20AND$20subject$3AVeeCrypt$20AND$20subject$3Acryptosystem/sci.crypt/nZqCjXjtbFI

Subject: CT-ONLY BREAK of VeeCrypt cryptosystem
Date: 9 June 2017

[Bruce Stephens]

On 01/07/2019 20:52, Chris M. Thomasson wrote:
> Btw, have you run your ciphertext through any "randomness" tests, so to
> speak?

As far as I remember, only trivial home grown ones, counting individual
elements. (See previous claims about isochronous and isentropic.
("isochronous" seems quite the wrong word to me, but it's one he's used.
Doesn't matter much, obviously.))

[ao40...@gmail.com]

In order to allay all fears and scotch all claims I have decided that Alice as a matter of form will always *encrypt the keys she periodically sends to Bob, The initial key(s)will be mentally transported by the couriers.

AOB

[Chris M. Thomasson]

Have you looked into telepathy? Couriers seem dangerous.

[ao40...@gmail.com]

Carrier pigeons are a possibilty.

[Richard Heathfield]

On 02/07/2019 00:49, ao40...@gmail.com wrote:
> On Monday, 1 July 2019 20:52:35 UTC+1, Chris M. Thomasson wrote:
>> On 7/1/2019 8:11 AM, ao40...@gmail.com wrote:

<snip>

>>
>>> but he will get his chance to demonstrate his claim later when I am not so busy - promise.
>>
>> Who? Richard? The WIZ; MM; Rich, ect...? Richard mentioned that he got a
>> lot of help from others, then used his excellent coding skills to create
>> a nice little Eve program... :^)
>
> In order to allay all fears and scotch all claims I have decided that Alice as a matter of form will always *encrypt the keys she periodically sends to Bob, The initial key(s)will be mentally transported by the couriers.

A further complication in keying, which makes it even more likely that
an attack along the lines I suggested in June 2017 will succeed.

I re-posted this ciphertext-only attack last night under the title
"CT-ONLY BREAK of VeeCrypt cryptosystem", mainly to remind AOB that I
don't need to demonstrate my claim because I've already demonstrated it.

[Andrew Swallow]

On 02/07/2019 01:39, ao40...@gmail.com wrote:
> On Tuesday, 2 July 2019 00:59:34 UTC+1, Chris M. Thomasson wrote:

{snip}

>>
>> Have you looked into telepathy? Couriers seem dangerous.
>
> Carrier pigeons are a possibilty.
>

Carrier pigeons - Watch out for the vulture squadron.

<https://upload.wikimedia.org/wikipedia/en/9/91/Dastardly_%26_Muttley_in_Their_Flying_Machines.jpg>

[Richard Heathfield]

On 02/07/2019 07:49, Andrew Swallow wrote:
> On 02/07/2019 01:39, ao40...@gmail.com wrote:
>> On Tuesday, 2 July 2019 00:59:34 UTC+1, Chris M. Thomasson  wrote:
> {snip}
>
>>>
>>> Have you looked into telepathy? Couriers seem dangerous.
>>
>> Carrier pigeons are a possibilty.
>>
>
> Carrier pigeons - Watch out for the vulture squadron.

See also RFC 2549.

[ao40...@gmail.com]

This might a good time to say it i.e. something that is so fundamentally true that it preempts all attempts at at strong cryptography that uses it:
"Scalar cryptography i.e. cryptography that uses scalar data will never succeed - it simply cannot succeed no matter how elegant or ingenious the algorithm may be - this is the DNA of data and the origins will always be retrievable.

The sooner people bite that bullet the sooner they will move on to displacement cryptography which uses vector data. Mathematician readers will see this to be true more quickly than others.

A three-dimensional encryption arena is sine qua non to the achievement of unbreakable cryptography.

AOB

[Richard Heathfield]

On 02/07/2019 09:19, ao40...@gmail.com wrote:
<snip>

>
> This might a good time to say it i.e. something that is so fundamentally true that it preempts all attempts at at strong cryptography that uses it:
> "Scalar cryptography i.e. cryptography that uses scalar data will never succeed - it simply cannot succeed no matter how elegant or ingenious the algorithm may be - this is the DNA of data and the origins will always be retrievable.

Hitchens's Razor applies. What evidence have you for your assertion?

> The sooner people bite that bullet the sooner they will move on to displacement cryptography which uses vector data. Mathematician readers will see this to be true more quickly than others.

This'd be the same crypto that you were touting a couple of years ago,
no doubt. The sci.crypt community identified some problems with that, I
seem to recall, and several attacks were published. One of them was a
ciphertext-only *BREAK*. For your benefit and education I re-posted the
break last night.

> A three-dimensional encryption arena is sine qua non to the achievement of unbreakable cryptography.

No, *unbreakability* is the sine qua non of unbreakable cryptography.

Thy vector approach lyeth in broken shards on yonder floor.

[MM]

On Tuesday, 2 July 2019 09:54:55 UTC+1, Richard Heathfield wrote:
> > The sooner people bite that bullet the sooner they will move on to displacement cryptography which uses vector data. Mathematician readers will see this to be true more quickly than others.
>
> This'd be the same crypto that you were touting a couple of years ago,
> no doubt. The sci.crypt community identified some problems with that, I
> seem to recall, and several attacks were published. One of them was a
> ciphertext-only *BREAK*. For your benefit and education I re-posted the
> break last night.

That break was for a cipher that has now been discarded.

No matter; no lessons were learnt, and the current cipher (code
unpublished) has no improvements from past failures applied,
and has all the weaknesses previously exposed.

The cipher currently touted encrypts single characters into number
triples, adds easy-to-remove triples after the cross-product
calculation and has a useless crap-scramble at the end.

M
--

[Richard Heathfield]

On 02/07/2019 10:48, MM wrote:
> On Tuesday, 2 July 2019 09:54:55 UTC+1, Richard Heathfield wrote:
>>> The sooner people bite that bullet the sooner they will move on to displacement cryptography which uses vector data. Mathematician readers will see this to be true more quickly than others.
>>
>> This'd be the same crypto that you were touting a couple of years ago,
>> no doubt. The sci.crypt community identified some problems with that, I
>> seem to recall, and several attacks were published. One of them was a
>> ciphertext-only *BREAK*. For your benefit and education I re-posted the
>> break last night.
>
> That break was for a cipher that has now been discarded.

Sure, but the replacement is... oh, wait, reading on...

>
> No matter; no lessons were learnt, and the current cipher (code
> unpublished) has no improvements from past failures applied,
> and has all the weaknesses previously exposed.

Indeed. So the same techniques apply.

>
> The cipher currently touted encrypts single characters into number
> triples, adds easy-to-remove triples after the cross-product
> calculation and has a useless crap-scramble at the end.

What you are describing has essentially the same structure as the
original (or at least, the first version I encountered of) Shuttlepads:
a pointlessly inflated polyalphabetic substitution cipher with arbitrary
noise, "superencrypted" with a technique that I demonstrated how to
remove *years* ago.

[MM]

On Tuesday, 2 July 2019 10:56:38 UTC+1, Richard Heathfield wrote:
> On 02/07/2019 10:48, MM wrote:
> > No matter; no lessons were learnt, and the current cipher (code
> > unpublished) has no improvements from past failures applied,
> > and has all the weaknesses previously exposed.
>
> Indeed. So the same techniques apply.

It may even be easier. In spite of all the cross-product stuff, he
ends up with an encipherment of C(N) = N(a,b,c) = (Na,Nb,Nc)
where N is the plaintext and a,b,c are integers. Thus, an attack is to
factorise each of the numbers in the triple, and discard any factors
that are not common. The plaintext will then be the product of
some sub-list of the remaining factors.

This was pointed out *years* ago, and not by me either.

M
--

[Richard Heathfield]

On 02/07/2019 11:21, MM wrote:
> In spite of all the cross-product stuff, he
> ends up with an encipherment of C(N) = N(a,b,c) = (Na,Nb,Nc)
> where N is the plaintext and a,b,c are integers. Thus, an attack is to
> factorise each of the numbers in the triple, and discard any factors
> that are not common. The plaintext will then be the product of
> some sub-list of the remaining factors.

That's actually embarrassing, or it would be if AOB were capable of
embarrassment.

> This was pointed out *years* ago, and not by me either.

Learning can be difficult.

[MM]

On Tuesday, 2 July 2019 16:14:04 UTC+1, Richard Heathfield wrote:
> That's actually embarrassing, or it would be if AOB were capable of
> embarrassment.

He is very easily embarrassed, but reacts by denying, not by
correcting. To correct would be to admit fault, and he is too
proud to do that.

M
--

[Chris M. Thomasson]

On 7/2/2019 12:07 AM, Richard Heathfield wrote:
> On 02/07/2019 07:49, Andrew Swallow wrote:
>> On 02/07/2019 01:39, ao40...@gmail.com wrote:
>>> On Tuesday, 2 July 2019 00:59:34 UTC+1, Chris M. Thomasson  wrote:
>> {snip}
>>
>>>>
>>>> Have you looked into telepathy? Couriers seem dangerous.
>>>
>>> Carrier pigeons are a possibilty.
>>>
>>
>> Carrier pigeons - Watch out for the vulture squadron.
>
> See also RFC 2549.
>

Wow! :^D

https://en.wikipedia.org/wiki/IP_over_Avian_Carriers

[ao40...@gmail.com]

All.
I have decided that I should not go any further with a demonstration of the key transport system That I outlined recently. The reason for this is that I would be pandering to a group of backward looking dissidents who are still laboring in the past and will almost certainly want to cast doubt over my invention.

I am satisfied that all properly orientated mathematical readers will already have recognized the truth of my scheme (which is not the only one available to me) and there is no need for me to defend anything.
Austin O’byrne

[MM]

On Wednesday, 3 July 2019 09:29:48 UTC+1, ao40...@gmail.com wrote:
> I have decided that I should not go any further with a demonstration of the key
> transport system That I outlined recently.

You don't have a key transport system!

Instead you have a bizarre requirement for multiple couriers memorising bits of your
key, and passing them on by Chinese whisper.

> I am satisfied that all properly orientated mathematical readers will already have

> recognized the truth of my scheme (which is not the only one available to me) ...

They have, repeatedly, and the answer was not favourable to you *at* *all*.

... and there is no need for me to defend anything.

Not so much need as ability. You have comprehensively lost this debate and you
don't have the honesty to admit it.

M
--

[Richard Heathfield]

On 03/07/2019 09:50, MM wrote:
> On Wednesday, 3 July 2019 09:29:48 UTC+1, ao40...@gmail.com wrote:
>> I have decided that I should not go any further with a demonstration of the key
>> transport system That I outlined recently.
>
> You don't have a key transport system!
>
> Instead you have a bizarre requirement for multiple couriers memorising bits of your
> key, and passing them on by Chinese whisper.

Well, perhaps AOB can improve on that a *little* bit; we can keep the
multiple couriers without having to trust them, and we can do a little
bit better than Chinese whispers, by using the Internet as follows.

(1) Alice divides the key into individual bits, and each bit will be
carried by a separate "courier" (see below);
(2) Alice encodes the bits as ASCII characters '0' or '1' (in keeping
with AOB rules on representation);
(3) Alice stores each encoding in a separate UDP/IP datagram (the
"courier");
(4) Alice stores 0xFFFFFFFF into the pseudoheader of each datagram (bits
32-63), and ships them down the wire;
(5) Bob II picks up all the datagrams, discards duplicated packets, and
reassembles the remainder in the correct order;
(6) Alice and Bob II now have a shared key (provided Bob II has
performed Step 5 correctly).

I would be interested to hear AOB's reaction to this (admittedly very
modest) improvement to his key transport system.

[Chris M. Thomasson]

Step five seems hard for Bob II. The datagrams can come in at a
seemingly random order. However, if Alice puts ordering info in there,
then The Eve can reassemble things and create Bob III... Humm... I must
be missing something here.

[MM]

On Wednesday, 3 July 2019 10:11:20 UTC+1, Richard Heathfield wrote:
> (1) Alice divides the key into individual bits, and each bit will be
> carried by a separate "courier" (see below);

AOB can't code this. Therefore he'll dismiss it.

> (2) Alice encodes the bits as ASCII characters '0' or '1' (in keeping
> with AOB rules on representation);

OK - but you lost him on step (1). This is the only step he'll know how to
perform.

> (3) Alice stores each encoding in a separate UDP/IP datagram (the
> "courier");

AOB: "Huh?"

> (4) Alice stores 0xFFFFFFFF into the pseudoheader of each datagram (bits
> 32-63), and ships them down the wire;

AOB: *Lost*. *Denounces* *idea*.

> (5) Bob II picks up all the datagrams, discards duplicated packets, and
> reassembles the remainder in the correct order;

AOB: "Huh?"

> (6) Alice and Bob II now have a shared key (provided Bob II has
> performed Step 5 correctly).

AOB: *Dismissal*.

> I would be interested to hear AOB's reaction to this (admittedly very
> modest) improvement to his key transport system.

I predict he won't understand a word of it, let alone be able to code even
the basic beginnings of it.

He certainly won't be able to analyse it and attempt to fix any issues with it.

M
--

[Richard Heathfield]

You are missing a key element (number 26, in fact) and a key letter
(number 25, in fact).

[MM]

On Wednesday, 3 July 2019 10:53:07 UTC+1, Richard Heathfield wrote:
> You are missing a key element (number 26, in fact) and a key letter
> (number 25, in fact).

Well said!

M
--

[Richard Heathfield]

On 03/07/2019 10:52, MM wrote:
> On Wednesday, 3 July 2019 10:11:20 UTC+1, Richard Heathfield wrote:

<snip>

>
>> I would be interested to hear AOB's reaction to this (admittedly very
>> modest) improvement to his key transport system.
>
> I predict he won't understand a word of it, let alone be able to code even
> the basic beginnings of it.

Oh, fie, sir! Fie! Have a little faith in the man!

> He certainly won't be able to analyse it and attempt to fix any issues with it.

You're forgetting something; he's the world's greatest cryptographer,
right? I'm pretty sure that's written down somewhere. So I have
almost[1] every confidence that he will see precisely what I'm getting at.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999

[1] Well, nearly almost. For low values of "nearly" and "almost".

[Professor Sundar]

ao40...@gmail.com wrote:
> On Tuesday, 2 July 2019 23:16:52 UTC+1, Chris M. Thomasson wrote:
>> On 7/2/2019 12:07 AM, Richard Heathfield wrote:
>> > On 02/07/2019 07:49, Andrew Swallow wrote:
>> >> On 02/07/2019 01:39, ao40...@gmail.com wrote:
>> >>> On Tuesday, 2 July 2019 00:59:34 UTC+1, Chris M. Thomasson  wrote:
>> >> {snip}
>> >>>> Have you looked into telepathy? Couriers seem dangerous.
>> >>>
>> >>> Carrier pigeons are a possibilty.
>> >>
>> >> Carrier pigeons - Watch out for the vulture squadron.
>> >
>> > See also RFC 2549.
>> >
>>
>> Wow! :^D
>>
>> https://en.wikipedia.org/wiki/IP_over_Avian_Carriers
> All.

> I am satisfied that all properly orientated mathematical readers will
> already have recognized the truth of my scheme (which is not the only one
> available to me) and there is no need for me to defend anything.

As a properly orientated mathematical reader (see
https://www.imsc.res.in/mathematics) I can, without question or doubt,
declare that your scheme is fully inoperative and would not work for your
intended purpose.

You have no key transport system. Instead, your pontifications show a
system with no significant mathematical background reliant upon courier
memory to transport small numbers. Numbers much too small to produce
sufficient combinatorial possibilities for protecting an enciphered message.

[Rich]

Richard Heathfield <r...@cpax.org.uk> wrote:
> On 03/07/2019 10:52, MM wrote:
>> On Wednesday, 3 July 2019 10:11:20 UTC+1, Richard Heathfield wrote:
> <snip>
>>
>>> I would be interested to hear AOB's reaction to this (admittedly
>>> very modest) improvement to his key transport system.
>>
>> I predict he won't understand a word of it, let alone be able to
>> code even the basic beginnings of it.
>
> Oh, fie, sir! Fie! Have a little faith in the man!
>
>> He certainly won't be able to analyse it and attempt to fix any
>> issues with it.
>
> You're forgetting something; he's the world's greatest cryptographer,
> right? I'm pretty sure that's written down somewhere. So I have
> almost[1] every confidence that he will see precisely what I'm
> getting at.

Indeed, it was written down in comp.lang.ada, by none other than AOB
himself, on Feb. 28 of 2012 at 03:30 PST:

From: adacrypt <austin...@hotmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Banging the Ada Drum.
Date: Tue, 28 Feb 2012 03:30:43 -0800 (PST)
Message-ID: <8893fdc4-ea96-4abc...@l7g2000vbw.googlegroups.com>

[snip]

There are millions of people out there who can write great Ada -
nobody apart from me can write great cryptography.

[Richard Heathfield]

On 03/07/2019 11:56, Rich wrote:
> Richard Heathfield <r...@cpax.org.uk> wrote:
>> On 03/07/2019 10:52, MM wrote:

<snip>

>>> He certainly won't be able to analyse it and attempt to fix any
>>> issues with it.
>>
>> You're forgetting something; he's the world's greatest cryptographer,
>> right? I'm pretty sure that's written down somewhere. So I have
>> almost[1] every confidence that he will see precisely what I'm
>> getting at.
>
> Indeed, it was written down in comp.lang.ada, by none other than AOB
> himself, on Feb. 28 of 2012 at 03:30 PST:
>
> From: adacrypt <austin...@hotmail.com>
> Newsgroups: comp.lang.ada
> Subject: Re: Banging the Ada Drum.
> Date: Tue, 28 Feb 2012 03:30:43 -0800 (PST)
> Message-ID: <8893fdc4-ea96-4abc...@l7g2000vbw.googlegroups.com>
>
> [snip]
>
> There are millions of people out there who can write great Ada -
> nobody apart from me can write great cryptography.

Aha! I knew I'd seen it written down somewhere.

And it's obviously correct, because it was written by the only person in
the world who can write great cryptography, and such a person would have
no reason to lie.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

On 03/07/2019 11:52, Professor Sundar wrote:
> ao40...@gmail.com wrote:

<snip>

>> I am satisfied that all properly orientated mathematical readers will
>> already have recognized the truth of my scheme (which is not the only one
>> available to me) and there is no need for me to defend anything.
>
> As a properly orientated mathematical reader (see
> https://www.imsc.res.in/mathematics) I can, without question or doubt,
> declare that your scheme is fully inoperative and would not work for your
> intended purpose.
>
> You have no key transport system. Instead, your pontifications show a
> system with no significant mathematical background reliant upon courier
> memory to transport small numbers. Numbers much too small to produce
> sufficient combinatorial possibilities for protecting an enciphered message.

Whilst your response is most welcome, I'm afraid it will do no good.

AOB divides the world into two mutually exclusive sets:

(1) himself and people who agree with him;
(2) mathematical ignoramuses.

Since your response indicates that you are not in Set 1 (which is almost
but not quite the empty set), you must necessarily be in Set 2, no
matter what your academic background might be. AOB would cheerfully
place Newton, Gauss, and Ramanujan into Set 2.

[Chris M. Thomasson]

Ahhh! Need to squeeze some lemons into my thinking cap! I am thinking
about the mask and times for some reason? Try to be gentle... ;^o

[Chris M. Thomasson]

On 7/1/2019 2:26 PM, Bruce Stephens wrote:

> On 01/07/2019 20:52, Chris M. Thomasson wrote:
>> Btw, have you run your ciphertext through any "randomness" tests, so
>> to speak?
>

> As far as I remember, only trivial home grown ones, counting individual
> elements. (See previous claims about isochronous and isentropic.
> ("isochronous" seems quite the wrong word to me, but it's one he's used.
> Doesn't matter much, obviously.))

Strange! I thought he cared about his own work? ;^o

[Chris M. Thomasson]

Eve gets a small part of the whole. Can she still reassemble aspects of
it? I hear a toilet flushing in the background... ;^o