Reader Asked - Sample of Change_of_Origin file.

[austin obyrne]

A reader asked "Is the change_of_Origin a constant"

No there are 6 files each containing 0 to 14250 elements

Herewith a sample of one of them.


WITH Ada.Text_IO;
PACKAGE BODY Change_of_Origin_I_Coefficients IS
------------------------------------------------------------------------
--| Contains the body of the function "Get_Num" that is provided
--| by the package called "Change_of_Origin_I_Coefficients".
--| Copyright © 2003 Austin O' Byrne
--| Last Modified October 2011
-------------------------------------------------------------------------
FUNCTION GetNum (NumIn: Integer) RETURN Integer IS
CharOut: Integer;

BEGIN
CASE NumIn IS

-- When 000
WHEN 000 => CharOut:= 8514442;
WHEN 001 => CharOut:= 6514449;
WHEN 002 => CharOut:= 9814466;
WHEN 003 => CharOut:= 4714447;
WHEN 004 => CharOut:= 6514459;
WHEN 005 => CharOut:= 5814445;
WHEN 006 => CharOut:= 8214457;
WHEN 007 => CharOut:= 9414452;
WHEN 008 => CharOut:= 7614461;
WHEN 009 => CharOut:= 8114464;
----------------------------------------------
--------------------------------------------
When 14240
WHEN 14240 => CharOut:= 9817525;
WHEN 14241 => CharOut:= 5426946;
WHEN 14242 => CharOut:= 6526939;
WHEN 14243 => CharOut:= 4726940;
WHEN 14244 => CharOut:= 9526941;
WHEN 14245 => CharOut:= 5726942;
WHEN 14246 => CharOut:= 5426943;
WHEN 14247 => CharOut:= 8426944;
WHEN 14248 => CharOut:= 5426947;
WHEN 14249 => CharOut:= 6226945;
WHEN 14250 => CharOut:= 7328690;

WHEN OTHERS =>
Ada.Text_IO. Put (Item => "Forget this one - out of bounds ");
END CASE;
RETURN CharOut;
END GetNum;
END Change_of_Origin_I_Coefficients; 19 => CharOut:= 5714458;

14250 all told

Austin O'Byrne

[Richard Heathfield]

On 05/11/2021 10:17, austin obyrne wrote:
> A reader asked "Is the change_of_Origin a constant"
>
> No there are 6 files each containing 0 to 14250 elements
>
> Herewith a sample of one of them.
>
>
> WITH Ada.Text_IO;
> PACKAGE BODY Change_of_Origin_I_Coefficients IS
> ------------------------------------------------------------------------
> --| Contains the body of the function "Get_Num" that is provided
> --| by the package called "Change_of_Origin_I_Coefficients".
> --| Copyright © 2003 Austin O' Byrne
> --| Last Modified October 2011
> -------------------------------------------------------------------------
> FUNCTION GetNum (NumIn: Integer) RETURN Integer IS
> CharOut: Integer;
>
> BEGIN
> CASE NumIn IS
>
> -- When 000
> WHEN 000 => CharOut:= 8514442;
> WHEN 001 => CharOut:= 6514449;
> WHEN 002 => CharOut:= 9814466;

Bloody hell, Austin! Look up "array", why don't you?

https://learn.adacore.com/courses/intro-to-ada/chapters/arrays.html

Then you can write:

RETURN Coefficient(NumIn);

Next you can stick your 14250 numbers in a file, read them into the
array as part of initialisation (a short loop will do it), and reduce
your code by well over 14,000 lines.

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

[austin obyrne]

Yes -that sounds good - but i don't want to change horses in mid stream
- I suggest you do that yourself- I have copyright for however far it will take
me on my cipher but I will forego that for regular readers of this group.
The invitation is to write your own program within sci.group but not
commercialise it for gain.

Have a good day

AOB

[Richard Heathfield]

> Yes -that sounds good - but i don't want to change horses in mid stream

