ASLEC – Meaning and Methods.

133 views
Skip to first unread message

austin obyrne

unread,
Nov 12, 2021, 10:30:44 AM11/12/21
to
The most intelligent part of this algorithm is in finding the position
Vector of Alice’s spatial number. That is the transformation she
has made of a character into a point i.e. a displacement in space.
It may be uncovered by knowing and subtracting the change-of-origin
(key information) from the ciohertext in hand

Furthermore, that point is on a particular line in a particular plane in R^3 space.

Knowing how to track that point is crucial and it requires knowing
the plane that contains the position vector.

How that works.
It starts with knowing the vector that is called the defining normal
of the plane in question - call it ‘N’ for now. (key information). The plane passes through the origin (0, 0, 0)

That ‘normal’ is factorised into a primary pair called Vo and V1 (Veezero and Veeone - (uncovered key info))

Alice’s instaneous numberline passes thro’ those two points ( i.e.veezero and Veeone define the line ) and it is onto this line that Alice puts her number which is defined by Pn.

Pn is found in retrospect by removing the confusing change-of-origin (key information) from the ciphertext.

So now, knowing N, (key information) and Pn (Uncovered key information) , Veezero ( calculated key information) , decryption is performed on the model shown in my website at https://www.aslec.uk.

This is difficult to explain in words – I could do this in seconds by chalk ‘n talk on a blackboard.

Austin O’Byrne,




MM

unread,
Nov 12, 2021, 12:49:06 PM11/12/21
to
On Friday, 12 November 2021 at 15:30:44 UTC, austin obyrne wrote:
> This is difficult to explain in words – I could do this in seconds by
> chalk ‘n talk on a blackboard.

That bit is explained, /ad nauseam/. You may be confused by people
disagreeing with your opinion that this is secure, and you might need
to address that in isolation. Repeating yourself won't work.

Disagreement is not misunderstanding. There is a difference, and you
need to get used to it.

The bits you _don't_ explain are the questions that you are repeatedly
asked. There's a clue in that - answer the questions.

M
--

Chris M. Thomasson

unread,
Nov 12, 2021, 3:46:23 PM11/12/21
to
On 11/12/2021 7:30 AM, austin obyrne wrote:
> The most intelligent part of this algorithm is in finding the position
> Vector of Alice’s spatial number. That is the transformation she
> has made of a character into a point i.e. a displacement in space.
> It may be uncovered by knowing and subtracting the change-of-origin
> (key information) from the ciohertext in hand
[...]

For some reason, this is making me think of something very simple. Say a
3d vector storing 3 bytes, say:

42, 128, 255

change of origin = 3 * 123, 0, 4 * -12

Adding the two vectors together = 411, 128, 207

To get back to the original subtract change of origin, and we get:

42, 128, 255

I have to be missing something! It better not be that simple...

;^o


Rich

unread,
Nov 13, 2021, 12:13:20 AM11/13/21
to
Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
> On 11/12/2021 7:30 AM, austin obyrne wrote:
>> The most intelligent part of this algorithm is in finding the position
>> Vector of Alice?s spatial number. That is the transformation she
>> has made of a character into a point i.e. a displacement in space.
>> It may be uncovered by knowing and subtracting the change-of-origin
>> (key information) from the ciohertext in hand
> [...]
>
> For some reason, this is making me think of something very simple. Say a
> 3d vector storing 3 bytes, say:
>
> 42, 128, 255
>
> change of origin = 3 * 123, 0, 4 * -12
>
> Adding the two vectors together = 411, 128, 207
>
> To get back to the original subtract change of origin, and we get:
>
> 42, 128, 255
>
> I have to be missing something! It better not be that simple...
>
> ;^o

To the extent that the author has coherently explained anything, it
certianly looks that simple.

