On 2/13/2024 8:45 PM, Rich wrote:
> In sci.crypt Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 2/12/2024 5:30 PM, The Doctor wrote:
>>> Deos anyone how what encryption is being used here?
>>>
>>> *1234567890ABCDEF01234567890ABCDEF0123456
>>
>> None? lol. just kidding. Humm...
>>
>> Some combination of plaintext, secret key and cipher algorithm
>> generated it. Probably, the plaintext was hand crafted? ;^)
>
> As Jacob correctly pointed out, if one knows the message, one can then
> 'hand craft' a one-time-pad to generate exactly this output from that
> message.

Or even the other way around? If one knows the OTP (Bob and/or Alice),
they can create a special plaintext that generates this output for fun.

> The usual issues with getting the OTP to Bob so Bob can
> decrypt still apply.

Indeed.

Chris M. Thomasson wrote:

> On 2/13/2024 8:45 PM, Rich wrote:
> > In sci.crypt Chris M. Thomasson <chris.m.thomasson.1@gmail.com>
> > wrote:
> >> On 2/12/2024 5:30 PM, The Doctor wrote:
> >>> Deos anyone how what encryption is being used here?
> >>>
> >>> *1234567890ABCDEF01234567890ABCDEF0123456
> >>
> >> None? lol. just kidding. Humm...
> >>
> >> Some combination of plaintext, secret key and cipher algorithm
> >> generated it. Probably, the plaintext was hand crafted? ;^)
> >
> > As Jacob correctly pointed out, if one knows the message, one can
> > then 'hand craft' a one-time-pad to generate exactly this output
> > from that message.
>
> Or even the other way around? If one knows the OTP (Bob and/or
> Alice), they can create a special plaintext that generates this
> output for fun.

How would you do this? I mean the OP IMHO does not show an encrypted
string, done with an OTP. OTPs nature is that it does not include
patterns and is totally random.

Even if this string is not encrypted and only encoded, how would one
get such pattern from plain text and convert it back to plain text?

It had been best if the OP had posted a reference URL ...

Regards
Stefan
--
----Ed25519 Signature----
924d68b09939ff530a360fb2865c20195c09f0c0278c1e189d9a2ec3d036d252
c1fb0947cde91b30f3a85319c063eb0d72fce5b739a2bd9ea09bc55bb65e4e01

Rich wrote:

> In sci.crypt Stefan Claas <pollux@tilde.club> wrote:
> > Chris M. Thomasson wrote:

> >> Or even the other way around? If one knows the OTP (Bob and/or
> >> Alice), they can create a special plaintext that generates this
> >> output for fun.
> >
> > How would you do this?
>
> For a traditional, 1940's substution style OTP, it is trivial:
>
> Message: The
>
> Pad:
>
> T=H
> e=r
> h=e
>
> Substitute using the pad, get the encrypted message: Her

Well, one uses a substitution table, trigraph, etc. and then
a pad to encrypt the message. Otherwise it would be a plain
text encoded message, right?
> > It had been best if the OP had posted a reference URL ...
>
> I doubt OP found the string at some URL. I suspect the OP was
> trolling.

That was my thought too and the reason why I did not reply to him
directly.

Regards
Stefan
--
----Ed25519 Signature----
cec364f80a628ea8fa2d4734e0cf804ad331b8d6f2e65c1f2f7441fc2728186c
2cc5ce7d3e5d69a80c0140c8973536ed840a5613f727eb5924612d392b7ea202

On 2/15/2024 12:20 PM, Stefan Claas wrote:
> Rich wrote:
>
>> In sci.crypt Stefan Claas <pollux@tilde.club> wrote:
>>> Chris M. Thomasson wrote:
>
>>>> Or even the other way around? If one knows the OTP (Bob and/or
>>>> Alice), they can create a special plaintext that generates this
>>>> output for fun.
>>>
>>> How would you do this?
>>
>> For a traditional, 1940's substution style OTP, it is trivial:
>>
>> Message: The
>>
>> Pad:
>>
>> T=H
>> e=r
>> h=e
>>
>> Substitute using the pad, get the encrypted message: Her
>
> Well, one uses a substitution table, trigraph, etc. and then
> a pad to encrypt the message. Otherwise it would be a plain
> text encoded message, right?

Give me a OPT 3 bytes long. Creating a plaintext that results in a
ciphertext of say 123, or ABC is possible...

>
>>> It had been best if the OP had posted a reference URL ...
>>
>> I doubt OP found the string at some URL. I suspect the OP was
>> trolling.
>
> That was my thought too and the reason why I did not reply to him
> directly.
>
> Regards
> Stefan

Chris M. Thomasson wrote:

