Hi all,

while playing with OTPs I thought that it would be nice
if foreign languages could be used as clear code.

I used 'Hello World.' in Chinese, converted it to hex
and then to decimal.

Here is the clear code:

11876 89806 73946 99030 57513
06009 70323 22

The pad:

68238 63972 92381 95246 41836
78127 58141 10064 13267 28473
12708 72549 92268 64828 08986
16748 83548 90223 98025 11923
00629 13164 30531 58883 04983
26340 01769 44902 11429 74915
93683 48677 01747 16699 49779
13120 31250 40235 50756 22868
43604 62434 04077 07160 97839
30798 93693 54202 26094 23219

The cipher text:

68238 74748 71187 68182 30866
25630 54140 80387 35

The modulo 10 addition starts at the second group,
while the first group in the cipher text is for the
pad used.

Hope you like the idea.

I know OTPs should be used with pencil and paper,
but when used on a secure offline computer, it might
be an option too.

Regards
Stefan
--
----Ed25519 Signature----
c642635988371708a9d7ed043857092a46654547a180fd669329d29e024379c3
dee3d91ef870c608b5fae5fa4d1274c6c0068fa739f18a89d95afa9e82f5c001

On 12/13/23 10:05, Stefan Claas wrote:
> I used 'Hello World.' in Chinese, converted it to hex
> and then to decimal.

I think the Achilles heal of your idea is using non-random text as the seed.

So I wouldn't consider it cryptographically strong. But I do see value
in things that aren't cryptographically strong. Sometimes all you
really need is something to keep miscreants out.

Grant. . . .

On 13/12/2023 16:05, Stefan Claas wrote:

> I know OTPs should be used with pencil and paper,
> but when used on a secure offline computer, it might
> be an option too.

The late, and sadly missed, Len Sassaman used to distribute large
real-random OTPs on CDs and DVDs.

You could use them for anything you liked, but you had to write the code
first ... and then he had to write the decode ...

:)

Peter Fairbrother

On 12/13/2023 1:16 PM, Peter Fairbrother wrote:
> On 13/12/2023 16:05, Stefan Claas wrote:
>
>> I know OTPs should be used with pencil and paper,
>> but when used on a secure offline computer, it might
>> be an option too.
>
> The late, and sadly missed, Len Sassaman used to distribute large
> real-random OTPs on CDs and DVDs.
>
> You could use them for anything you liked, but you had to write the code
> first ... and then he had to write the decode ...
>
> :)

Indeed! ;^D

On 12/13/2023 2:24 PM, Chris M. Thomasson wrote:
> On 12/13/2023 1:16 PM, Peter Fairbrother wrote:
>> On 13/12/2023 16:05, Stefan Claas wrote:
>>
>>> I know OTPs should be used with pencil and paper,
>>> but when used on a secure offline computer, it might
>>> be an option too.
>>
>> The late, and sadly missed, Len Sassaman used to distribute large
>> real-random OTPs on CDs and DVDs.
>>
>> You could use them for anything you liked, but you had to write the
>> code first ... and then he had to write the decode ...
>>
>> :)
>
> Indeed! ;^D
>

I have some random numbers for ya. I swear I never looked at them...
Cough...

Grant Taylor wrote:

> On 12/13/23 10:05, Stefan Claas wrote:
> > I used 'Hello World.' in Chinese, converted it to hex
> > and then to decimal.
>
> I think the Achilles heal of your idea is using non-random text as
> the seed.
>
> So I wouldn't consider it cryptographically strong. But I do see
> value in things that aren't cryptographically strong. Sometimes all
> you really need is something to keep miscreants out.

The Chinese text is the clear code, which then gets encrypted, with the
pad (created from random numbers, with Golang's crypto/rand)

If this is carried out on an offline computer (shielded[1]) this should
be ok, I guess.

To create real random numbers, I was thinking to 3D print a 'violin'[2]

[1] <https://www.youtube.com/watch?v=d8HvGvOT6Pg>
[2]
<https://scienceblogs.de/klausis-krypto-kolumne/2016/11/16/how-a-crypto-mystery-from-the-cold-war-was-solved-or-was-it/>

Regards
Stefan
--
----Ed25519 Signature----
2dbdf2ff533b4082456d23dd96b2d102de86cf23a997e1e35d67f75500673be5
a75a4a3eee9dd7061b6821ad187539a9ae71533ce1f3fd1cf1854e5196e9fc03

Peter Fairbrother wrote:

> On 13/12/2023 16:05, Stefan Claas wrote:
>
> > I know OTPs should be used with pencil and paper,
> > but when used on a secure offline computer, it might
> > be an option too.
>
> The late, and sadly missed, Len Sassaman used to distribute large
> real-random OTPs on CDs and DVDs.

You write 'real'. Do you know how he did that, like getting random data
from random.org, or an hardware device?
>
> You could use them for anything you liked, but you had to write the
> code first ... and then he had to write the decode ...
>
> :)