Encryption appears to be (<+> == "tuple add" and <-> == "tuple
subtract", Coo = "change of origin value"):

C = P(as a tuple) <+> Coo

And decrypt appears to be:

P(as a tuple) = C <-> Coo

So we have a one to one map (P(ascii) to P(tuple)) followed by a
linear addition for encrypt, and the reverse (linear subtraction
followed by mapping P(tuple) back to P(ascii) for decrypt.

The questions, so far unanswered, are whether Coo is a constant or not,
and if it is a constant, over what timeframe is it constant. And if
not a constant, then how/when does it change, and are the changes
cyclic?

wizzofozz

unread,
Nov 13, 2021, 3:16:39 AM11/13/21
to
Op 13-11-2021 om 06:13 schreef Rich:
> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>>
>> I have to be missing something! It better not be that simple...
>>>
> To the extent that the author has coherently explained anything, it
> certianly looks that simple.
>

It is slightly different from what both of you propose, but not much.
I posted some python code in the "vector math" thread, recently. It
generates the same numbers as shown on Austins bitmap example run (as
far as the 'factoring' and 'numberline' goes. I don't have all the
keymaterial).

I found the pdf's on the website, and the sourcecode pdf and example
bitmap Austin posted recently, helpful to read.

Ozz


MM

unread,
Nov 13, 2021, 4:57:55 AM11/13/21
to
On Saturday, 13 November 2021 at 05:13:20 UTC, Rich wrote:
> To the extent that the author has coherently explained anything, it
> certianly looks that simple.

The most cogent explanations are in the documents currently
on his website. They only tell a tiny part of the story, though, and
they contradict his narrative here.

> Encryption appears to be (<+> == "tuple add" and <-> == "tuple
> subtract", Coo = "change of origin value"):
>
> C = P(as a tuple) <+> Coo
>
> And decrypt appears to be:
>
> P(as a tuple) = C <-> Coo

No - Wizz has it about as correct (as it will get without further
details) in the "vector math" thread.

AOB is adamant that his vectors are the same as the ones used
in physics, i.e. real-valued. His algorithm is explicitly integer with
GCD() usage central and a need to search for an integer solution
to one variable. How the real-valued algorithm is supposed to work
is a total mystery.

> The questions, so far unanswered, are whether Coo is a constant or not,
> and if it is a constant, over what timeframe is it constant. And if
> not a constant, then how/when does it change, and are the changes
> cyclic?

There are three sets of numbers baked into the code, I, J, K, each being
a list of 14500 numbers. Why 14500, I have no idea. These numbers
were created something like 15 years ago, and it would appear that
changing them is sacrilege. AOB then uses his weak "scrambling"
algorithm[*] to create II from I, JJ, from J and KK from K. Coo would then
appear to be (A, B, C) where A, B, C are picked from (I, II, J, JJ, K, KK)
as part of the keying process. This requires changing the source.
Coo cycles through all 14500 triples thus created.

[*] the "scrambling" has three parameters:
1: offset - where to start.
2: length - a sublist length that will be reversed
3: repeat - how many times the above reversals will be applied.

With AOB's algorithm, offset + length*repeat must be less than 14500,
(I get about 10^9 choices) making searching all possibilities practical.

The possible permutations of the list is 14500! with a proper shuffle.
This is about 1.111274225*10^54045 permutations.

M
--

Max

unread,
Nov 13, 2021, 1:03:50 PM11/13/21
to
Does this mean that all the encryption of ASLEC is done by those
(scalar) scrambling operations and the vector math is merely used for
the (cryptographically irrelevant) encoding?

austin obyrne

unread,
Nov 13, 2021, 1:38:23 PM11/13/21
to
Hi max ,

No - Its the sum of several things.
The geometry of planes, the
perpendicular property of the Vector Cross product.
My invention of vector factorising as a new method
in vector methods. I have to say this as a matter of fact (not vanity),
The killer part is that these variables are all interdependent.


MM hasn't mentioned these latter because he just didn't get that far
although he outlined the enormity of the the very first obstacle
and intimated it could be made even stronger.

I value his remarks.
His summing up was acurate.

Best wishes.
AOB

austin obyrne

unread,
Nov 13, 2021, 1:55:56 PM11/13/21
to
On Saturday, 13 November 2021 at 18:03:50 UTC, Max wrote:
HI again Max,
The very first step is daunting, Eve has to partition
each of the groups of three 7-digit integers into another
pair of groups of seven-digits akso one of which must be
the correct operand of a Cross Product that immediately follows.

AOB

austin obyrne

unread,
Nov 13, 2021, 2:16:03 PM11/13/21
to
Correction:

They do not need to be seven-digits after the
partitioning and one will be something much less than that.

AOB

austin obyrne

unread,
Nov 13, 2021, 2:27:03 PM11/13/21
to
On Saturday, 13 November 2021 at 18:03:50 UTC, Max wrote:
Hi Max,

Further to other posts
Up tp now I have been totally honest but in practise
the entities may do some naughty tricks like Alice
by agreement with Bob takes the very first single
integer and places it last. The entire sequence is
disordered by doing this very easy ploy.

AOB

MM

unread,
Nov 13, 2021, 2:37:54 PM11/13/21
to
On Saturday, 13 November 2021 at 18:38:23 UTC, austin obyrne wrote:
> MM hasn't mentioned these latter because he just didn't get that far
> although he outlined the enormity of the the very first obstacle
> and intimated it could be made even stronger.

I showed you how to start years ago, and you got nowhere. Should
you do this, ie properly shuffle the the arrays used to construct the
Change-of-origin offsets, you would need a Fisher-Yates shuffle to
replace your scrambling, a PRNG that generated a cycle length
exceeding 14500! and three seed values, one for each dimension.

This could probably be done, but the PRNG would be a huge research
project in its own right. Each of the seed values would be numbers
50000+ digits long. Should you get this right, vector factoring would
be irrelevant, as the COO would likely be the most secure non-OTP
cipher ever produced, as well as the most expensive.

50000-digit numbers are not practical, so smaller possibilities
must be accepted.

> I value his remarks.
> His summing up was acurate.

So you accept that the COO can be brute-forced in practical time?
Because that is what I said.

M
--


MM

unread,
Nov 13, 2021, 2:46:50 PM11/13/21
to
On Friday, 12 November 2021 at 15:30:44 UTC, austin obyrne wrote:
> This is difficult to explain in words – I could do this in seconds by chalk ‘n talk on a blackboard.

Please just explain a bit; After the cross-product, you add the
change-of-origin.

Is the vector-factoring par not strong enough to stand on its own?
You imply as much, but never give a reason as to why the COO
is then necessary. That seems like an afterthought and not part
of the central idea.

M
--

MM

unread,
Nov 13, 2021, 2:48:29 PM11/13/21
to
On Saturday, 13 November 2021 at 19:27:03 UTC, austin obyrne wrote:
> Further to other posts
> Up tp now I have been totally honest but in practise
> the entities may do some naughty tricks ...

Is your challenge honest like you said it was?

M
--

austin obyrne

unread,
Nov 14, 2021, 2:36:02 AM11/14/21
to
absolutely.

austin obyrne

unread,
Nov 14, 2021, 2:39:32 AM11/14/21
to
No way

Richard Heathfield

unread,
Nov 14, 2021, 2:41:48 AM11/14/21
to
As Mandy Rice-Davies very nearly said: "Well he would say that, wouldn't
he?"

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

MM

unread,
Nov 14, 2021, 4:00:20 AM11/14/21
to
> No way

Read your own words. "His summing up was acurate" vs "No Way".

No wonder people don't understand you when you contradict yourself
like this!

M
--

MM

unread,
Nov 14, 2021, 4:05:57 AM11/14/21
to
> absolutely.

Oh, yeah? Or is this another one of your "strategic lies"?

So far, you've either lied about this being an honest challenge,
or you've cast doubt on your own challenge by suggesting that
"the entities may do some naughty tricks ..."

This kind of dishonesty doesn't do you any favours. If you need
to cheat, your cipher can't be worth all that much.

M
--

austin obyrne

unread,
Nov 14, 2021, 4:17:27 AM11/14/21
to
There are no lies whatever - Preparing your excuses ?

Richard Heathfield

unread,
Nov 14, 2021, 4:19:18 AM11/14/21
to
It's security by obscurity. The trouble with that idea is that Eve is
much better at cheating. For example, in WW2 the Bletchley Park crew
sometimes indulged in what they called "gardening", in which they asked
for the armed forces to conduct operations that they knew would be
called in by German observers. BP could then make a reasonable guess at
the plaintext of the message and from that determine the day key (or, in
ASLEC's case, the decade key).

Richard Heathfield

unread,
Nov 14, 2021, 4:34:03 AM11/14/21
to
Well, you would say that, wouldn't you?

> - Preparing your excuses ?

I'll give you my excuses right now if you like:

1) along with several other people here, I've already broken vector
cryptography, and it hasn't changed significantly since it was broken,
so what's the point?

2) VC doesn't exist (no implementation since you removed the Ada code
from your Web site; nor even a coherent description of the algorithm),
so there is nothing to break.

3) from what we have been able to glean about it, it's a ridiculous
cipher - 420KB key required for every single message no matter how
short; key hardwired into source code; can't encrypt files containing
byte values 0-31 or 127-255 i.e. most files. So again, why bother
cracking it, since it is of no practical value and will never be used?