If you cut 14,000 lines the water might go down enough that you don't
have to swim so much.

> - I suggest you do that yourself-

You think I don't? Clearly you didn't read the reference implementation
I posted the other day. Out of 764 lines of source, 46 either declare an
array or access an array element.

> I have copyright for however far it will take
> me on my cipher

Your IPR is safe. Nobody's gonna steal that shinola.

> but I will forego that for regular readers of this group.
> The invitation is to write your own program within sci.group but not
> commercialise it for gain.

It's incredible. I really think you mean it. Perhaps you missed all
those comments about your algorithm description being inadequate to use
for constructing an implementation.

[Richard Heathfield]

On 05/11/2021 11:16, Richard Heathfield wrote:
> On 05/11/2021 11:02, austin obyrne wrote:

<snip>

>
>> but I will forego that for regular readers of this group.
>> The invitation is to write your own program within sci.group but not
>> commercialise it for gain.
>
> It's incredible. I really think you mean it. Perhaps you missed all
> those comments about your algorithm description being inadequate to use
> for constructing an implementation.

Oh, one more thing. If you really want people to implement your
cryptosystem, telling folk to piss off when they ask you questions about
it might not be the best strategy.

[DaleT]

On Friday, November 5, 2021 at 5:17:07 AM UTC-5, austin obyrne wrote:
> A reader asked "Is the change_of_Origin a constant"
>
> No there are 6 files each containing 0 to 14250 elements
>

If this large array is going to be be public knowledge, rather than sending it securely
as part of a key, then why do it at all.

[austin obyrne]

It is not sent regukarly - it is sent once in a secure one-off delivery
of the entities' mutual database from Alice to Bob at the very outset of setting up the secure link..
After that they sybchronise their mutual database whenever Alice (alone) decides.

Thet do this by Alice sending scrambling parameters to Bob that are useless to Eve
should she intercept them not having any knowledge of the Entities' files to which
the scrambling parameters apply.
AOB

[DaleT]

That sounds like a ont-time-pad.....very secure...but not distributable.

[DaleT]

OOPS.....one time pad key must be random and never reused.

[Rich]

austin obyrne <ao40...@gmail.com> wrote:
> A reader asked "Is the change_of_Origin a constant"

I was that 'reader', thank you.

> No there are 6 files each containing 0 to 14250 elements
>
> Herewith a sample of one of them.
>

> ...

> FUNCTION GetNum (NumIn: Integer) RETURN Integer IS

How is the value of NumIn chosen for a given single encryption of a
message of 20 characters?

[Richard Heathfield]

On 05/11/2021 13:47, austin obyrne wrote:
> On Friday, 5 November 2021 at 12:36:03 UTC, DaleT wrote:
>> On Friday, November 5, 2021 at 5:17:07 AM UTC-5, austin obyrne wrote:
>>> A reader asked "Is the change_of_Origin a constant"
>>>
>>> No there are 6 files each containing 0 to 14250 elements
>>>
>> If this large array is going to be be public knowledge, rather than sending it securely
>> as part of a key, then why do it at all.
>
> It is not sent regukarly - it is sent once in a secure one-off delivery

That's fair enough. We'll give Alice and Bob one briefcase chained to
the wrist, because we all saw the movie (or 1970s news reports).

> of the entities' mutual database from Alice to Bob at the very outset of setting up the secure link..
> After that they sybchronise their mutual database whenever Alice (alone) decides.

This is where it gets wobbly.

> Thet do this by Alice sending scrambling parameters to Bob that are useless to Eve

Carry on thinking that, but Eve will disagree. She will collect them avidly.

> should she intercept them not having any knowledge of the Entities' files to which
> the scrambling parameters apply.

She will calculate their cumulative effect. Over time, a pattern will
emerge. She will also be careful to record which pattern is in effect at
the time any given ciphertext is intercepted.