I already created software for OTP usage, in Golang. :-)

Regards
Stefan
--
----Ed25519 Signature----
3cc534c1965b893695bfccde59051914efe8269518862638ec3d2a925444e9f3
ee1c0306a37cc73a5e3645ac14e9e65a004ee32c809259ade48156e7a261bb03

Chris M. Thomasson wrote:

> On 12/13/2023 2:24 PM, Chris M. Thomasson wrote:
> > On 12/13/2023 1:16 PM, Peter Fairbrother wrote:
> >> On 13/12/2023 16:05, Stefan Claas wrote:
> >>
> >>> I know OTPs should be used with pencil and paper,
> >>> but when used on a secure offline computer, it might
> >>> be an option too.
> >>
> >> The late, and sadly missed, Len Sassaman used to distribute large
> >> real-random OTPs on CDs and DVDs.
> >>
> >> You could use them for anything you liked, but you had to write
> >> the code first ... and then he had to write the decode ...
> >>
> >> :)
> >
> > Indeed! ;^D
> >
>
> I have some random numbers for ya. I swear I never looked at them...
> Cough...

He he. And I have the software to create random pads. You can look
at the source code. It uses Golang's crypto/rand, to create the numbers
or letters.

https://github.com/stefanclaas/pads

Regards
Stefan
--
----Ed25519 Signature----
8d891486fe5ef962e1363d76d2a65fb4f9821b95fe0e8c01b9ea617aabc0b804
9b52ec7cccd63947a03aa491e9152632f7e0aaac57c12dcf28aa6e23143f750a

On 14/12/2023 09:25, Stefan Claas wrote:
> Peter Fairbrother wrote:
>
>> On 13/12/2023 16:05, Stefan Claas wrote:
>>
>>> I know OTPs should be used with pencil and paper,
>>> but when used on a secure offline computer, it might
>>> be an option too.
>>
>> The late, and sadly missed, Len Sassaman used to distribute large
>> real-random OTPs on CDs and DVDs.
>
> You write 'real'. Do you know how he did that, like getting random data
> from random.org, or an hardware device?

He did tell me, but I can't remember exactly.

Len was a pretty good cryptographer though, and I remember thinking at
the time that he had done it right - which would probably mean something
hardware and quantum noisy.

[they were in pairs, he kept one copy and the recipient got the other.
only good for talking to Len]

Peter F

Peter Fairbrother wrote:

> On 14/12/2023 09:25, Stefan Claas wrote:
> > Peter Fairbrother wrote:
> >
> >> On 13/12/2023 16:05, Stefan Claas wrote:
> >>
> >>> I know OTPs should be used with pencil and paper,
> >>> but when used on a secure offline computer, it might
> >>> be an option too.
> >>
> >> The late, and sadly missed, Len Sassaman used to distribute large
> >> real-random OTPs on CDs and DVDs.
> >
> > You write 'real'. Do you know how he did that, like getting random
> > data from random.org, or an hardware device?
>
> He did tell me, but I can't remember exactly.
>
> Len was a pretty good cryptographer though, and I remember thinking
> at the time that he had done it right - which would probably mean
> something hardware and quantum noisy.
>
> [they were in pairs, he kept one copy and the recipient got the
> other. only good for talking to Len]

Ah, ok. Thanks for the info, much appreciated.

Regards
Stefan
--
----Ed25519 Signature----
f06435973fc9eaa771fe4ba09f7564056a3b5566a776d9b599585c5f0a2ea79a
b3c83e8599c0c40c2580333d0fb8764225cd6cabdd4d7f9d807b560bd00d4305