> On 2/15/2024 12:20 PM, Stefan Claas wrote:
> > Rich wrote:
> >
> >> In sci.crypt Stefan Claas <pollux@tilde.club> wrote:
> >>> Chris M. Thomasson wrote:
> >
> >>>> Or even the other way around? If one knows the OTP (Bob and/or
> >>>> Alice), they can create a special plaintext that generates this
> >>>> output for fun.
> >>>
> >>> How would you do this?
> >>
> >> For a traditional, 1940's substution style OTP, it is trivial:
> >>
> >> Message: The
> >>
> >> Pad:
> >>
> >> T=H
> >> e=r
> >> h=e
> >>
> >> Substitute using the pad, get the encrypted message: Her
> >
> > Well, one uses a substitution table, trigraph, etc. and then
> > a pad to encrypt the message. Otherwise it would be a plain
> > text encoded message, right?
>
> Give me a OPT 3 bytes long. Creating a plaintext that results in a
> ciphertext of say 123, or ABC is possible...

Yes, but then it is not OTP encryption and only plain code, done
with substitution, I would say. The OP's Subject: is Patterns.

Regards
Stefan
--
----Ed25519 Signature----
0722421a0b6680c4ade0fcaac8d76552cf746531dd89eeca1b7db32ecef8bceb
9c4ca60a0298d56bd96340d8a4a1b05bc4c38d6fcf13d8aa2633018b09f0ff0f

Stefan Claas wrote:

> Chris M. Thomasson wrote:
>
> > On 2/15/2024 12:20 PM, Stefan Claas wrote:
> > > Rich wrote:
> > >
> > >> In sci.crypt Stefan Claas <pollux@tilde.club> wrote:
> > >>> Chris M. Thomasson wrote:
> > >
> > >>>> Or even the other way around? If one knows the OTP (Bob and/or
> > >>>> Alice), they can create a special plaintext that generates this
> > >>>> output for fun.
> > >>>
> > >>> How would you do this?
> > >>
> > >> For a traditional, 1940's substution style OTP, it is trivial:
> > >>
> > >> Message: The
> > >>
> > >> Pad:
> > >>
> > >> T=H
> > >> e=r
> > >> h=e
> > >>
> > >> Substitute using the pad, get the encrypted message: Her
> > >
> > > Well, one uses a substitution table, trigraph, etc. and then
> > > a pad to encrypt the message. Otherwise it would be a plain
> > > text encoded message, right?
> >
> > Give me a OPT 3 bytes long. Creating a plaintext that results in a
> > ciphertext of say 123, or ABC is possible...
>
> Yes, but then it is not OTP encryption and only plain code, done
> with substitution, I would say. The OP's Subject: is Patterns.

To be more clear, an OTP encrypted message with digits or letters
can of course include 3-5 letter words or a 3-5 digits sequence, but
in case of OTPs this means nothing and I would not call it pattern,
in an encrypted message.

Regards
Stefan
--
----Ed25519 Signature----
48c677c37bef1ad110bea0c0c42da8846f5b1e628b1b04d6f2400cc4696c5171
361fc85f7b1c3ebd65756278b51194f681428720b3b4360c13b7c3d306fd8d0f

On 2/16/2024 9:07 AM, Stefan Claas wrote:
> Stefan Claas wrote:
>
>> Chris M. Thomasson wrote:
>>
>>> On 2/15/2024 12:20 PM, Stefan Claas wrote:
>>>> Rich wrote:
>>>>
>>>>> In sci.crypt Stefan Claas <pollux@tilde.club> wrote:
>>>>>> Chris M. Thomasson wrote:
>>>>
>>>>>>> Or even the other way around? If one knows the OTP (Bob and/or
>>>>>>> Alice), they can create a special plaintext that generates this
>>>>>>> output for fun.
>>>>>>
>>>>>> How would you do this?
>>>>>
>>>>> For a traditional, 1940's substution style OTP, it is trivial:
>>>>>
>>>>> Message: The
>>>>>
>>>>> Pad:
>>>>>
>>>>> T=H
>>>>> e=r
>>>>> h=e
>>>>>
>>>>> Substitute using the pad, get the encrypted message: Her
>>>>
>>>> Well, one uses a substitution table, trigraph, etc. and then
>>>> a pad to encrypt the message. Otherwise it would be a plain
>>>> text encoded message, right?
>>>
>>> Give me a OPT 3 bytes long. Creating a plaintext that results in a
>>> ciphertext of say 123, or ABC is possible...
>>
>> Yes, but then it is not OTP encryption and only plain code, done
>> with substitution, I would say. The OP's Subject: is Patterns.
>
> To be more clear, an OTP encrypted message with digits or letters
> can of course include 3-5 letter words or a 3-5 digits sequence, but
> in case of OTPs this means nothing and I would not call it pattern,
> in an encrypted message.
>

AFAICT, it all boils down to fun with OTP's... ;^)