For months, maybe, the accumulated scrambling parameters might yield no
fruit, but Eve will keep recording them, and one day out will pop
something that makes sense in two or three messages, and it will all
start to unravel. No, Austin, this is a crap way to change a large key.
It's a crap way to change a small key, but it's a disastrous way to
change a large key.

You like big numbers. Let's play a game. Imagine a key this big:

abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuv

256 bytes - almost ten alphabets. Five short lines of text.

How many bits? 256*8 is 2048.

How many keys for brute force? 2^2048 is
32317006071311007300714876688669951960444102669715484032130345427524\
65513886789089319720141152291346368871796092189801949411955915049092\
10950881523864482831206308773673009960917501977503896521067960576383\
84067568276792218642619756161838094338476170470581645852036305042887\
57589154106580860755239912393038552191433338966834242068497478656456\
94948561760353263220580778056593310261927084603141502585928641771167\
25943603718461857357598351152301645904403697613233287231227125684710\
82020972515710172693132346967854258065669793504599726835299863821552\
51663894373355436021354332296046453184786049521481935558536110595962\
30656

Imagine you could run one million tests per second on a single atom, and
that you have the whole universe at your disposal. 10^80 atoms, so 10^86
tests per second.

Time to exhaust the search space (seconds):
32317006071311007300714876688669951960444102669715484032130345427524\
65513886789089319720141152291346368871796092189801949411955915049092\
10950881523864482831206308773673009960917501977503896521067960576383\
84067568276792218642619756161838094338476170470581645852036305042887\
57589154106580860755239912393038552191433338966834242068497478656456\
94948561760353263220580778056593310261927084603141502585928641771167\
25943603718461857357598351152301645904403697613233287231227125684710\
8202097251571017269313234696785425806566979350459972683

The universe is 13.82e9 years old, or 4.3e15 seconds.

So to exhaust the search space of a 256 byte key at a million tests per
atom per second using every atom of the observable universe will take
74150907384900814204469870761419453182864869730382064978664829213916\
21882635564384093322379349269514620994553286102268047258594214172368\
25593027085266398118242530379157814451270773303860886345745125448672\
54063185997965935337492584593644050606249395335525498371549151010215\
17845302900057483187936164272138097638793757142353566999388837713728\
92993452456497614516359081814276689691204182340622966135614019443212\
90091097777537906182698951989772573114253311982761637519418520621898\
360639835587027012271559789704290772314 universe lifetimes, by which
time the news that the enemy will be attacking at dawn might be a touch
outdated.

Conclusion: nobody, but *nobody*, can possibly justify having a key
bigger than 256 bytes - less than you can write in five short lines of
text. Your key of 14,000 numbers (and that's just one of six files,
yes?) is stupendously and ridiculously large, and is a huge hostage to
fortune.

[Richard Heathfield]

No, it's not a one time pad, because Austin's key is re-used, and just
perturbed when Alice feels like it. She sends the perturbations to Bob,
and the rest of the key remains untouched. Is this not setting off all
your alarm bells?

[austin obyrne]

Numin is only used at boot-up time - lemme explain

The database is a series of several out-of-sight ' Case Statements'
Each one of these is loaded into a set of named arrays of the same size at boot-up.
.i.e. the arrays absorb the full contents of the case statement each time.

Numin directs the cell in the corresponding array into which each element will go in consecutive order.
(In passing and very importantly - NOTE WELL the elements of every case satement are
studiously *scrambled as they are loaded into each array).

The name ' Numin'. is not used again to call variables.

The variables are handy in ready use arrays now and the counter ' Total ' is used to call
each varaiable along with the name of the array when a particular one is is required.
-
I hope this answers your question but come back by all means if not.

Good question !

AOB

[Rich]