Now, what are *your* excuses for wasting everyone's time with all this BS?

MM

unread,
Nov 14, 2021, 4:54:07 AM11/14/21
to
On Sunday, 14 November 2021 at 09:17:27 UTC, austin obyrne wrote:
> There are no lies whatever - Preparing your excuses ?

I don't have a cipher to defend, you do. Your move. So far, you
are choosing dishonesty, which makes your cipher dubious.

So yes, I have an excuse. There is no need to attack a cipher that
is being defended by dishonesty and not by its merits.

M
--

wizzofozz

unread,
Nov 14, 2021, 4:56:41 AM11/14/21
to
Op 14-11-2021 om 10:05 schreef MM:
> On Sunday, 14 November 2021 at 07:36:02 UTC, austin obyrne wrote:
>> On Saturday, 13 November 2021 at 19:48:29 UTC, MM wrote:
>>> On Saturday, 13 November 2021 at 19:27:03 UTC, austin obyrne wrote:
>>>> Further to other posts
>>>> Up tp now I have been totally honest but in practise
>>>> the entities may do some naughty tricks ...
>>>
>>> Is your challenge honest like you said it was?
>>
>> absolutely.
>
> Oh, yeah? Or is this another one of your "strategic lies"?
>
> So far, you've either lied about this being an honest challenge,
> or you've cast doubt on your own challenge by suggesting that
> "the entities may do some naughty tricks ..."
>

