Richard Heathfield <r...@cpax.org.uk
> On 07/11/2021 13:49, Rich wrote:
>> austin obyrne <ao40...@gmail.com
>>> 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,
>>>>> 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.
>>>> 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
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
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