Richard Heathfield <r...@cpax.org.uk> wrote:
> On 05/11/2021 14:01, DaleT wrote:
>> On Friday, November 5, 2021 at 8:47:17 AM UTC-5, austin obyrne wrote:
>>> On Friday, 5 November 2021 at 12:36:03 UTC, DaleT wrote:
>>>> On Friday, November 5, 2021 at 5:17:07 AM UTC-5, austin obyrne wrote:
>>>>> A reader asked "Is the change_of_Origin a constant"
>>>>>
>>>>> No there are 6 files each containing 0 to 14250 elements
>>>>>
>>>> If this large array is going to be be public knowledge, rather
>>>> than sending it securely as part of a key, then why do it at all.

>>> It is not sent regukarly - it is sent once in a secure one-off
>>> delivery of the entities' mutual database from Alice to Bob at the
>>> very outset of setting up the secure link.. After that they
>>> sybchronise their mutual database whenever Alice (alone) decides.
>>>
>>> Thet do this by Alice sending scrambling parameters to Bob that are
>>> useless to Eve should she intercept them not having any knowledge
>>> of the Entities' files to which the scrambling parameters apply.
>>

>> That sounds like a ont-time-pad.....very secure...but not distributable.
>
> No, it's not a one time pad, because Austin's key is re-used, and
> just perturbed when Alice feels like it. She sends the perturbations
> to Bob, and the rest of the key remains untouched. Is this not
> setting off all your alarm bells?

And, IIRC, the sending of the perturbations was advertised by Austin as
not needing a secure channel, because of his belief that without the
original Ada source, Eve can't do anything with the perturbation
information.

But he's again thinking linearly. Eve just sits, and watches, and
grabs plural perturbations between Alice and Bob. Each new
"perturbation" data-set allows Eve to narrow in upon Alice and Bob's
key. If Alice decides to perturb often enough (yes, I know, the
difficulty makes this unlikely), eventually Eve will have the entire
key and can decrypt everything, even after future perturbations, from
that point onward.

[Rich]

austin obyrne <ao40...@gmail.com> wrote:
> On Friday, 5 November 2021 at 14:33:26 UTC, Rich wrote:
>> austin obyrne <ao40...@gmail.com> wrote:
>> > A reader asked "Is the change_of_Origin a constant"
>> I was that 'reader', thank you.
>> > No there are 6 files each containing 0 to 14250 elements
>> >
>> > Herewith a sample of one of them.
>> >
>> > ...
>> > FUNCTION GetNum (NumIn: Integer) RETURN Integer IS
>> How is the value of NumIn chosen for a given single encryption of a
>> message of 20 characters?
>
> Numin is only used at boot-up time - lemme explain
>
> The database is a series of several out-of-sight ' Case Statements'
> Each one of these is loaded into a set of named arrays of the same
> size at boot-up. .i.e. the arrays absorb the full contents of the
> case statement each time.
>
> Numin directs the cell in the corresponding array into which each
> element will go in consecutive order. (In passing and very
> importantly - NOTE WELL the elements of every case satement are
> studiously *scrambled as they are loaded into each array).

Do you mean you effectively do the following at program start (Ada
like, but I'm not well versed in Ada, so this is likely also incorrect
Ada in many ways):

for numin from 0 to 14250 do:
array1(numin) = GetNum(numin);
done;

> The name ' Numin'. is not used again to call variables.
>
> The variables are handy in ready use arrays now and the counter '
> Total ' is used to call each varaiable along with the name of the
> array when a particular one is is required.

Ok, so, once the "case statements" are loaded into "ready use arrays"
how are the "ready use arrays" utilized to perform a "change of
origin"? How is the index to the "ready use arrays" derived to read a
value from a given array while encrypting?

> I hope this answers your question but come back by all means if not.

It created more questions, therefore the above.

[Richard Heathfield]

Indeed.

> Eve just sits, and watches, and
> grabs plural perturbations between Alice and Bob.

Because Austin cannot envisage how useful to Eve this data is, he
insists Eve cannot use it.

> Each new
> "perturbation" data-set allows Eve to narrow in upon Alice and Bob's
> key.

Austin can't see this.

