ASLEC Cipher - The Key to the Key.

75 views
Skip to first unread message

austin obyrne

unread,
Nov 6, 2021, 12:26:35 PM11/6/21
to
I am planning a new encryption scheme that aims at preventing
the Change–of–Origin key becoming ineffective through over-exposure.

I am planning to create a key generator by having the entities’
encrypt an agreed trivial sample passage using the current
change-of-origin key and then swopping the resultant ciphertext
string as the new Change–of-Origin key in the next encryption.

I think the entities could in fact have a whole library of specimen
passages to use in this way to use as often as Alice desires.

Just a thought – can be done.

Austin O'Byrne

Rich

unread,
Nov 6, 2021, 12:59:51 PM11/6/21
to
austin obyrne <ao40...@gmail.com> wrote:
> encrypt an agreed trivial sample passage using the current
> change-of-origin key and then swopping the resultant ciphertext
> string as the new Change?of-Origin key in the next encryption.

Hmm, so the ciphertext, which is in full view to Eve, becomes the new
key?

What prevents Eve from observing the same ciphertext exchange, and also
using the ciphertext as a new change-of-origin key in her copy of the
Ada code?

austin obyrne

unread,
Nov 6, 2021, 1:11:10 PM11/6/21
to
Come to think of it why bother considering over exposure
of the existing change-of-origin string at all and just go ahead
and adopt this idea of using a new Change-of-Origin key for
each and every encryption of a message.

The coding of this new ploy in ASLEC should be fairly easy.

My mantra has always been 'security at any cost'. I don't
see this new ploy as being a prohibiting extra cost in any case.

AOB

austin obyrne

unread,
Nov 6, 2021, 1:13:55 PM11/6/21
to
You got a point there judge.

austin obyrne

unread,
Nov 6, 2021, 1:57:34 PM11/6/21
to
On Saturday, 6 November 2021 at 16:59:51 UTC, Rich wrote:
So Eve has the ciphertext at some instant. Essentially she can;t decrpt it.,

Next Message:

Alice takes this cipheretxt abd uses it as the key to encrypt a fake message.
She then takes the ciphertext of this fake messge and uses it as
the genuine Change-of-Origin key in the next real meessage.

The ensuing ciphertext is totally transformed from the previuous
one and has been made more secure by the transfprmation and
swap over to the new role of key in a real message by means of
the fake out-of-sight encryption . - I'm sure you can think it through.

AOB

Rich

unread,
Nov 6, 2021, 2:18:52 PM11/6/21
to
austin obyrne <ao40...@gmail.com> wrote:
> On Saturday, 6 November 2021 at 16:59:51 UTC, Rich wrote:
>> austin obyrne <ao40...@gmail.com> wrote:
>> > encrypt an agreed trivial sample passage using the current
>> > change-of-origin key and then swopping the resultant ciphertext
>> > string as the new Change?of-Origin key in the next encryption.
>>
>> Hmm, so the ciphertext, which is in full view to Eve, becomes the new
>> key?
>>
>> What prevents Eve from observing the same ciphertext exchange, and also
>> using the ciphertext as a new change-of-origin key in her copy of the
>> Ada code?
>
> So Eve has the ciphertext at some instant. Essentially she can;t decrpt it.,
>
> Next Message:
>
> Alice takes this cipheretxt abd uses it as the key to encrypt a fake message.
> She then takes the ciphertext of this fake messge and uses it as
> the genuine Change-of-Origin key in the next real meessage.

How does Bob get this new "Change-of-Origin" key so he can decrypt the
next real message?

austin obyrne