I don't think he cheated. If you compare the first 9 triples from the
challenge to the demonstration bitmap, you'll find that most likely the
same keys were used resulting in similar ciphertext (that would not be
the case if he put the first digit last, or something like that).
I think you would even be able to decrypt the first 9 challenge bytes,
if it wasn't for Alice's 'renumbering' of the ASCII values in one of the
first steps (see demo bitmap). That seems to be some initial 'random'
substitution.

My guess is that the first challenge renumbered byte is 138 (=130+8).
But how that maps back to the ASCII value I don't know.

Ozz


MM

unread,
Nov 14, 2021, 5:57:54 AM11/14/21
to
On Sunday, 14 November 2021 at 09:56:41 UTC, wizzofozz wrote:
> I don't think he cheated. If you compare the first 9 triples from the
> challenge to the demonstration bitmap, you'll find that most likely the
> same keys were used resulting in similar ciphertext (that would not be
> the case if he put the first digit last, or something like that).

That doesn't mean much. His crappy scrambling could be surreptitiously
changed elsewhere.

> I think you would even be able to decrypt the first 9 challenge bytes,
> if it wasn't for Alice's 'renumbering' of the ASCII values in one of the
> first steps (see demo bitmap). That seems to be some initial 'random'
> substitution.

Maybe. In a past break, I reused a published keystream, and only a few
letters failed. His bad scrambling is used in a few places and doesn't
avalanche.

