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 ...)?
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]
Running this results in:
OTP: f1c3
Alice 'special' message: 0f2e
Ciphertext: feed
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 ...'
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?
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.
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.
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! :-)
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. :-)
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...
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.
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>
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.
On 25/02/2024 17:59, Stefan Claas wrote:
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>
I'm not sure what you're trying to do, then.
Combining a OTP with steganography is just going to make the pad much
longer. And the reason OTPs aren't used is that they are difficult
to securely exchange, mostly because they are too long.
Aren't you making the problem worse?
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.
Richard Harnden wrote:
On 25/02/2024 17:59, Stefan Claas wrote:
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>
I'm not sure what you're trying to do, then.
Combining a OTP with steganography is just going to make the pad much
longer. And the reason OTPs aren't used is that they are difficult
to securely exchange, mostly because they are too long.
Aren't you making the problem worse?
Ok, I must admit that the OP's thread was about 'Patterns', but I
replied to Chris, showing another way.
I somehow doubt that we can create proper (i.e. long) cipher text
consisting of a pattern, shown by the OP, in form of software and
that it can be reused with other plain code messages. I can be wrong
of course and would like to see such a solution.
[...]
Therefore, given the lack of information in the doctors initial post,
a reasonable "possible encryption algorithm" to 'create' that output
would be an OTP with specially crafted message or pad.
Rich wrote:
[...]
Therefore, given the lack of information in the doctors initial
post, a reasonable "possible encryption algorithm" to 'create' that
output would be an OTP with specially crafted message or pad.
Yes, since the 'Doctor gave little info, I leave it as it is and
concentrate on other things, but because the Subject: is Patterns,
I have one for the Doctor, he can try to decode. :-)
🔵🔴🔵🔵🔵🔲🔴🔵🔵🔵🔴🔲🔴🔵🔴🔴🔴🔲🔴🔵🔴🔴🔵🔲🔵🔵🔴🔴🔵🔲🔴🔴🔴🔵🔴
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 30:32:45 |
| Calls: | 9,740 |
| Calls today: | 30 |
| Files: | 13,741 |
| Messages: | 6,183,048 |
| Posted today: | 2 |