Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.crypt > #49974 > unrolled thread

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

Back to article view | Back to sci.crypt

Contents

  Triangulation Cryptography.- The Triangle model is Merely the Box That the Ciphertext Travels In' austin obyrne <ao402468@gmail.com> - 2021-09-17 06:25 -0700
    Re: Triangulation Cryptography.- The Triangle model is Merely the Box That the Ciphertext Travels In' Richard Heathfield <rjh@cpax.org.uk> - 2021-09-17 15:35 +0100
      Re: Triangulation Cryptography.- The Triangle model is Merely the Box That the Ciphertext Travels In' Max <maxturv26@gmx.net> - 2021-09-17 17:01 +0200
        Re: Triangulation Cryptography.- The Triangle model is Merely the Box That the Ciphertext Travels In' Rich <rich@example.invalid> - 2021-09-17 20:34 +0000
          Re: Triangulation Cryptography.- The Triangle model is Merely the Box That the Ciphertext Travels In' Max <maxturv26@gmx.net> - 2021-09-17 22:53 +0200

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

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.

[toc] | [next] | [standalone]

#49975

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

[toc] | [prev] | [next] | [standalone]

#49976

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.

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

[toc] | [prev] | [next] | [standalone]

#49995

Max <maxturv26@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.

[toc] | [prev] | [next] | [standalone]

#50001

On 17.09.21 22:34, Rich wrote:
> Max <maxturv26@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

[toc] | [prev] | [standalone]

Back to top | Article view | sci.crypt

csiph-web