On 2/16/2024 4:25 PM, William Unruh wrote:
> On 2024-02-16, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 2/16/2024 9:07 AM, Stefan Claas wrote:
>>> Stefan Claas wrote:
>>>
>>>> Chris M. Thomasson wrote:
>>>>
>>>>> On 2/15/2024 12:20 PM, Stefan Claas wrote:
>>>>>> Rich wrote:
>>>>>>
>>>>>>> In sci.crypt Stefan Claas <pollux@tilde.club> wrote:
>>>>>>>> Chris M. Thomasson wrote:
>>>>>>
>>>>>>>>> Or even the other way around? If one knows the OTP (Bob and/or
>>>>>>>>> Alice), they can create a special plaintext that generates this
>>>>>>>>> output for fun.
>>>>>>>>
>>>>>>>> How would you do this?
>>>>>>>
>>>>>>> For a traditional, 1940's substution style OTP, it is trivial:
>>>>>>>
>>>>>>> Message: The
>>>>>>>
>>>>>>> Pad:
>>>>>>>
>>>>>>> T=H
>>>>>>> e=r
>>>>>>> h=e
>>>>>>>
>>>>>>> Substitute using the pad, get the encrypted message: Her
>>>>>>
>>>>>> Well, one uses a substitution table, trigraph, etc. and then
>>>>>> a pad to encrypt the message. Otherwise it would be a plain
>>>>>> text encoded message, right?
>>>>>
>>>>> Give me a OPT 3 bytes long. Creating a plaintext that results in a
>>>>> ciphertext of say 123, or ABC is possible...
>>>>
>>>> Yes, but then it is not OTP encryption and only plain code, done
>>>> with substitution, I would say. The OP's Subject: is Patterns.
>>>
>>> To be more clear, an OTP encrypted message with digits or letters
>>> can of course include 3-5 letter words or a 3-5 digits sequence, but
>>> in case of OTPs this means nothing and I would not call it pattern,
>>> in an encrypted message.
>>>
>>
>> AFAICT, it all boils down to fun with OTP's... ;^)
>>
>
> A One Time Pad means what it says. It can only be used once. It must be
> the same size as the message to be encrypted (ie you cannot use pad from
> earlier in the message to encode later stuff.) Otherwise it is weak. It
> is not a substition cypher (eg your T=H e=r h=e ) to encrypt any other
> occrances of T, h or e. That is NOT an OTP. It is a MRP (Many time pad)
> which is woefully weak. A OTP is unconditionally secret. It cannot be
> broken. An MTP is very weak, or a substitiution cypher is very weak
> unless the substition block is really large.
> OTPs are not fun. They are boring, because there is no way they can be
> broken, unless you capture the key. But of course that is their problem
> since you have to get the key to the recipient, without the enemy
> capturing the key, and the key is huge, so hard to hide.
>

There can be some fun. Then it makes one, at least me, think about
prepending plaintext with TRNG data and whacking it with HMAC... ;^)

On 2/15/2024 11:02 AM, Stefan Claas wrote:
> Chris M. Thomasson wrote:
>
>> On 2/13/2024 8:45 PM, Rich wrote:
>>> In sci.crypt Chris M. Thomasson <chris.m.thomasson.1@gmail.com>
>>> wrote:
>>>> On 2/12/2024 5:30 PM, The Doctor wrote:
>>>>> Deos anyone how what encryption is being used here?
>>>>>
>>>>> *1234567890ABCDEF01234567890ABCDEF0123456
>>>>
>>>> None? lol. just kidding. Humm...
>>>>
>>>> Some combination of plaintext, secret key and cipher algorithm
>>>> generated it. Probably, the plaintext was hand crafted? ;^)
>>>
>>> As Jacob correctly pointed out, if one knows the message, one can
>>> then 'hand craft' a one-time-pad to generate exactly this output
>>> from that message.
>>
>> Or even the other way around? If one knows the OTP (Bob and/or
>> Alice), they can create a special plaintext that generates this
>> output for fun.
>
> How would you do this? I mean the OP IMHO does not show an encrypted
> string, done with an OTP. OTPs nature is that it does not include
> patterns and is totally random.

If Bob and Alice have access to the same OPT, one of them can create a
special plaintext that can give the message in the ciphertext, or
whatever... Think about it... ;^)

>
> Even if this string is not encrypted and only encoded, how would one
> get such pattern from plain text and convert it back to plain text?
>
> It had been best if the OP had posted a reference URL ...
>
> Regards
> Stefan

On 2/20/2024 1:55 PM, Richard Harnden wrote:
> On 20/02/2024 21:09, Chris M. Thomasson wrote:
>> On 2/15/2024 11:02 AM, Stefan Claas wrote:
>>> Chris M. Thomasson wrote:
>>>
>>>> On 2/13/2024 8:45 PM, Rich wrote:
>>>>> In sci.crypt Chris M. Thomasson <chris.m.thomasson.1@gmail.com>
>>>>> wrote:
>>>>>> On 2/12/2024 5:30 PM, The Doctor wrote:
>>>>>>> Deos anyone how what encryption is being used here?
>>>>>>>
>>>>>>> *1234567890ABCDEF01234567890ABCDEF0123456
>>>>>>
>>>>>> None? lol. just kidding. Humm...
>>>>>>
>>>>>> Some combination of plaintext, secret key and cipher algorithm
>>>>>> generated it.  Probably, the plaintext was hand crafted?  ;^)
>>>>>
>>>>> As Jacob correctly pointed out, if one knows the message, one can
>>>>> then 'hand craft' a one-time-pad to generate exactly this output
>>>>> from that message.
>>>>
>>>> Or even the other way around? If one knows the OTP (Bob and/or
>>>> Alice), they can create a special plaintext that generates this
>>>> output for fun.
>>>
>>> How would you do this? I mean the OP IMHO does not show an encrypted
>>> string, done with an OTP. OTPs nature is that it does not include
>>> patterns and is totally random.
>>
>> If Bob and Alice have access to the same OPT, one of them can create a
>> special plaintext that can give the message in the ciphertext, or
>> whatever... Think about it... ;^)
>>
>
> If the ciphertext is just going to be 123...abc..., then there is no
> point in transmitting it.
>
>
>