Stefan Claas <stefan.claas@iris.to> wrote:
> Grant Taylor wrote:
>
>> On 12/13/23 10:05, Stefan Claas wrote:
>> > I used 'Hello World.' in Chinese, converted it to hex
>> > and then to decimal.
>>
>> I think the Achilles heal of your idea is using non-random text as
>> the seed.
>>
>> So I wouldn't consider it cryptographically strong. But I do see
>> value in things that aren't cryptographically strong. Sometimes all
>> you really need is something to keep miscreants out.
>
> The Chinese text is the clear code, which then gets encrypted, with the
> pad (created from random numbers, with Golang's crypto/rand)

In which case it is likely created from "psudeo-random numbers",
depending upon how Golang's crypto/rand is implemented.

> If this is carried out on an offline computer (shielded[1]) this should
> be ok, I guess.

Depends upon who you are defending against. Against your noisy
neighbor who is not a cryptographer, this is likely more than enough.
Against the NSA, it may not be enough.

Stefan Claas <stefan.claas@iris.to> wrote:
> Chris M. Thomasson wrote:
>> I have some random numbers for ya. I swear I never looked at
>> them... Cough...
>
> He he. And I have the software to create random pads. You can look
> at the source code. It uses Golang's crypto/rand, to create the
> numbers or letters.

What is the implementation of 'crypto/rand'?

Rich wrote:

> Stefan Claas <stefan.claas@iris.to> wrote:
> > Chris M. Thomasson wrote:
> >> I have some random numbers for ya. I swear I never looked at
> >> them... Cough...
> >
> > He he. And I have the software to create random pads. You can
> > look at the source code. It uses Golang's crypto/rand, to create
> > the numbers or letters.
>
> What is the implementation of 'crypto/rand'?

Please have a look:

https://pkg.go.dev/crypto/rand

Regards
Stefan
--
----Ed25519 Signature----
8b33b0df45eb883e597b74893f09130148a6aec955be659751919219386c260f
54033f8bb0a99c686f38e46dce728ab18dc2d476c3c41f02820129f859bc1e0c

Stefan Claas <stefan.claas@iris.to> wrote:
> Rich wrote:
>
>> Stefan Claas <stefan.claas@iris.to> wrote:
>> > Chris M. Thomasson wrote:
>> >> I have some random numbers for ya. I swear I never looked at
>> >> them... Cough...
>> >
>> > He he. And I have the software to create random pads. You can
>> > look at the source code. It uses Golang's crypto/rand, to create
>> > the numbers or letters.
>>
>> What is the implementation of 'crypto/rand'?
>
> Please have a look:
>
> https://pkg.go.dev/crypto/rand

The docs say this:

On Linux, FreeBSD, Dragonfly, NetBSD and Solaris, Reader uses
getrandom(2) if available, /dev/urandom otherwise. On OpenBSD and
macOS, Reader uses getentropy(2). On other Unix-like systems,
Reader reads from /dev/urandom. On Windows systems, Reader uses
the ProcessPrng API. On JS/Wasm, Reader uses the Web Crypto API.
On WASIP1/Wasm, Reader uses random_get from wasi_snapshot_preview1.

So it is not just a chosen psudeo-random number generator algorithm,
but is using the various kernel's randomness generation facilities.

On 12/14/2023 8:50 AM, Rich wrote:
> Stefan Claas <stefan.claas@iris.to> wrote:
>> Chris M. Thomasson wrote:
>>> I have some random numbers for ya. I swear I never looked at
>>> them... Cough...
>>
>> He he. And I have the software to create random pads. You can look
>> at the source code. It uses Golang's crypto/rand, to create the
>> numbers or letters.
>
> What is the implementation of 'crypto/rand'?

I hope its not something akin to this damn thing!

https://groups.google.com/g/comp.lang.c++/c/7u_rLgQe86k/m/fYU9SnuAFQAJ

;^o

Stefan Claas wrote:

> The cipher text:
>
> 68238 74748 71187 68182 30866
> 25630 54140 80387 35

The nice thing about digits is, that you can convert them to images. :-)
My humble approach uses ten colors for the digits 0-9 and each colored
square is 8x8 pixels in size.

I created a little program, which takes a long integer string, without
spaces, and creates a .png file of it. The image size is 320 pixels,
for width and depending on the message size the height varies.

The above cipher text looks like this:

https://postimg.cc/CZxYfPd9

Regards
Stefan
--
----Ed25519 Signature----
88649b111e156896afdbf8d7d66c72bb3479a3896f6f696a1258e108369845d8
519ff092a18a9b1f5722d28ea3be6d74f1d64824def689980d95f0da588ffc0b