It's like a list of journey directions from a secret location. The
longer the list of directions gets, the fewer places there are on the
map where it will fit, and eventually there's only one possible starting
point.

> If Alice decides to perturb often enough (yes, I know, the
> difficulty makes this unlikely), eventually Eve will have the entire
> key and can decrypt everything, even after future perturbations, from
> that point onward.

Indeed.

[MM]

On Friday, 5 November 2021 at 10:17:07 UTC, austin obyrne wrote:
> A reader asked "Is the change_of_Origin a constant"
>
> No there are 6 files each containing 0 to 14250 elements
>
> Herewith a sample of one of them.
>
>
> WITH Ada.Text_IO;
> PACKAGE BODY Change_of_Origin_I_Coefficients IS

... etc.

The problem is that you don't need that massive case statement,
the function call or the error message.

Ada is perfectly capable of replacing all that, plus the loop to copy
the contents of the case statement, into an array by a static
initialisation of the array, with no runtime overhead.

Instead of

FOR I IN 1 .. 14250 LOOP
Origin_I(I):= Change_Of_Origin_I_Coefficients.GetNum(NumIn => I)REM 10000;
END LOOP;

Which is a huge waste of time, space and effort

You simply fill the arrays when you declare them, like

-- When the program starts, the numbers will
-- already be in the arrays, as the declarations
-- include the initial values.
-- These should be in a package, so there would
-- be no need to duplicate them in the encryption
-- and decryption programs.
offset_index is positive range 1 .. 14250; -- Define once, use many.
offset_i: array(offset_index) := (14442 ..... 28690);
offset_j: array(offset_index) := ( ........);

In the examples above I've not put the numbers in the brackets
for brevity, but I'm sure you get the idea.

You don't need a new range subtype for each array range; reuse
the ones that already have. You don't need an array subtype for
each array. There is a time and place for those, but in your
programs they just make the code longer for no good reason.

Ada will take care of out-of-bounds array references for you,
simplifying the code.

Any time you loop through all the values of those arrays, you
do

-- No need to mention 1..14250 again, re-use offset_index.
for i in offset_index loop
do something with offset_i(i) and offset_j(i)
end loop;

If you change the offset_index range, you only change it in one
place. You don't have to waste time changing it everywhere, and
risk bugs by missing some.

Your files will still be big with all those numbers, but MUCH smaller
and faster than with those case statements.

It would be better to read those numbers from a file if they are
supposed to be secret. There would be a speed penalty, but it
would be a necessary one unlike the case statement wastage.

M
--

[MM]

On Friday, 5 November 2021 at 18:11:16 UTC, MM wrote:
> -- When the program starts, the numbers will
> -- already be in the arrays, as the declarations
> -- include the initial values.
> -- These should be in a package, so there would
> -- be no need to duplicate them in the encryption
> -- and decryption programs.
> offset_index is positive range 1 .. 14250; -- Define once, use many.
> offset_i: array(offset_index) := (14442 ..... 28690);
> offset_j: array(offset_index) := ( ........);

A correction; The above declarations should be

offset_index is positive range 1 .. 14250; -- Define once, use many.

offset_i: array(offset_index) of integer := (14442 ..... 28690);
offset_j: array(offset_index) of integer := ( ........);

I left out the "of integer". Apologies.

M
--

[Richard Heathfield]

It's one hell of a key though, isn't it! I mean, I *like* big keys - my
preference is to let the user specify the key size and then to put all
the key bits to good use if I can. But 14250 32-bit numbers --- 55 KB!
--- really is taking the proverbial.

[Chris M. Thomasson]

On 11/5/2021 4:02 AM, austin obyrne wrote:
> On Friday, 5 November 2021 at 10:32:07 UTC, Richard Heathfield wrote:
>> On 05/11/2021 10:17, austin obyrne wrote:
>>> A reader asked "Is the change_of_Origin a constant"
>>>
>>> No there are 6 files each containing 0 to 14250 elements
>>>
>>> Herewith a sample of one of them.
>>>
>>>
>>> WITH Ada.Text_IO;
>>> PACKAGE BODY Change_of_Origin_I_Coefficients IS