Thing of using sections of a large OPT to get:

ciphertext: 123456789

plaintext: thefoxrun

Of source, alice is in on the fun. She says 123456789, lol...

Just for different ways of thinking how to use things.

On 2/20/2024 2:15 PM, Chris M. Thomasson wrote:
> On 2/20/2024 1:55 PM, Richard Harnden wrote:
>> On 20/02/2024 21:09, Chris M. Thomasson wrote:
>>> On 2/15/2024 11:02 AM, Stefan Claas wrote:
>>>> Chris M. Thomasson wrote:
>>>>
>>>>> On 2/13/2024 8:45 PM, Rich wrote:
>>>>>> In sci.crypt Chris M. Thomasson <chris.m.thomasson.1@gmail.com>
>>>>>> wrote:
>>>>>>> On 2/12/2024 5:30 PM, The Doctor wrote:
>>>>>>>> Deos anyone how what encryption is being used here?
>>>>>>>>
>>>>>>>> *1234567890ABCDEF01234567890ABCDEF0123456
>>>>>>>
>>>>>>> None? lol. just kidding. Humm...
>>>>>>>
>>>>>>> Some combination of plaintext, secret key and cipher algorithm
>>>>>>> generated it.  Probably, the plaintext was hand crafted?  ;^)
>>>>>>
>>>>>> As Jacob correctly pointed out, if one knows the message, one can
>>>>>> then 'hand craft' a one-time-pad to generate exactly this output
>>>>>> from that message.
>>>>>
>>>>> Or even the other way around? If one knows the OTP (Bob and/or
>>>>> Alice), they can create a special plaintext that generates this
>>>>> output for fun.
>>>>
>>>> How would you do this? I mean the OP IMHO does not show an encrypted
>>>> string, done with an OTP. OTPs nature is that it does not include
>>>> patterns and is totally random.
>>>
>>> If Bob and Alice have access to the same OPT, one of them can create
>>> a special plaintext that can give the message in the ciphertext, or
>>> whatever... Think about it... ;^)
>>>
>>
>> If the ciphertext is just going to be 123...abc..., then there is no
>> point in transmitting it.
>>
>>
>>
>
> Thing of using sections of a large OPT to get:
>
> ciphertext: 123456789
>
> plaintext: thefoxrun
>
> Of source, alice is in on the fun. She says 123456789, lol...
>
> Just for different ways of thinking how to use things.

One can encrypt a message in binary while eating soup. The spoons and
the number of times it uses the spoon can encrypt. ;^)

Chris M. Thomasson wrote:

> If Bob and Alice have access to the same OPT, one of them can create
> a special plaintext that can give the message in the ciphertext, or
> whatever... Think about it... ;^)

Can you craft an example, maybe with code (that compiles ...)?

BTW. I would appreciate if you and other sci.crypt regulars
can sign my guestbook, on my Gemini-Capsule.

gemini://tilde.club/~pollux/

The guestbook is under Gästebuch.

I am thinking about to set-up a cryptobook for us in Geminispace,
so that small encrypted messages can be left there ... ;-)

Regards
Stefan
--
----Ed25519 Signature----
d9ebda51717e5bf7c606c460e632d40daa4fa4315574e6aa5b030d60a79654d0
6fa37e28bed2cc9d8ec7ba5d51dd97faa279d0ccc208092802bedc262e88bc0e

On 2/21/2024 10:24 AM, Stefan Claas wrote:
> Chris M. Thomasson wrote:
>
>> If Bob and Alice have access to the same OPT, one of them can create
>> a special plaintext that can give the message in the ciphertext, or
>> whatever... Think about it... ;^)
>
> Can you craft an example, maybe with code (that compiles ...)?
>
> BTW. I would appreciate if you and other sci.crypt regulars
> can sign my guestbook, on my Gemini-Capsule.
>
> gemini://tilde.club/~pollux/
>
> The guestbook is under Gästebuch.
>
> I am thinking about to set-up a cryptobook for us in Geminispace,
> so that small encrypted messages can be left there ... ;-)

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=9c113c0799ac3d9b52edbf3429aa673022d46643c5689d93f7cc16688e99961c249bb349a7c6a1c9603ddc793f613cb08a32d3c8284f6dd1a0e9fe3d2cbaf4b32d9717a7be19a1b4934a1e5c5b653ce9213e2acf0cd24a9af41789f9c0bba9fbe2f835a31fe35d90b95514f4d3ad1261e8fc3de2268fec68037bce2dc315ed0668cfd03c78335c171123bc164cca83816da4