Stefan Claas wrote:

> Stefan Claas wrote:
>
> > The cipher text:
> >
> > 68238 74748 71187 68182 30866
> > 25630 54140 80387 35
>
> The nice thing about digits is, that you can convert them to images.
> :-) My humble approach uses ten colors for the digits 0-9 and each
> colored square is 8x8 pixels in size.
>
> I created a little program, which takes a long integer string, without
> spaces, and creates a .png file of it. The image size is 320 pixels,
> for width and depending on the message size the height varies.
>
> The above cipher text looks like this:
>
> https://postimg.cc/CZxYfPd9

Forgot to mention, you can of course decode the image back to its
original content. https://github.com/stefanclaas/d2i

Maybe something for you Chris, to look at, because you do computer
graphics programming. ;-)

Regards
Stefan
--
----Ed25519 Signature----
76c5ee0184b8a94ba6c0a6d14aef3df86a3c838cdfb5e8a551092bf0c92a22c3
098d11ba4029e8bc75e193d00e4476e784a02f6321504a8896753a45ae39610e

On 12/16/2023 9:19 AM, Stefan Claas wrote:
> Stefan Claas wrote:
>
>> Stefan Claas wrote:
>>
>>> The cipher text:
>>>
>>> 68238 74748 71187 68182 30866
>>> 25630 54140 80387 35
>>
>> The nice thing about digits is, that you can convert them to images.
>> :-) My humble approach uses ten colors for the digits 0-9 and each
>> colored square is 8x8 pixels in size.
>>
>> I created a little program, which takes a long integer string, without
>> spaces, and creates a .png file of it. The image size is 320 pixels,
>> for width and depending on the message size the height varies.
>>
>> The above cipher text looks like this:
>>
>> https://postimg.cc/CZxYfPd9
>
> Forgot to mention, you can of course decode the image back to its
> original content. https://github.com/stefanclaas/d2i
>
> Maybe something for you Chris, to look at, because you do computer
> graphics programming. ;-)

I need to find an old post of mine here. Basically it would use a single
color channel to encode bytes, dead simple. It would simply map a byte
into a color. The fun part was to try to hide a fractal in the noise and
see if anybody could visually notice it.

So, all bytes could be shades of red, ect... It could be decoded by
reading the bytes. If the image was compressed, well, these bytes no
longer worked! Take notice of the little thumbnail image this creates:

http://funwithfractals.atspace.cc/ffe

Hit the encryption button over and over again and notice how the
thumbnail changes. This is just fun to me.

Stefan Claas <stefan.claas@iris.to> wrote:
> Stefan Claas wrote:
>
>> The cipher text:
>>
>> 68238 74748 71187 68182 30866
>> 25630 54140 80387 35
>
> The nice thing about digits is, that you can convert them to images. :-)
> My humble approach uses ten colors for the digits 0-9 and each colored
> square is 8x8 pixels in size.

You don't need "digits" to encode things to images. Provided you are
not using a lossy compression algorithm then you can just insert any
old binary data in as the pixels, and get it back later just as you put
it in.

The resulting 'image' will look like random noise when viewed as an
image.

If you want larger "color blocks" (for ease of decoding by scanning or
for resistance to 'lossy' compression algorithms) then you just need to
pick a set of colors (if you pick powers of two sized sets it makes
things easer). So you pick sixteen colors, then every four bits of
your binary data determines which of your sixteen colors is used for
the next "large block" and you just output the proper image bytes to
make the large block.

On 17/12/2023 05:42, Rich wrote:
> Stefan Claas <stefan.claas@iris.to> wrote:
>> Stefan Claas wrote:
>>
>>> The cipher text:
>>>
>>> 68238 74748 71187 68182 30866
>>> 25630 54140 80387 35
>>
>> The nice thing about digits is, that you can convert them to images. :-)
>> My humble approach uses ten colors for the digits 0-9 and each colored
>> square is 8x8 pixels in size.
>
> You don't need "digits" to encode things to images. Provided you are
> not using a lossy compression algorithm then you can just insert any
> old binary data in as the pixels, and get it back later just as you put
> it in.
>
> The resulting 'image' will look like random noise when viewed as an
> image.
>
> If you want larger "color blocks" (for ease of decoding by scanning or
> for resistance to 'lossy' compression algorithms) then you just need to
> pick a set of colors (if you pick powers of two sized sets it makes
> things easer). So you pick sixteen colors, then every four bits of
> your binary data determines which of your sixteen colors is used for
> the next "large block" and you just output the proper image bytes to
> make the large block.
>

