Triangulation Cryptography.- The Triangle model is Merely the Box That the Ciphertext Travels In'

[austin obyrne]

It appears that some readers are mistakenly thinking that the
intractability of my cipher comes from not knowing how the
ciphertext vector V3 is resolved into the unique pair of
components that comprise the hidden operands of the
decryption scheme.

They wrongly think it can be brute forced. That is impossible
however. The side called V1 has been mathematically compounded
and is an intractable key. Also, it is not the only key.

NB. Counting V1 as a single key there are * three more hidden
keys that are just as intractable and which must be found so
as to achieve correct step-by-step serial decryption by Bob..

Furthermore, it is totally wrong to think that V1 in the triangle
can be found by brute force and that correct decryption
immediately follows with just some simple steps.

No, there are three more impossible-to-guess inversion functions
before decryption is correctly realised by Bob.

Comment:

In any case:

'Brute force' is a search engine that must be told when to stop
searching i.e. when some prescribed condition is fulfilled.
That is not possible here by adversaries..

Most claims for successful brute force fail at that juncture
i.e. It is impossible to write a program for a search engine
if the terminating condition cannot be provided. It follows
there is no search engine. That is the case here

Austin O’ Byrne.

[Richard Heathfield]

On 17/09/2021 14:25, austin obyrne wrote:
> It appears that some readers are mistakenly thinking that the
> intractability of my cipher comes from not knowing how the
> ciphertext vector V3 is resolved into the unique pair of
> components that comprise the hidden operands of the
> decryption scheme.
>
> They wrongly think it can be brute forced. That is impossible

Austin, we've heard you say "impossible" so often, but there is a pile
of "impossible" decryptions all around you which you keep ignoring in
the hope we can't see them. We can..

> however. The side called V1 has been mathematically compounded
> and is an intractable key. Also, it is not the only key.

It doesn't matter. We just need enough messages all encrypted the same
way and we can hand you your plaintext on a plate. This is partly
because you encrypt one character at a time but mostly because you don't
understand the importance of diffusion.

> NB. Counting V1 as a single key there are * three more hidden
> keys that are just as intractable and which must be found so
> as to achieve correct step-by-step serial decryption by Bob..

Bob, sure. But we're not Bob. We're Eve.

Eve cheats. Eve is sneaky. Eve is inventive. Eve finds other ways.

Eve doesn't need your keys.

> Furthermore, it is totally wrong to think that V1 in the triangle
> can be found by brute force and that correct decryption
> immediately follows with just some simple steps.

You can say that till you're blue in the face, but we've seen the
"impossible" decryptions.

> No, there are three more impossible-to-guess inversion functions
> before decryption is correctly realised by Bob.

That's Bob's problem, not Eve's problem.

> Comment:
>
> In any case:
>
> 'Brute force' is a search engine

Not really. A search engine is something else - a tool for trawling
through the Web. Yes, you can use the words "search engine" to describe
brute force but it's like using the words "tyre lever" to describe a
steering wheel; it's just not what we commonly use those words for, so
you're asking to be misunderstood.

> that must be told when to stop
> searching i.e. when some prescribed condition is fulfilled.
> That is not possible here by adversaries..

That's the same for any Eve decryption. It's amazing how often Eve
manages it anyway. And if Eve can do it sometimes (which we know she
can), it is clearly possible.

> Most claims for successful brute force fail at that juncture
> i.e. It is impossible to write a program for a search engine
> if the terminating condition cannot be provided. It follows
> there is no search engine. That is the case here

Since you can only encrypt a limited subset of ASCII, a trial decrypt
that results only in ASCII 32-126 is a fair bet for closer inspection.

That ridiculous limitation of yours actually therefore makes far easier
Eve's job of defining a terminating condition for her program.

--
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

[Max]

On 17.09.21 16:35, Richard Heathfield wrote:
> On 17/09/2021 14:25, austin obyrne wrote:

<snip>

>
> Since you can only encrypt a limited subset of ASCII, a trial decrypt
> that results only in ASCII 32-126 is a fair bet for closer inspection.

Tbh, if the whole system works in base, idk, 94 of something, this
wouldn't work. But, I doubt this, too and the limitation is of course a
bit weird.

[Rich]

Max <maxt...@gmx.net> wrote:
> On 17.09.21 16:35, Richard Heathfield wrote:
>> On 17/09/2021 14:25, austin obyrne wrote:
> <snip>
>>
>> Since you can only encrypt a limited subset of ASCII, a trial decrypt
>> that results only in ASCII 32-126 is a fair bet for closer inspection.
>
> Tbh, if the whole system works in base, idk, 94 of something, this
> wouldn't work. But, I doubt this, too and the limitation is of course a
> bit weird.

Actually, Austin's 'system' works in binary (although he does not
realize this) and his "characters" are, likely (MM could say with
greater accuracy) stored in the Ada equivalent of a C char * string
(i.e., one byte per character). And they are stored using the ASCII
codepoints. His 'limitation' of ASCII 32-126 is because Ada's text
mode I/O library (the only one Austin knows how to use) enforces that
all characters read in from a file (or from a terminal) must lie
between 32-126 (with special 'behind the scenes' handling of newlines,
which is why Austin is also ignorant of ASCII newlines).

But it is most definetly not "base 94". It is simply ASCII, with each
code point encoded into a single byte.

And yes, if one were to perform a brute force run against one of his
examples, one could immediately reject as invalid any output which had
any byte with a value other than 32-126 present. That significantly
narrows the number of trials that one has to otherwise examine.

[Max]

On 17.09.21 22:34, Rich wrote:
> Max <maxt...@gmx.net> wrote:
>> On 17.09.21 16:35, Richard Heathfield wrote:
>>> On 17/09/2021 14:25, austin obyrne wrote:
>> <snip>
>>>
>>> Since you can only encrypt a limited subset of ASCII, a trial decrypt
>>> that results only in ASCII 32-126 is a fair bet for closer inspection.
>>
>> Tbh, if the whole system works in base, idk, 94 of something, this
>> wouldn't work. But, I doubt this, too and the limitation is of course a
>> bit weird.
>
> Actually, Austin's 'system' works in binary (although he does not
> realize this) and his "characters" are, likely (MM could say with
> greater accuracy) stored in the Ada equivalent of a C char * string
> (i.e., one byte per character). And they are stored using the ASCII
> codepoints. His 'limitation' of ASCII 32-126 is because Ada's text
> mode I/O library (the only one Austin knows how to use) enforces that
> all characters read in from a file (or from a terminal) must lie
> between 32-126 (with special 'behind the scenes' handling of newlines,
> which is why Austin is also ignorant of ASCII newlines).
>
> But it is most definetly not "base 94". It is simply ASCII, with each
> code point encoded into a single byte.

I am pretty certain, you are right about that.

>
> And yes, if one were to perform a brute force run against one of his
> examples, one could immediately reject as invalid any output which had
> any byte with a value other than 32-126 present. That significantly
> narrows the number of trials that one has to otherwise examine.
>

Absolutely. I was just playing devil's advocate. I am sure the approach
I mentioned is not what is happening.

Cheers,

Max