Chris M. Thomasson wrote:

> On 2/21/2024 10:24 AM, Stefan Claas wrote:
> > Chris M. Thomasson wrote:
> >
> >> If Bob and Alice have access to the same OPT, one of them can
> >> create a special plaintext that can give the message in the
> >> ciphertext, or whatever... Think about it... ;^)
> >
> > Can you craft an example, maybe with code (that compiles ...)?
> >
> > BTW. I would appreciate if you and other sci.crypt regulars
> > can sign my guestbook, on my Gemini-Capsule.
> >
> > gemini://tilde.club/~pollux/
> >
> > The guestbook is under Gästebuch.
> >
> > I am thinking about to set-up a cryptobook for us in Geminispace,
> > so that small encrypted messages can be left there ... ;-)
>
>
> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=9c113c0799ac3d9b52edbf3429aa673022d46643c5689d93f7cc16688e99961c249bb349a7c6a1c9603ddc793f613cb08a32d3c8284f6dd1a0e9fe3d2cbaf4b32d9717a7be19a1b4934a1e5c5b653ce9213e2acf0cd24a9af41789f9c0bba9fbe2f835a31fe35d90b95514f4d3ad1261e8fc3de2268fec68037bce2dc315ed0668cfd03c78335c171123bc164cca83816da4

Gemini is an Internet Protocol, starting with gemini:// and a mixture
of gopher and classic html.

Regards
Stefan
--
----Ed25519 Signature----
a3ea8d7848721a39804504886a973579eba929486734109e6a345b7d187c405b
4e2d0b5662ed90305670277288fce36151675d3789e48c9e334141e2613ab103

Rich wrote:

> In sci.crypt Stefan Claas <pollux@tilde.club> wrote:
> > Chris M. Thomasson wrote:
> >
> >> If Bob and Alice have access to the same OPT, one of them can
> >> create a special plaintext that can give the message in the
> >> ciphertext, or whatever... Think about it... ;^)
> >
> > Can you craft an example, maybe with code (that compiles ...)?
>
> This is not go, but you should be able to follow along well enough.
> Note that ^ is Tcl's expr's byte wise XOR operator.:
>
> #!/usr/bin/tclsh
>
> # "OTP" - obtained by running this, then converted to 0x notation
> by hand: # dd if=/dev/urandom bs=1 count=2 | xxd
> # f1c3
>
> set otp 0xf1c3
>
> # show otp:
> puts [format "OTP: %04x" $otp]
>
> # message that Bob should see in the encrypted text
> # "feed"
>
> set bob 0xfeed
>
> # create Alice's message, which when 'encrypted' will result in
> Bob seeing # "feed" in the encrypted text
>
> set alice [expr {$otp ^ $bob}]
>
> # output Alice's message as a hex string:
> puts [format "Alice 'special' message: %04x" $alice]
>
> # encrypt Alice's special message using the OTP:
>
> set ciphertext [expr {$alice ^ $otp}]
>
> # output ciphertext as hex string
> puts [format "Ciphertext: %04x" $ciphertext]

Thanks for the code example.
> Running this results in:
>
> OTP: f1c3
> Alice 'special' message: 0f2e
> Ciphertext: feed

He he, so Alice crafts a message she can't read herself, but the
ciphertext is readable for third parties. It would be cool if there
would be a real world usage scenario for this.

Maybe a verifying scheme, like Alice submits a long hex key to Bob,
in that form, so that he knows the message comes from Alice if it
says 'the quick brown fox jumps ...'

Regards
Stefan
--
----Ed25519 Signature----
0c8a7d5aead639537cab202da5fab93756cc33bd29705ca6edc240c9172d1a0e
e8dfca6350ec5e2963d906042c7667824673753acba4b7495a909b54bc1b6809

Stefan Claas wrote:

> Gemini is an Internet Protocol, starting with gemini:// and a mixture
> of gopher and classic html.

https://github.com/kr1sp1n/awesome-gemini

Regards
Stefan
--
----Ed25519 Signature----
0d1bafdd4013b840a05c4a6b7218a01ce97f7e6faa213f917ae861a12af38d8c
1f1d33e84cc5547aa35c164ac810872324c8ebe738d8df9f00d301a332ae0e07