Or just encode a .jpeg

Peter F

Chris M. Thomasson wrote:

> On 12/16/2023 9:19 AM, Stefan Claas wrote:

> > Maybe something for you Chris, to look at, because you do computer
> > graphics programming. ;-)
>
> I need to find an old post of mine here. Basically it would use a
> single color channel to encode bytes, dead simple. It would simply
> map a byte into a color. The fun part was to try to hide a fractal in
> the noise and see if anybody could visually notice it.

Nice, I would like to try that out. :-)
> So, all bytes could be shades of red, ect... It could be decoded by
> reading the bytes. If the image was compressed, well, these bytes no
> longer worked! Take notice of the little thumbnail image this creates:
>
> http://funwithfractals.atspace.cc/ffe
>
> Hit the encryption button over and over again and notice how the
> thumbnail changes. This is just fun to me.

Yes, I remember this program. Really nice!

Regards
Stefan
--
----Ed25519 Signature----
725a3bf20c1b7d3137d8b3faa8985a19886bf44f0ecd7e3d3726a7c5cc682f89
a146f52610cf13c3a6b36fa42bc77416d32c41e7188e60d51695b3455c55a309

Rich wrote:

> Stefan Claas <stefan.claas@iris.to> wrote:
> > Stefan Claas wrote:
> >
> >> The cipher text:
> >>
> >> 68238 74748 71187 68182 30866
> >> 25630 54140 80387 35
> >
> > The nice thing about digits is, that you can convert them to
> > images. :-) My humble approach uses ten colors for the digits 0-9
> > and each colored square is 8x8 pixels in size.
>
> You don't need "digits" to encode things to images. Provided you are
> not using a lossy compression algorithm then you can just insert any
> old binary data in as the pixels, and get it back later just as you
> put it in.
>
> The resulting 'image' will look like random noise when viewed as an
> image.

I have such a program (file2png, from GitHub).

> If you want larger "color blocks" (for ease of decoding by scanning
> or for resistance to 'lossy' compression algorithms) then you just
> need to pick a set of colors (if you pick powers of two sized sets it
> makes things easer). So you pick sixteen colors, then every four
> bits of your binary data determines which of your sixteen colors is
> used for the next "large block" and you just output the proper image
> bytes to make the large block.

Thanks for the suggestion. I may look into this. The reason why I
created my version, of an encoder/decoder was, to easily convert
OTP messages, consisting of digits and with a nice color scheme.

Regards
Stefan
--
----Ed25519 Signature----
1394d28ec5c950e1ef51115c990945635c4532849600062a2ca2bf4dcc73eb5b
b2019098e86217d0593fd9e187f8e9735133a634e23241202eb2ee05ab1f0909

Stefan Claas wrote:

> Stefan Claas wrote:
>
> > Stefan Claas wrote:
> >
> > > The cipher text:
> > >
> > > 68238 74748 71187 68182 30866
> > > 25630 54140 80387 35
> >
> > The nice thing about digits is, that you can convert them to images.
> > :-) My humble approach uses ten colors for the digits 0-9 and each
> > colored square is 8x8 pixels in size.
> >
> > I created a little program, which takes a long integer string,
> > without spaces, and creates a .png file of it. The image size is
> > 320 pixels, for width and depending on the message size the height
> > varies.
> >
> > The above cipher text looks like this:
> >
> > https://postimg.cc/CZxYfPd9
>
> Forgot to mention, you can of course decode the image back to its
> original content. https://github.com/stefanclaas/d2i
>
> Maybe something for you Chris, to look at, because you do computer
> graphics programming. ;-)

Here is a C version. Must be compiled with lodepng.c and lodepng.h
https://lodev.org/lodepng/

// d2i - decimal to image. Converts a long decimal string to .png image

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>
#include "lodepng.h"

#define BLOCK_WIDTH 8
#define MAX_IMAGE_WIDTH 320

typedef struct {
uint8_t r, g, b, a;
} RGBA;