unread,
Nov 6, 2021, 2:22:41 PM11/6/21
to
On Saturday, 6 November 2021 at 16:59:51 UTC, Rich wrote:
Eve doesn;t know the fake message that Alice encrypts for no other reason than to
gain a new key ( i. e' she will use this new key (Change -of-Origin) to encrypt the next message.

AOB

Rich

unread,
Nov 6, 2021, 2:33:46 PM11/6/21
to
If the ciphertext *is* the new key (you said "swopping [sic] the
resultant ciphertext string as the new Change?of-Origin key" --
indicating that the ciphertext *is* the new key), then Eve does not
need to know what message was encrypted. The ciphertext itself *is*
the new key (at least to the extent you have revealed the details of
your plan to us here so far).

austin obyrne

unread,
Nov 6, 2021, 3:11:08 PM11/6/21
to
There's a fake mesage encrypted iby Alice n the meantime using the last ciphertext i.e. the one that eve knows as the key.

That visible ciphertext is now used as the key of a fake message by Akice. It's the cipheretxt from this fake encryption
that becomes the invisible key of the next real message ... and so on

Ciphertext in hand => key of a fake encryption => ciphertext from fake => key of the next genuine message -and so on and on.

All that is needed is knowledge of the fake messages by the entities. (the other cipher key information remains unchanged).

AOB

austin obyrne

unread,
Nov 6, 2021, 3:26:28 PM11/6/21
to
I haven't done any work on this yet - I think it puts the lid more firmly on all hopes
of numerical analysis methods for adversaries albeit that was already
the case in Vector Cryptography anyway.

AOB

Chris M. Thomasson

unread,
Nov 6, 2021, 4:14:02 PM11/6/21
to
Another thought... Please, oh please, try to separate the secret key
from your source code. Keep the key, in a file... Have your code just
load it up, and initialize everything, then perform an encrypt and/or
decrypt.

Chris M. Thomasson

unread,
Nov 6, 2021, 4:20:13 PM11/6/21
to
Eve records everything. Nothing is fake to her as she is collecting
data. You think may think its "fake", however, to her its valid data and
shall me analyzed.

Chris M. Thomasson

unread,
Nov 6, 2021, 4:21:16 PM11/6/21
to
On 11/6/2021 10:11 AM, austin obyrne wrote:
> On Saturday, 6 November 2021 at 16:26:35 UTC, austin obyrne wrote:
>> I am planning a new encryption scheme that aims at preventing
>> the Change–of–Origin key becoming ineffective through over-exposure.
>>
>> I am planning to create a key generator by having the entities’
>> encrypt an agreed trivial sample passage using the current
>> change-of-origin key and then swopping the resultant ciphertext
>> string as the new Change–of-Origin key in the next encryption.
>>
>> I think the entities could in fact have a whole library of specimen
>> passages to use in this way to use as often as Alice desires.
>>
>> Just a thought – can be done.
>>
>> Austin O'Byrne
>
> Come to think of it why bother considering over exposure
> of the existing change-of-origin string at all and just go ahead
> and adopt this idea of using a new Change-of-Origin key for
> each and every encryption of a message.
>
> The coding of this new ploy in ASLEC should be fairly easy.

Where is the old ploy?

>
> My mantra has always been 'security at any cost'. I don't
> see this new ploy as being a prohibiting extra cost in any case.
[..]

austin obyrne

unread,
Nov 6, 2021, 4:56:28 PM11/6/21
to
About to be published later - Much to do these days.

Aob

Colin

unread,
Nov 6, 2021, 4:58:15 PM11/6/21
to
It doesn't fit, your 14250 size limit.
Your change of origin is at least six times this amount.

Colin

unread,
Nov 6, 2021, 6:09:55 PM11/6/21
to
What happens when the next message is longer than the previous?

austin obyrne

unread,
Nov 7, 2021, 4:49:47 AM11/7/21
to
Let Count = length of previous message,
then,
While encryptimg fake message (always 14250 long)
If Total = Count -1 say
Then Count = 1 again.
The reset point of Count is effectively
hidden by the several other variables.

Has always worked for me before.
thanks.

AOB

Unknown

unread,
Nov 7, 2021, 5:09:33 AM11/7/21
to

>> >
>> What happens when the next message is longer than the previous?
>
>Let Count = length of previous message,
>then,
>While encryptimg fake message (always 14250 long)
>If Total = Count -1 say
>Then Count = 1 again.
>The reset point of Count is effectively
>hidden by the several other variables.
>
>Has always worked for me before.
> thanks.
>
>AOB

So Eve knows messages 14250 long have high probably of being fake.
Or do you need some fake fake messages as well?


austin obyrne

unread,
Nov 7, 2021, 5:59:58 AM11/7/21
to
No - the fake messages don't go anywhere.
The ciphertext of the fake message is used as the
key to the bona fide message that immediately follows.

Thanks .

AOB

MM

unread,
Nov 7, 2021, 7:03:03 AM11/7/21
to
On Sunday, 7 November 2021 at 10:59:58 UTC, austin obyrne wrote:
> > So Eve knows messages 14250 long have high probably of being fake.
> > Or do you need some fake fake messages as well?
> No - the fake messages don't go anywhere.
> The ciphertext of the fake message is used as the
> key to the bona fide message that immediately follows.

How does Bob get this key?

M
--

Unknown

unread,
Nov 7, 2021, 7:11:14 AM11/7/21
to
I don't believe that you are really that dumb. You must be just trolling.

Richard Heathfield

unread,
Nov 7, 2021, 7:27:43 AM11/7/21
to
Or to be fair, maybe he's just thinking out loud. He wouldn't be the
first to bounce ideas off Usenet to see which ones die horribly in flames.

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

unread,
Nov 7, 2021, 8:49:55 AM11/7/21
to
Then how does Bob get the "ciphertext of the fake message" from Alice
in order to reset his key so that he can decrypt "the bona fide message
that immediately follows"?

MM

unread,
Nov 7, 2021, 8:50:12 AM11/7/21
to
On Sunday, 7 November 2021 at 12:27:43 UTC, Richard Heathfield wrote:
> Or to be fair, maybe he's just thinking out loud. He wouldn't be the
> first to bounce ideas off Usenet to see which ones die horribly in flames.

Nothing wrong with that.

We all have our "back to the drawing board" moments.

I just wish he'd do more of it, rather than treating folks like trash.

M
--

Richard Heathfield

unread,
Nov 7, 2021, 9:04:59 AM11/7/21
to
Presumably Bob has his own copy of these fake messages... in which case
why not just fill the pages of that same book with keys? This is
becoming more and more like a one time pad, isn't it? In which case, why
bother with vectors? The whole point of *not* using a one time pad is to
escape the problem of vast quantities of key material. And 14250 lines
of key is pretty vast to start with, and now AOB is proposing *multiple*
keys of that size.

Rich

unread,
Nov 7, 2021, 10:02:48 AM11/7/21
to
Richard Heathfield <r...@cpax.org.uk> wrote:
> On 07/11/2021 13:49, Rich wrote:
>> austin obyrne <ao40...@gmail.com> wrote:
>>> On Sunday, 7 November 2021 at 10:09:33 UTC, undefined wrote:
>>>>>>>
>>>>>> What happens when the next message is longer than the previous?
>>>>>
>>>>> Let Count = length of previous message,
>>>>> then,
>>>>> While encryptimg fake message (always 14250 long)
>>>>> If Total = Count -1 say
>>>>> Then Count = 1 again.
>>>>> The reset point of Count is effectively
>>>>> hidden by the several other variables.
>>>>>
>>>>> Has always worked for me before.
>>>>> thanks.
>>>>>
>>>>> AOB
>>>> So Eve knows messages 14250 long have high probably of being fake.
>>>> Or do you need some fake fake messages as well?
>>>
>>> No - the fake messages don't go anywhere.
>>> The ciphertext of the fake message is used as the
>>> key to the bona fide message that immediately follows.
>>
>> Then how does Bob get the "ciphertext of the fake message" from Alice
>> in order to reset his key so that he can decrypt "the bona fide message
>> that immediately follows"?
>
> Presumably Bob has his own copy of these fake messages...

That is a reasonable presumption, and one I expected to hear back from
Austin, but in both our cases, it is an "assumption" given that Austin
has not elaborated on what is in his head on this particular point.

> in which case why not just fill the pages of that same book with
> keys?

Indeed. No need for a stack of "fake message" files when a stack of
"real key" files would suffice just as well. Bob still needs copies of
them all to keep up.

> This is becoming more and more like a one time pad, isn't it?

Well, I think I'd postulate that this is inheriting all the "troubles"
surrounding use of a OTP, rather than it is "becoming" an OTP. ASLEC
won't ever be an OTP from the guaranteed security standpoint of an
OTP. But it sure is growing all the surrounding "management" troubles
that arise from trying to use a OTP.

> In which case, why bother with vectors?

Yep. Given that most all that's ever done is some simple scalar
additions, some fixed mapping substitutions, and some simple scalar
subtractions, calling it "vector" anything is a massive stretch.

> The whole point of *not* using a one time pad is to escape the
> problem of vast quantities of key material. And 14250 lines of key
> is pretty vast to start with, and now AOB is proposing *multiple*
> keys of that size.

And, if you guess a reasonable media of 35 bytes per line you get a
"keyfile" size estimate of 498750 bytes (487 KiB). That is indeed
huge. So we get all the OTP management troubles of handling/exchanging
487KiB keys, without the guaranteed security that comes from using a
true OTP.

Or, we use AES-128, 192, or 256 and we only need a 128, 192, or 256
*bit* key (for Austin's sake: 16 characters, 24 characters, or 32
characters). Alice and Bob will have a much easier time rekeying when
they only need to exchange, at most, 32 characters vs. 498750
characters.

Sir Eyus Trifle

unread,
Nov 10, 2021, 8:49:53 PM11/10/21
to
On Sun, 7 Nov 2021 02:59:56 -0800 (PST), austin obyrne
<ao40...@gmail.com> wrote:

>On Sunday, 7 November 2021 at 10:09:33 UTC, undefined wrote:
>> >> >
>> >> What happens when the next message is longer than the previous?
>> >
>> >Let Count = length of previous message,
>> >then,
>> >While encryptimg fake message (always 14250 long)
>> >If Total = Count -1 say
>> >Then Count = 1 again.
>> >The reset point of Count is effectively
>> >hidden by the several other variables.
>> >
>> >Has always worked for me before.
>> > thanks.
>> >
>> >AOB
>> So Eve knows messages 14250 long have high probably of being fake.
>> Or do you need some fake fake messages as well?
>
>No - the fake messages don't go anywhere.

So how do the thousands of agents in the field, including double
agents employed by Eve but really working for Alice, get this new key?
How do they get it without them being "outed" to Eve?

How does Alice transmit the "fake" key to all of those thousands of
agents securely?

And don't say "trusted courier". If you have one of those there is no
need for *any* encryption, messages can be sent in plain text. Also,
Eve could subvert *any* courier by simply buying the company; or by
just following them.

>The ciphertext of the fake message is used as the
> key to the bona fide message that immediately follows.

Yes, but to decrypt this new message, all of the thousands of Bobs
need the "fake" key. A key is a key, fake or not. Unless you have told
all of Alice's agents, double or not, what the key is they will be
faced with the same task as is Eve, decrypting a message by way of
cryptanalysis.

Incidentally, this "secure channel" question arises for *EVERY* first
use of all of your little ciphers. How does Alice transmit the very
first "mutual database" to Bobs who are under deep cover in enemy
territory?

No, sending a CDROM in a package labeled "Secret Key From Alice For
Her Spies: Never To Be Opened By Eve!!" is *not* a smart idea no
matter how much idiot Alice trusts the couriers.

KT.

>
>Thanks .
>
>AOB

Sir Eyus Trifle

unread,
Nov 10, 2021, 8:55:25 PM11/10/21
to
On Sun, 7 Nov 2021 04:03:01 -0800 (PST), MM <mrvm...@gmail.com>
wrote:
"Secure couriers", which, considering that "Bob" may be a deep
undercover spy working in Eve's gang but secretly spying for Alice who
is getting regular mail from Alice labeled "Secret Key From Spymaster
Alice, Not To Be Opened By Eve Because It's A Secret!!!!" is not
really conducive to "Bob's" longevity.

AOB still has not ever even *tried* to work out how PGP, HTTPS or
anything else does the initial handshaking. He hasn't even *asked*.

I suspect that his idea of "coding" is stuck in visions from 1960's
"James Bond" and computer hacker movies and that he is too old to move
on from there.

KT.

>
>M

Sir Eyus Trifle

unread,
Nov 10, 2021, 9:13:00 PM11/10/21
to
On Sun, 7 Nov 2021 15:02:45 -0000 (UTC), Rich <ri...@example.invalid>
wrote:
A random thought: Could AOB incorporate the use of some Number
Stations into his ASLEC for transmission of the "Mutual Databases" and
other keys?

Granted, it would take a while for Alice to sound-chip thousands of
498750-character keys for her thousands of agents across the globe but
as Eve would never know which stations belong to Alice it may be a
useful strategy; Alice could even buy up thousands of bogus stations
that transmitted bogus keys much of the time as misdirection.

Of course, all of the Bobs would need telling but that could be
simply by using their agency codenames as frequency markers.

Hmmm ...... I see lots of issues with this one but it could make a
simplistic ploy for a spy-movie. :)

KT.
Reply all
Reply to author
Forward
0 new messages