On 2/23/2024 10:59 AM, Stefan Claas wrote:
> Stefan Claas wrote:
>
>> Gemini is an Internet Protocol, starting with gemini:// and a mixture
>> of gopher and classic html.
>
> https://github.com/kr1sp1n/awesome-gemini

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=19d672f834593b161ffb1338f77bd51aa5328ab1854b531f33d415ac79ddb154a85beacb0a155cb64b47e551cadf2ad22ad689920bcdc670d1283d337413b691cd1294db0a7ae44bf6e5a9aa3adc138d4a7e2807c48c6612b1674b3caba2257776bfad003601cc973d6d95e2bab113cd7f70be4e8309c8a34a8c2aab53d511576093be2f566d67552c85812070ded60528b863f414a1e15a768302fe0bfabd28ed46d6593f32f33a0c1c4168dea84e722251a6f231979e93c1ba7c30

A little busy right now.

Rich wrote:

> Stefan Claas <pollux@tilde.club> wrote:
> > Thanks for the code example.
> >
> >> Running this results in:
> >>
> >> OTP: f1c3
> >> Alice 'special' message: 0f2e
> >> Ciphertext: feed
> >
> > He he, so Alice crafts a message she can't read herself,
>
> Yes, doing anything like this to "craft" any one of the three pieces
> means one of the other pieces is going to look like gibberish.
>
> > but the ciphertext is readable for third parties. It would be cool
> > if there would be a real world usage scenario for this.
>
> Say you receive a purported encrypted message that reads thusly
> (assuming ASCII bytes):
>
> *1234567890ABCDEF01234567890ABCDEF0123456
>
> And you would like to "decrypt" it to read:
>
> The quick brown fox jumped over the lazy
>
> Why you might want to do this I can't say, perhaps to fool someone
> else who isn't very cryptographicly aware?

Yes, so that 3rd parties do not see that this is an encrypted message,
kind of steganography.
> So you just create an OTP pad as the bytewise XOR of each byte of the
> purported ciphertext with each byte of the desired decrypted text.
> I.e., you do:
>
> otp[i] = cipher[i] ^ desired_message[i] for i from 0 ...
> length(cipher)
>
> Then, you go to your not so knowledgable friend, indicating that you
> just received this message, and when you decrypt with "the pad" (not
> mentioning you fashioned "the pad" yourself) the message about the
> fox pops out.
>
> > Maybe a verifying scheme, like Alice submits a long hex key to Bob,
> > in that form, so that he knows the message comes from Alice if it
> > says 'the quick brown fox jumps ...'
>
> Not really a very safe way to 'verify' in that once someone
> learns/deduces the method, they can repeat with ease (i.e., the
> algorithm here has to be kept secret). At least a HMAC, provided
> Alice and Bob do in fact keep their shared key secret, is much harder
> to fake, even when Eve knows all about the algorithm.

Yes, understand, but if such a message would be posted anonymously,
probably only the receiver(s) know whats all about it.

Regards
Stefan
--
----Ed25519 Signature----
6a0eaa08046bba8dc871aa0b8efdc88737ae9e8687d310cb79e5f0329ae52b40
acd37e2d21cbfb7ca41095488a261f0c68031a0dea86e2c698a3f70c51581701

For your reference, records indicate that
Stefan Claas <pollux@tilde.club> wrote:

> He he, so Alice crafts a message she can't read herself, but the
> ciphertext is readable for third parties. It would be cool if there
> would be a real world usage scenario for this.

There are probably plenty. One obvious use is simply transforming one OTP
to another OTP, for whatever reason it might make sense to “refresh” or
“resync" the parties holding the OTP.

As an example, you can create a kind of dead man’s switch if you not only
exchange an OTP with someone, but also agree to XOR it with some commonly
available innocuous “message”, like a news story/video/podcast, or a nightly
build of some open source software, or pretty much any shared-but-non-secret
info. Access to the OTP alone does not then compromise all the secrets.

Another use might be to just flat out *lie* about the data format your
encrypted message is:

<https://en.wikipedia.org/wiki/Magic_number_(programming)#In_files>

I mean, yeah, you can certainly try hide the message in another *valid*
file format, but you can spice things up for the attacker by forcing them
to consider if the JPEG they have intercepted is corrupted, or was ever
even a JPEG at all! :-)

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

Doc O'Leary , wrote:

> For your reference, records indicate that
> Stefan Claas <pollux@tilde.club> wrote:
>
> > He he, so Alice crafts a message she can't read herself, but the
> > ciphertext is readable for third parties. It would be cool if there
> > would be a real world usage scenario for this.
>
> There are probably plenty. One obvious use is simply transforming
> one OTP to another OTP, for whatever reason it might make sense to
> “refresh” or “resync" the parties holding the OTP.
>
> As an example, you can create a kind of dead man’s switch if you not
> only exchange an OTP with someone, but also agree to XOR it with some
> commonly available innocuous “message”, like a news
> story/video/podcast, or a nightly build of some open source software,
> or pretty much any shared-but-non-secret info. Access to the OTP
> alone does not then compromise all the secrets.
>
> Another use might be to just flat out *lie* about the data format
> your encrypted message is:
>
> <https://en.wikipedia.org/wiki/Magic_number_(programming)#In_files>
>
> I mean, yeah, you can certainly try hide the message in another
> *valid* file format, but you can spice things up for the attacker by
> forcing them to consider if the JPEG they have intercepted is
> corrupted, or was ever even a JPEG at all! :-)