// Define the colors for the numbers 0-9.
const RGBA colors[] = {
{230, 25, 75, 255}, // 0: Red
{245, 130, 49, 255}, // 1: Orange
{255, 225, 25, 255}, // 2: Yellow
{191, 239, 69, 255}, // 3: Lime
{60, 180, 75, 255}, // 4: Green
{66, 212, 244, 255}, // 5: Cyan
{67, 99, 216, 255}, // 6: Blue
{145, 30, 180, 255}, // 7: Purple
{240, 50, 230, 255}, // 8: Magenta
{169, 160, 169, 255} // 9: Grey
};

void encode(const char *filename) {
// Read the number string from the standard input.
char numbers[MAX_IMAGE_WIDTH * BLOCK_WIDTH];
fgets(numbers, sizeof(numbers), stdin);
numbers[strcspn(numbers, "\n")] = '\0'; // Remove the newline
character.

// Calculate the number of rows needed.
int numRows = (strlen(numbers) * BLOCK_WIDTH + MAX_IMAGE_WIDTH - 1)
/ MAX_IMAGE_WIDTH;

// Create a new image.
RGBA *img = (RGBA *)malloc(MAX_IMAGE_WIDTH * numRows * BLOCK_WIDTH
* sizeof(RGBA));

// Fill the image with the corresponding colors.
for (int i = 0; i < strlen(numbers); i++) {
// Convert the number to a color.
int n = numbers[i] - '0';
for (int x = (i % (MAX_IMAGE_WIDTH / BLOCK_WIDTH)) *
BLOCK_WIDTH; x < (i % (MAX_IMAGE_WIDTH / BLOCK_WIDTH) + 1) *
BLOCK_WIDTH; x++) { for (int y = (i / (MAX_IMAGE_WIDTH /
BLOCK_WIDTH)) * BLOCK_WIDTH; y < ((i / (MAX_IMAGE_WIDTH /
BLOCK_WIDTH)) + 1) * BLOCK_WIDTH; y++) { img[x + y *
MAX_IMAGE_WIDTH] = colors[n]; } } }

// Save the image as a .png file using lodepng.
if (lodepng_encode32_file(filename, (unsigned char *)img,
MAX_IMAGE_WIDTH, numRows * BLOCK_WIDTH) != 0) { fprintf(stderr,
"Error writing PNG file\n"); exit(EXIT_FAILURE);
}

free(img);
}

void decode(const char *filename) {
// Open the .png file.
unsigned char *imgIn;
size_t width, height;
if (lodepng_decode32_file(&imgIn, &width, &height, filename) != 0) {
fprintf(stderr, "Error opening or decoding image file\n");
exit(EXIT_FAILURE);
}

// Decode the colors back into numbers and print in a single line.
for (size_t y = 0; y < height; y += BLOCK_WIDTH) {
for (size_t x = 0; x < width; x += BLOCK_WIDTH) {
RGBA c = *((RGBA *)(imgIn + 4 * (x + y * width)));
for (size_t j = 0; j < sizeof(colors) / sizeof(colors[0]);
j++) { if (c.r == colors[j].r && c.g == colors[j].g && c.b ==
colors[j].b) { printf("%lu", j);
break;
}
}
}
}

// Add a newline at the end to separate the prompt.
printf("\n");

free(imgIn);
}

int main(int argc, char *argv[]) {
if (argc < 3 || (strcmp(argv[1], "-e") != 0 && strcmp(argv[1],
"-d") != 0)) { fprintf(stderr, "Please enter either -e for encoding or
-d for decoding.\n"); return EXIT_FAILURE;
}

if (strcmp(argv[1], "-e") == 0) {
encode(argv[2]);
} else {
decode(argv[2]);
}

return EXIT_SUCCESS;
}

Regards
Stefan
--
----Ed25519 Signature----
ff71bd199df152306e68d48d8c9757fc3447f7e8abe4a017f9861ca8193416ca
6a7d9cb89a0bf2894a145b8a45c936b33f1280843a9f5648bc1e08dd2d9c2004

Stefan Claas wrote:

> Here is a C version. Must be compiled with lodepng.c and lodepng.h
> https://lodev.org/lodepng/
>
> // d2i - decimal to image. Converts a long decimal string to .png
> image
>
> [...]

https://postimg.cc/LhDy3WXZ

Then simply convert decimal to hex and hex back to the message, with
xxd or something else.

Regards
Stefan
--
----Ed25519 Signature----
3870cd9bdbbe6da6a0d2dc541a2058c274786ac2103a2fa126bd9d29157bf606
120e1431ce51d6e35fbd89e816e58dca464c356c8adf9e9098e64dfbc21a990f