[...

>> Bloody hell, Austin! Look up "array", why don't you?
>>
>> https://learn.adacore.com/courses/intro-to-ada/chapters/arrays.html
>>
>> Then you can write:
>>
>> RETURN Coefficient(NumIn);

[...]es -that sounds good - but i don't want to change horses in mid stream

> - I suggest you do that yourself- I have copyright for however far it will take
> me on my cipher but I will forego that for regular readers of this group.
> The invitation is to write your own program within sci.group but not
> commercialise it for gain.

[...]

Why should Richard do that for you? Well, are you actually asking him to
create a version of your ADA code that does it? Pay him five hundred
grand, and he might think about it... ;^)

[Colin]

>
> But he's again thinking linearly. Eve just sits, and watches, and
> grabs plural perturbations between Alice and Bob. Each new
> "perturbation" data-set allows Eve to narrow in upon Alice and Bob's
> key. If Alice decides to perturb often enough (yes, I know, the
> difficulty makes this unlikely), eventually Eve will have the entire
> key and can decrypt everything, even after future perturbations, from
> that point onward.
>

https://groups.google.com/g/sci.crypt/c/INhaZXim7PQ/m/YvroCjWeBgAJ

https://groups.google.com/g/sci.crypt/c/9HfpmBxt5nw

[Colin]

https://groups.google.com/g/sci.crypt/c/thXZUU0oH5o

> https://groups.google.com/g/sci.crypt/c/9HfpmBxt5nw
>

sorry pushed send too quick, hope this formats ok.


composite 2
https://groups.google.com/g/sci.crypt/c/INhaZXim7PQ/m/YvroCjWeBgAJ
9128962 9649216 7358484 8943976 *8714739**6219192* 9727246 5412889
5428213
9428033 3123649 8524625 2928185 6514468 5426040 6826615 9111506
5729780
5727414 5048391 9707113 9685465 6515703 4660578 8256052
*9889497**6527157*
8731063 5411795 5425292 6589474 6814876 9769974 6498564
#7529332##6524279#
5724667 6471372 9266474 5828682 6315198 8639628 5718795 4717686
5424209
8968696 9714466 9361106 5722861 8914663 8724413 5724802 6513215
5724276
6419395 8114459 6328302 5992520 3514823 5157709 9823817 4771362
9862983
7223831 5209399 5428822 5214494 9614866 5123527 6714711
*7461976**8424166*
5824932 5166564 6257718 5757805 6514811 5707921 2202543
#7536666##5424165#
8724354 6478762 9563044 9828782 8715100 8422528 6767022 5441967
8724181
8724350 8396009 5450397 6528365 9515724 2521153 4723848 6632874
2665472
3225087 5303577 9647056 8731197 8414901 7422649 9184400 4729662
5424475
2425077 3196635 9539163 2698572 6514906 5052899 5686867 5751687
5424030
2526668 2400387 2135755 8759246 3715232 5412342 6812352 9819212
5824236
8732171 5709495 9424146 8431062 6214619 8722097 6332551 6551054
6524062
.....................................^^^^.................................^^^^...