Thanks for the explanation, much appreciated! :-)

Regards
Stefan
--
----Ed25519 Signature----
5d8b1bcd6084543a05426e256fbaa12e44e570cd152fd6c8f61c26bb06519ed9
ea0107239bf7465654726af7f3158651d3bfeb1056d0ca709e48af8a4d279d0d

Chris M. Thomasson wrote:

> On 2/23/2024 10:59 AM, Stefan Claas wrote:
> > Stefan Claas wrote:
> >
> >> Gemini is an Internet Protocol, starting with gemini:// and a
> >> mixture of gopher and classic html.
> >
> > https://github.com/kr1sp1n/awesome-gemini
>
> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=19d672f834593b161ffb1338f77bd51aa5328ab1854b531f33d415ac79ddb154a85beacb0a155cb64b47e551cadf2ad22ad689920bcdc670d1283d337413b691cd1294db0a7ae44bf6e5a9aa3adc138d4a7e2807c48c6612b1674b3caba2257776bfad003601cc973d6d95e2bab113cd7f70be4e8309c8a34a8c2aab53d511576093be2f566d67552c85812070ded60528b863f414a1e15a768302fe0bfabd28ed46d6593f32f33a0c1c4168dea84e722251a6f231979e93c1ba7c30
>
> A little busy right now.
>

No Problem! Don't forget to sign my guestbook (Gästebuch),
when exploring Geminispace. ;-)

Regards
Stefan
--
----Ed25519 Signature----
2f610593c193e717c188b9cc56c8d99a724227c8f67107f41c1714bb54e9e7fc
60c9bb65e4c1ade36179980d8a4d560ea18e358af033d56f54d0fbcedb658f06

On 2/23/2024 1:16 PM, Stefan Claas wrote:
> Rich wrote:
>
>> Stefan Claas <pollux@tilde.club> wrote:
>>> Thanks for the code example.
>>>
>>>> Running this results in:
>>>>
>>>> OTP: f1c3
>>>> Alice 'special' message: 0f2e
>>>> Ciphertext: feed
>>>
>>> He he, so Alice crafts a message she can't read herself,
>>
>> Yes, doing anything like this to "craft" any one of the three pieces
>> means one of the other pieces is going to look like gibberish.
>>
>>> but the ciphertext is readable for third parties. It would be cool
>>> if there would be a real world usage scenario for this.
>>
>> Say you receive a purported encrypted message that reads thusly
>> (assuming ASCII bytes):
>>
>> *1234567890ABCDEF01234567890ABCDEF0123456
>>
>> And you would like to "decrypt" it to read:
>>
>> The quick brown fox jumped over the lazy
>>
>> Why you might want to do this I can't say, perhaps to fool someone
>> else who isn't very cryptographicly aware?
>
> Yes, so that 3rd parties do not see that this is an encrypted message,
> kind of steganography.
>
>> So you just create an OTP pad as the bytewise XOR of each byte of the
>> purported ciphertext with each byte of the desired decrypted text.
>> I.e., you do:
>>
>> otp[i] = cipher[i] ^ desired_message[i] for i from 0 ...
>> length(cipher)
>>
>> Then, you go to your not so knowledgable friend, indicating that you
>> just received this message, and when you decrypt with "the pad" (not
>> mentioning you fashioned "the pad" yourself) the message about the
>> fox pops out.
>>
>>> Maybe a verifying scheme, like Alice submits a long hex key to Bob,
>>> in that form, so that he knows the message comes from Alice if it
>>> says 'the quick brown fox jumps ...'
>>
>> Not really a very safe way to 'verify' in that once someone
>> learns/deduces the method, they can repeat with ease (i.e., the
>> algorithm here has to be kept secret). At least a HMAC, provided
>> Alice and Bob do in fact keep their shared key secret, is much harder
>> to fake, even when Eve knows all about the algorithm.
>
> Yes, understand, but if such a message would be posted anonymously,
> probably only the receiver(s) know whats all about it.

Bob: "The dog was walking itself when the sun was down yesterday." in a
public forum.

Alice reads that and just "knows" to meet Bob in a _specific_ park where
there are dogs off their leashes when the sun is up in 42 days from now...

Something like that? Never mind that Alice is under surveillance...

;^)

Chris M. Thomasson wrote:

> On 2/23/2024 1:16 PM, Stefan Claas wrote:
> > Rich wrote:
> >
> >> Stefan Claas <pollux@tilde.club> wrote:
> >>> Thanks for the code example.
> >>>
> >>>> Running this results in:
> >>>>
> >>>> OTP: f1c3
> >>>> Alice 'special' message: 0f2e
> >>>> Ciphertext: feed
> >>>
> >>> He he, so Alice crafts a message she can't read herself,
> >>
> >> Yes, doing anything like this to "craft" any one of the three
> >> pieces means one of the other pieces is going to look like
> >> gibberish.
> >>
> >>> but the ciphertext is readable for third parties. It would be
> >>> cool if there would be a real world usage scenario for this.
> >>
> >> Say you receive a purported encrypted message that reads thusly
> >> (assuming ASCII bytes):
> >>
> >> *1234567890ABCDEF01234567890ABCDEF0123456
> >>
> >> And you would like to "decrypt" it to read:
> >>
> >> The quick brown fox jumped over the lazy
> >>
> >> Why you might want to do this I can't say, perhaps to fool someone
> >> else who isn't very cryptographicly aware?
> >
> > Yes, so that 3rd parties do not see that this is an encrypted
> > message, kind of steganography.
> >
> >> So you just create an OTP pad as the bytewise XOR of each byte of
> >> the purported ciphertext with each byte of the desired decrypted
> >> text. I.e., you do:
> >>
> >> otp[i] = cipher[i] ^ desired_message[i] for i from 0 ...
> >> length(cipher)
> >>
> >> Then, you go to your not so knowledgable friend, indicating that
> >> you just received this message, and when you decrypt with "the
> >> pad" (not mentioning you fashioned "the pad" yourself) the message
> >> about the fox pops out.
> >>
> >>> Maybe a verifying scheme, like Alice submits a long hex key to
> >>> Bob, in that form, so that he knows the message comes from Alice
> >>> if it says 'the quick brown fox jumps ...'
> >>
> >> Not really a very safe way to 'verify' in that once someone
> >> learns/deduces the method, they can repeat with ease (i.e., the
> >> algorithm here has to be kept secret). At least a HMAC, provided
> >> Alice and Bob do in fact keep their shared key secret, is much
> >> harder to fake, even when Eve knows all about the algorithm.
> >
> > Yes, understand, but if such a message would be posted anonymously,
> > probably only the receiver(s) know whats all about it.
>
> Bob: "The dog was walking itself when the sun was down yesterday." in
> a public forum.
>
> Alice reads that and just "knows" to meet Bob in a _specific_ park
> where there are dogs off their leashes when the sun is up in 42 days
> from now...
>
> Something like that? Never mind that Alice is under surveillance...

Yes, that would be nice, if a software implementation for that exists.

One the other side, you can hide OTP messages in text, like this:

Create your OPT message, consisting of digits, like usual. Once done
create a harmless story, with a couple of sentences. The word count
of each sentence represents a digit in the OTP message.

Once Bob receives the story from Alice he simple counts the words in
each sentence and writes down the digits, so that he later can decrypt,
with the exchanged pads, the story.

You can let AI, like Bing, write the stories and tell it how many words
per sentence must be in the story. I did this once successfully. :-)

Regards
Stefan
--
----Ed25519 Signature----
3333210c0ee5a760d6f03d01d5717f1d273f6e479f6db89a69b12b9b8d8a6d7b
3c082fb637cef297ee3b2bcb664f24ce4dded79dc2f9c5419a31ce41c297130d

Richard Harnden wrote:

> > Create your OPT message, consisting of digits, like usual. Once done
> > create a harmless story, with a couple of sentences. The word count
> > of each sentence represents a digit in the OTP message.
> >
> > Once Bob receives the story from Alice he simple counts the words in
> > each sentence and writes down the digits, so that he later can
> > decrypt, with the exchanged pads, the story.
> >
> > You can let AI, like Bing, write the stories and tell it how many
> > words per sentence must be in the story. I did this once
> > successfully. :-)
> >
>
> That isn't random, so isn't a OTP at all.

Excuse me, you create random pads as usual and the OTP messages as
usual, which is random and from the ciphertext digits you create with
the help of AI your story.

Regards
Stefan
--
----Ed25519 Signature----
1c4087b8b9c1a9574db57d25a7af79286ee494146cce2de510a325bc1fd4ce17
8d8d8d68442dc1ca5e6bb4c2861981293318092685fd6ff39b9a47214e22410d

Stefan Claas wrote:

> Richard Harnden wrote:
>
> > > Create your OPT message, consisting of digits, like usual. Once
> > > done create a harmless story, with a couple of sentences. The
> > > word count of each sentence represents a digit in the OTP message.
> > >
> > > Once Bob receives the story from Alice he simple counts the words
> > > in each sentence and writes down the digits, so that he later can
> > > decrypt, with the exchanged pads, the story.
> > >
> > > You can let AI, like Bing, write the stories and tell it how many
> > > words per sentence must be in the story. I did this once
> > > successfully. :-)
> > >
> >
> > That isn't random, so isn't a OTP at all.
>
> Excuse me, you create random pads as usual and the OTP messages as
> usual, which is random and from the ciphertext digits you create with
> the help of AI your story.

<https://rijmenants.blogspot.com/2014/12/wps-secret-numbers-in-letters.html>

Regards
Stefan
--
----Ed25519 Signature----
dc19ac1817f25ebe02c54514b64d911a701c338e4b3bd618e47d37756ca73a31
3c6c761eb5b79ed2b00b11af5ab46ed4773cba010c572c069d5ff838d2578d0c