> My guess is that the first challenge renumbered byte is 138 (=130+8).
> But how that maps back to the ASCII value I don't know.

Look at the example Ada, and look for the "Decrypt" procedure. This
is unused in this program, and likely used in the decryption program
(not supplied).

Its a monoalphabetic substitution based on more baked-in constants,
this time in the Number() array. He removed this years ago, and it
seems it's back. It's completely undocumented.

it adds complexity and no security.

M
--

MM

unread,
Nov 14, 2021, 6:13:59 AM11/14/21
to
On Sunday, 14 November 2021 at 10:57:54 UTC, MM wrote:
> Its a monoalphabetic substitution based on more baked-in constants,
> this time in the Number() array. He removed this years ago, and it
> seems it's back. It's completely undocumented.

Yup. I have a copy of ASLEC from 2018 that has this. It's pointless.

M
--

Richard Heathfield

unread,
Nov 14, 2021, 6:27:36 AM11/14/21
to
Yet another "excuse" to add to the list: violation of Kerckhoffs's
Principle.

What is really needed if another break is to take place is an excuse to
bother wasting any more time on this ridiculous system.

MM

unread,
Nov 14, 2021, 6:42:11 AM11/14/21
to
On Sunday, 14 November 2021 at 11:27:36 UTC, Richard Heathfield wrote:
> What is really needed if another break is to take place is an excuse to
> bother wasting any more time on this ridiculous system.

The central "vector factoring" bit is moderately interesting and could be
made pretty darn strong, from the PoV of armchair cryptanalysis maybe.
There are some potential diophantine problems in there that could be
brought to bear (but I am not a number theorist).

Its main enemy is its author, who won't accept criticism of any variety,
let alone constructive.

AOB, if you are still reading this, try spending some time addressing
problems instead of self-promoting. After all, the only person here who
has an interest in your cipher succeeding is you.

Start by removing as much extraneous material as you can, and by
concentrating on the core cipher. Get coding help if you need it. You say
that the vector factoring cipher is unbreakable? Prove it by showing
that it can stand on its own. All the other crap only shows a lack of
confidence it. If you aren't confident, why should anyone else be?

M
--

austin obyrne

unread,
Nov 14, 2021, 12:30:08 PM11/14/21
to
Note: The 'other crap' as you call it is where it gets is intractability.
You still don't get the fallout geometry - you believe its all just linear
algebra and it will have a method of numerical reduction in it
somewhere in it (there for the finding):
N0.
AOB

MM

unread,
Nov 14, 2021, 1:25:12 PM11/14/21
to
On Sunday, 14 November 2021 at 17:30:08 UTC, austin obyrne wrote:
> Note: The 'other crap' as you call it is where it gets is intractability.

Oh? Really? You keep saying that the vector crypto/factoring is
unbreakable, with no mention of anything else required for this
"intractability".

You also waffle on about the change-of-origin stuff, also claiming
unbreakability.

You don't say why you need both. You don't even explain the point
of the monoalphabetic first step.

"Intractability" is not a reason unless you can show the maths to
back it up. What you've posted online never gets anywhere near
an intractability argument, it just shows you can do high-school
vector algebra and eventually get it mostly right - with the
intractability left as a leap-of-faith claim at the end. Arguments
involving "infinite vector space" just collapse when you use
integer-only numbers on a VERY finite computer.

Your example program at aslec.uk is about triple (or more) the
length it could be if you removed useless code. There are at least
three SIGNIFICANT bugs, all of which are useful to Eve.

> You still don't get the fallout geometry

I get it just fine. It's the reduced form of a tachyon matrix.

> - you believe its all just linear
> algebra and it will have a method of numerical reduction in it
> somewhere in it (there for the finding):

Nope. Not at all. Not even close. You haven't been listening.

M
--
Reply all
Reply to author
Forward
0 new messages