composite 6
9827069 9685909 7341723 6549916 8714829 6216492 9827246 5414086
5427016
8728333 3098549 8551625 9834509 6514536 5421484 7226868 9113024
5728262
8627216 5118285 9631279 9387169 6515739 4658646 7062992 9974267
6527402
6828073 5413745 5426462 9888790 6814872 9770426 9598564
#7529332##6524279#
8724181 6496401 9241688 8826410 6315182 8641452 5423569 4714606
5423901
6005937 9714466 9269918 7822861 8914492 8724584 6924802 6513629
5723862
9541356 8114459 6406341 6858495 3514914 5092371 8723817 4658844
9965241
9224169 5127603 5509942 8853881 9614923 5082829 5371372 7437292
8423979
9824827 5171114 6254498 7624493 6514464 5723536 7402543
#7536666##5424165#
8724468 6471086 9571480 9834614 8715829 8421070 8693854 5429019
8724025
7624656 8385452 5465544 8735749 9517712 2516893 7623848 6648721
2649625
9724898 5320020 9628786 6528355 8414754 7423090 8684036 4729802
5424481
6524015 3211857 9526065 9874667 6514611 5110719 6452123 5786633
5424232
7627409 2396682 2138890 9825487 3714550 5423254 8704522 9822431
5824497
7632171 5709495 9424146 8747447 6214909 8718182 5907569
@6574935@@6524205@
^^^^.................................^^^^.................................^^^^...

current test piece
9827086 9681778 7343610 6543976 *8714739**6219192* 9827246 5413762
5427340
8727481 3169833 8474945 9859805 6514808 5403260 7226813 9112694
5728592
8627363 5066394 9687580 9345279 6514854 4706141 7256052
*9889497**6527157*
6836744 5408090 5423069 9895801 6814913 9765793 9604164 7526032
6524179
8724263 6492178 9245870 8785230 6314892 8674512 5413091 4721366
5424577
5784378 9714466 9417130 7822861 8914716 8724360 6924802 6513256
5724235
9670524 8114459 6277173 6828770 3514873 5121809 8723817 4695034
9932351
9223985 5172131 5465782 8817258 9614870 5120671 5314711
*7461976**8424166*
9824089 5203094 6231866 7663469 6514870 5705266 7583083 7436956
5423870
8724480 6470278 9572368 9833630 8715706 8421316 8708990 5421715
8723937
7624648 8385728 5465148 8733149 9517012 2518393 7623848 6660980
2637366
9724628 5343510 9602686 6531081 8414895 7422667 8691498 4726932
5424358
6524900 3199172 9536980 9988517 6514761 5081319 6501831 5736636
5423943
7624159 2412932 2125140 9850336 3715052 5415222 8691472 9827796
5824932
7626835 5712743 9423914 8775697 6215409 8711432 5907569
@6574935@@6524205@
^^^^.................................^^^^.................................^^^^...

[Max]

It has at least one important thing in common with an OTP: the key is
much larger than any piece of plaintext ever encrypted with it. Thus, so
far there has never been a scenario where the algorithm even could have
been tested. Any simple scrambling step could just take some more
entropy from the keys and slap it onto the plaintext. Until there is a
reference implementation allowing for the generation of some mega- (or
with this amount of key material rather tera-) bytes of ciphertext, all
of this are just shenanigans.

[Rich]

Colin <a...@b.com> wrote:
> On 6/11/21 10:35, Colin wrote:
>>
>>>
>>> But he's again thinking linearly.  Eve just sits, and watches, and
>>> grabs plural perturbations between Alice and Bob.  Each new
>>> "perturbation" data-set allows Eve to narrow in upon Alice and Bob's
>>> key.  If Alice decides to perturb often enough (yes, I know, the
>>> difficulty makes this unlikely), eventually Eve will have the entire
>>> key and can decrypt everything, even after future perturbations, from
>>> that point onward.
>>>
>>
>> https://groups.google.com/g/sci.crypt/c/INhaZXim7PQ/m/YvroCjWeBgAJ
>>
>
> https://groups.google.com/g/sci.crypt/c/thXZUU0oH5o
>
>> https://groups.google.com/g/sci.crypt/c/9HfpmBxt5nw
>>
>
> sorry pushed send too quick, hope this formats ok.

Had to reformat it a bit here, but nice repeats across the three
different samples. Seems there is a *lot* that is very much in common
with prior variants (which is not surprising).

[Colin]

then if you compare plaintext between first two samples at character 12,
( ie #7529332##6524279# )

The Eddystone
% Environment
...........^.

This strongly indicates to me no ciphertext scrambling was deployed.