Stefan Claas wrote:
> Chris M. Thomasson wrote:
> > On 1/5/2025 3:06 PM, Stefan Claas wrote:
> > > Chris M. Thomasson wrote:
> > [...]
> > > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> > > and see if you can get the *original* data back. The sci.crypt community
> > > and me of course would appreciate your help very much!
> >
> > Still, try this:
> >
> > Upload a PNG to X and/or FB. Copy the image, download the image from
> > them after its up on their site. Do a file compare on it wrt your
> > original source PNG. Are the exactly the same?
>
> On X they are the same, once downloaded, which a 'diff' shows. ;-)

BTW. I come to the conclusion that it is best to use 'age' without
the -a option and then my file2png program ... This allows one to
encrypt any kind of data and convert it as valid noise .png image,
for X and other online usage. The advantage of 'age' is that it
uses public key cryptography or symmetric encryption. Better not
to invent the wheel twice. Anyways interesting thread ... :-)

--
Regards
Stefan

Stefan Claas wrote:
> Stefan Claas wrote:
> > Chris M. Thomasson wrote:
> > > On 1/5/2025 3:06 PM, Stefan Claas wrote:
> > > > Chris M. Thomasson wrote:
> > > [...]
> > > > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> > > > and see if you can get the *original* data back. The sci.crypt community
> > > > and me of course would appreciate your help very much!
> > >
> > > Still, try this:
> > >
> > > Upload a PNG to X and/or FB. Copy the image, download the image from
> > > them after its up on their site. Do a file compare on it wrt your
> > > original source PNG. Are the exactly the same?
> >
> > On X they are the same, once downloaded, which a 'diff' shows. ;-)
>
> BTW. I come to the conclusion that it is best to use 'age' without
> the -a option and then my file2png program ... This allows one to
> encrypt any kind of data and convert it as valid noise .png image,
> for X and other online usage. The advantage of 'age' is that it
> uses public key cryptography or symmetric encryption. Better not
> to invent the wheel twice. Anyways interesting thread ... :-)

And plug-ins for 'age' exists, which allows Yubikey or TPM usage. :-)

--
Regards
Stefan

Stefan Claas <pollux@tilde.club> wrote:
> Rich wrote:
>> Stefan Claas <pollux@tilde.club> wrote:
>> > Rich wrote:
>> > > Stefan Claas <pollux@tilde.club> wrote:
>> > > > Stefan Claas wrote:
>> > > > > Rich wrote:
>> > > > > > Stefan Claas <pollux@tilde.club> wrote:
>> > > > > > > Rich wrote:
>> > > > > > >
>> > > > > > > > If instead you mean some kind of "special, PNG aware,
>> > > > > > > > encryptor that only encrypted the bitmap data of a PNG",
>> > > > > > > > but left the file as otherwise a proper PNG image
>> > > > > > > > structure, then that is slightly tricky (and an algorithm
>> > > > > > > > that is only useful for PNG's alone).
>> > > > > > >
>> > > > > > > Yes, this is what I mean.
>> > > > > >
>> > > > > > Which brings up the question of: why?
>> > > > > >
>> > > > > > Why go to the trouble to create an encryptor that is
>> > > > > > specalized for just encrypting the internal bitmap data within
>> > > > > > a PNG, leaving the rest as a PNG file, when a generic "byte
>> > > > > > stream" encryptor will encrypt the entire PNG with no extra
>> > > > > > effort?
>> > > > >
>> > > > > To make more content as allowed postable on social media, like
>> > > > > X.
>> > > >
>> > > > I.e, first you put data with file2png in a .png and then encrypt
>> > > > it to finally post it. I can do this now with my xorpic program,
>> > > > but I thought a solution with AES-GCM or XChaCha20+ploy1305 is
>> > > > better.
>> > >
>> > > The "path" I outlined in my previous post, where you utilize the
>> > > netpbm image format as your 'intermediary' would allow you to use
>> > > any generic encryption routine you like, while also allowing you to
>> > > convert the encrypted binary data to/from an image format of your
>> > > choice (well, your choice within the set of other formats for which
>> > > NetPBM has to/from converters available).
>> > >
>> > > This frees you from having to understand the internal structure of
>> > > the various image formats. You just work with the netpbm format (a
>> > > raw binary bit/pixel block) for the encrypt/decrypt/padding
>> > > operations, and delegate all the "image format" complexity to the
>> > > netpbm library.
>> >
>> > Thank you! My ppmenc tool works nicely, here are the test images:
>> >
>> > https://jmp.sh/HZM9ML9f
>> >
>> > The big problem I face when converting the encryypted image to .png
>> > and back a diff shows a difference and the decryption fails.
>> >
>> > Maybe someone can figure out what to do, so that a converted .ppm can
>> > be posted online , for viewers/readers and then can be converted back
>> > to the original .ppm, which shows no difference.
>>
>> We can't read your mind over Usenet so can you show how you converted
>> the encrypted image to a png and back.
>>
>
> I used Gimp with compression set to 0 and the netbmp tools.

"compression set to 0" -- meaningless with ppm, there is no
'compression' for any ppm image format. The only options GIMP offers
for "ppm" files is "RAW" vs "ASCII".

I still am unable to read your mind and divine how you converted the
ppm to a png. What exact command did you run?

Stefan Claas <pollux@tilde.club> wrote:
> *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> and see if you can get the *original* data back. The sci.crypt community
> and me of course would appreciate your help very much!

Since you have not "shown your work" (apologizes if you show it later,
I'm replying as I encounter articles in date order) we can't help you
diagnose your problem.

For the below, I used the smallest "tux the peguin" png image available
from wikipedia [1].

$ pngtopam Tux.svg.png > Tux.svg.png.ppm
$ ls -ls
4 drwxr-xr-x 2 4096 Jan 5 22:33 ./
1128 drwxrwxrwt 87 1150976 Jan 5 22:30 ../
28 -rw-r--r-- 1 24774 Jan 5 22:32 Tux.svg.png
144 -rw-r--r-- 1 144849 Jan 5 22:33 Tux.svg.png.ppm

Original png downloaded from wikipedia, and a "ppm" created from the
png. (I append extensions just to keep the conversions clear.

Hash of the starting ppm file:

$ sha256sum Tux.svg.png.ppm
130d198065698026f3e258bd43e2c3033190298a6f35298d90a5df2bd566e276 Tux.svg.png.ppm

Convert the ppm to a new png:

$ pamtopng Tux.svg.png.ppm > Tux.svg.png.ppm.png

Convert the newly created png back into another ppm:

$ pngtopam Tux.svg.png.ppm.png > Tux.svg.png.ppm.png.ppm

Hash of the new ppm file:

$ sha256sum Tux.svg.png.ppm.png.ppm
130d198065698026f3e258bd43e2c3033190298a6f35298d90a5df2bd566e276 Tux.svg.png.ppm.png.ppm

Identical hash as the original:

$ sha256sum Tux.svg.png.ppm Tux.svg.png.ppm.png.ppm
130d198065698026f3e258bd43e2c3033190298a6f35298d90a5df2bd566e276 Tux.svg.png.ppm
130d198065698026f3e258bd43e2c3033190298a6f35298d90a5df2bd566e276 Tux.svg.png.ppm.png.ppm

The four files, original png, ppm from png, new png from ppm, and ppm
created from last png:

$ ls -ls Tux.svg.png*
28 -rw-r--r-- 1 24774 Jan 5 22:32 Tux.svg.png
144 -rw-r--r-- 1 144849 Jan 5 22:33 Tux.svg.png.ppm
24 -rw-r--r-- 1 21863 Jan 5 22:33 Tux.svg.png.ppm.png
144 -rw-r--r-- 1 144849 Jan 5 22:34 Tux.svg.png.ppm.png.ppm

So, to the extent I can tell, you are doing something wrong somewhere.

[1] Direct link to image I downloaded:
https://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Tux.svg/202px-Tux.svg.png

Wikipedia page where the image is linked:
https://en.wikipedia.org/wiki/Electronic_codebook

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 1/5/2025 1:25 AM, Stefan Claas wrote:
>> Rich wrote:
>>> Stefan Claas <pollux@tilde.club> wrote:
>>>> Rich wrote:
>>>>
>>>>> If instead you mean some kind of "special, PNG aware, encryptor that
>>>>> only encrypted the bitmap data of a PNG", but left the file as
>>>>> otherwise a proper PNG image structure, then that is slightly tricky
>>>>> (and an algorithm that is only useful for PNG's alone).
>>>>
>>>> Yes, this is what I mean.
>>>
>>> Which brings up the question of: why?
>>>
>>> Why go to the trouble to create an encryptor that is specalized for
>>> just encrypting the internal bitmap data within a PNG, leaving the rest
>>> as a PNG file, when a generic "byte stream" encryptor will encrypt the
>>> entire PNG with no extra effort?
>>
>> To make more content as allowed postable on social media, like X.
>>
>
> Well, posting a png to say, facebook, well... It's probablly going to
> turn it into a jpg... This can ruin the embedded ciphertext in the png
> image...

ebay seems to recently be converting jpeg's into webp's after one
uploads them, which would also alter the stored bitmap (as webp is
lossy). Although given the volume of image data they handle, if webp
is even 5% smaller than jpegs, it becomes a huge storage savings for
them.

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 1/5/2025 2:18 PM, Stefan Claas wrote:
>> Chris M. Thomasson wrote:
>>> On 1/5/2025 2:06 PM, Chris M. Thomasson wrote:
>>>> On 1/5/2025 1:25 AM, Stefan Claas wrote:
>>>>> Rich wrote:
>>>>>> Stefan Claas <pollux@tilde.club> wrote:
>>>>>>> Rich wrote:
>>>>>>>
>>>>>>>> If instead you mean some kind of "special, PNG aware, encryptor that
>>>>>>>> only encrypted the bitmap data of a PNG", but left the file as
>>>>>>>> otherwise a proper PNG image structure, then that is slightly tricky
>>>>>>>> (and an algorithm that is only useful for PNG's alone).
>>>>>>>
>>>>>>> Yes, this is what I mean.
>>>>>>
>>>>>> Which brings up the question of: why?
>>>>>>
>>>>>> Why go to the trouble to create an encryptor that is specalized for
>>>>>> just encrypting the internal bitmap data within a PNG, leaving the rest
>>>>>> as a PNG file, when a generic "byte stream" encryptor will encrypt the
>>>>>> entire PNG with no extra effort?
>>>>>
>>>>> To make more content as allowed postable on social media, like X.
>>>>>
>>>>
>>>> Well, posting a png to say, facebook, well... It's probablly going to
>>>> turn it into a jpg... This can ruin the embedded ciphertext in the png
>>>> image...
>>>
>>> Actually, the damn FB allows me to send my links with embedded
>>> ciphertext just fine.
>>
>> It is for X and not Meta.
>>
>
> Well, sending say a PNG to X, it still might convert it into a JPG. It
> might alter things for compression purposes. This can mess around with
> your payload...

There are several "modifications" to a PNG that can be performed, that
for a photo or a "meme image" will not result in visible changes, but
*will* result in changes to the bitmap.

Several possibilities are:

1) convert RGBA to just RGB (remove alpha channel) -- if one created a
"crypto carrier" PNG that used an alpha channel, this conversion would
delete 25% of the data content.

2) convert RGB (24 bits per pixel) to indexed (either eight or sixteen
bits per pixel). Both require color mapping from 2^24 colors to either
2^8 or 2^16 total colors, resulting in an altered bitmap.

3) convert RGB or indexed images into a "low color" index image (i.e.,
max 64 colors) which requires the same color mapping as #2 above, and
will create a different bitmap.

Simply uploading a PNG to X, then downloading the PNG X serves, and
identifying it as a "PNG" does not tell the full story. You have to
look at what "kind" of PNG was uploaded, and what "kind" of PNG
returned, to know what transformations X performed.

Rich wrote:
> Stefan Claas <pollux@tilde.club> wrote:
> > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> > and see if you can get the *original* data back. The sci.crypt community
> > and me of course would appreciate your help very much!
>
> Since you have not "shown your work" (apologizes if you show it later,
> I'm replying as I encounter articles in date order) we can't help you
> diagnose your problem.

> So, to the extent I can tell, you are doing something wrong somewhere.

Please try your conversion steps with the encrypted image, I already
have shown:

https://jmp.sh/HZM9ML9f

It includes a padding byte, needed for ppm so that it is divideable by 3.

--
Regards
Stefan

Stefan Claas wrote:
> Rich wrote:
> > Stefan Claas <pollux@tilde.club> wrote:
> > > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> > > and see if you can get the *original* data back. The sci.crypt community
> > > and me of course would appreciate your help very much!
> >
> > Since you have not "shown your work" (apologizes if you show it later,
> > I'm replying as I encounter articles in date order) we can't help you
> > diagnose your problem.
>
> > So, to the extent I can tell, you are doing something wrong somewhere.
>
> Please try your conversion steps with the encrypted image, I already
> have shown:
>
> https://jmp.sh/HZM9ML9f
>
> It includes a padding byte, needed for ppm so that it is divideable by 3.

Welln ot true, but the paading byte causes the issue, because it gets
lost when converting.

--
Regards
Stefan

Stefan Claas wrote:
> Stefan Claas wrote:
> > Rich wrote:
> > > Stefan Claas <pollux@tilde.club> wrote:
> > > > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> > > > and see if you can get the *original* data back. The sci.crypt community
> > > > and me of course would appreciate your help very much!
> > >
> > > Since you have not "shown your work" (apologizes if you show it later,
> > > I'm replying as I encounter articles in date order) we can't help you
> > > diagnose your problem.
> >
> > > So, to the extent I can tell, you are doing something wrong somewhere.
> >
> > Please try your conversion steps with the encrypted image, I already
> > have shown:
> >
> > https://jmp.sh/HZM9ML9f
> >
> > It includes a padding byte, needed for ppm so that it is divideable by 3.
>
> Welln ot true, but the paading byte causes the issue, because it gets
> lost when converting.

I will use encryption and then file2png, which makes the noise image
smaller in size, compared to the original image.

https://github.com/706f6c6c7578/file2png

--
Regards
Stefan

Stefan Claas <pollux@tilde.club> wrote:
> Rich wrote:
>> Stefan Claas <pollux@tilde.club> wrote:
>> > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
>> > and see if you can get the *original* data back. The sci.crypt community
>> > and me of course would appreciate your help very much!
>>
>> Since you have not "shown your work" (apologizes if you show it later,
>> I'm replying as I encounter articles in date order) we can't help you
>> diagnose your problem.
>
>> So, to the extent I can tell, you are doing something wrong somewhere.
>
> Please try your conversion steps with the encrypted image, I already
> have shown:
>
> https://jmp.sh/HZM9ML9f
>
> It includes a padding byte, needed for ppm so that it is divideable by 3.

That PPM is over-sized. The image header claims:

P6
# Created by GIMP version 2.10.34 PNM plug-in
480 480
255

For 480x480 pixels, with a maxval of 255 (1 byte per color) and three
color channels, the binary part of the ppm should be:

480*480*3=691,200 bytes long.

Instead, the binary part of the ppm is 691228 bytes long (28 bytes too
many are present).

So when converting it to a PNG, 28 bytes are lost, which do not return
when converting back from PNG to PPM.

Stefan Claas <pollux@tilde.club> wrote:
> Stefan Claas wrote:
>> Rich wrote:
>> > Stefan Claas <pollux@tilde.club> wrote:
>> > > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
>> > > and see if you can get the *original* data back. The sci.crypt community
>> > > and me of course would appreciate your help very much!
>> >
>> > Since you have not "shown your work" (apologizes if you show it later,
>> > I'm replying as I encounter articles in date order) we can't help you
>> > diagnose your problem.
>>
>> > So, to the extent I can tell, you are doing something wrong somewhere.
>>
>> Please try your conversion steps with the encrypted image, I already
>> have shown:
>>
>> https://jmp.sh/HZM9ML9f
>>
>> It includes a padding byte, needed for ppm so that it is divideable by 3.
>
> Welln ot true, but the paading byte causes the issue, because it gets
> lost when converting.

When you pick an image matrix size, that size must include all bytes,
including any padding necessary, in the data you want to make into an
image.

I.e., the image matrix has to be exactly the number of bytes of the
data after adding any headers and any padding.

On a sunny day (Mon, 6 Jan 2025 19:49:01 +0100) it happened Stefan Claas
<pollux@tilde.club> wrote in <vlh8it$14fe4$1@paganini.bofh.team>:

>Stefan Claas wrote:
>> Stefan Claas wrote:
>> > Rich wrote:
>> > > Stefan Claas <pollux@tilde.club> wrote:
>> > > > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
>> > > > and see if you can get the *original* data back. The sci.crypt community
>> > > > and me of course would appreciate your help very much!
>> > >
>> > > Since you have not "shown your work" (apologizes if you show it later,
>> > > I'm replying as I encounter articles in date order) we can't help you
>> > > diagnose your problem.
>> >
>> > > So, to the extent I can tell, you are doing something wrong somewhere.
>> >
>> > Please try your conversion steps with the encrypted image, I already
>> > have shown:
>> >
>> > https://jmp.sh/HZM9ML9f
>> >
>> > It includes a padding byte, needed for ppm so that it is divideable by 3.
>>
>> Welln ot true, but the paading byte causes the issue, because it gets
>> lost when converting.
>
>I will use encryption and then file2png, which makes the noise image
>smaller in size, compared to the original image.
>
>https://github.com/706f6c6c7578/file2png

All nice stuff, but an image with just noise makes one suspicious..
and than have a go at hacking it perhaps

Somehow embed the noise in a real image, like one looking at a TV with noise..
'my TV failed'
Bit more complicated to code... sub=area of the image.

Rich wrote:
> Stefan Claas <pollux@tilde.club> wrote:
> > Rich wrote:
> > > Stefan Claas <pollux@tilde.club> wrote:
> > > > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> > > > and see if you can get the *original* data back. The sci.crypt community
> > > > and me of course would appreciate your help very much!
> > >
> > > Since you have not "shown your work" (apologizes if you show it later,
> > > I'm replying as I encounter articles in date order) we can't help you
> > > diagnose your problem.
> >
> > > So, to the extent I can tell, you are doing something wrong somewhere.
> >
> > Please try your conversion steps with the encrypted image, I already
> > have shown:
> >
> > https://jmp.sh/HZM9ML9f
> >
> > It includes a padding byte, needed for ppm so that it is divideable by 3.
>
> That PPM is over-sized. The image header claims:
>
> P6
> # Created by GIMP version 2.10.34 PNM plug-in
> 480 480
> 255
>
> For 480x480 pixels, with a maxval of 255 (1 byte per color) and three
> color channels, the binary part of the ppm should be:
>
> 480*480*3=691,200 bytes long.
>
> Instead, the binary part of the ppm is 691228 bytes long (28 bytes too
> many are present).
>
> So when converting it to a PNG, 28 bytes are lost, which do not return
> when converting back from PNG to PPM.

Yes, I did something wrong. I stick with my fil2png program, which writes
directly png files from any data. A Python3 version is uploaded as well,
for those who do not use Go or do not want to use my binaries.

--
Regards
Stefan

Jan Panteltje wrote:
> On a sunny day (Mon, 6 Jan 2025 19:49:01 +0100) it happened Stefan Claas
> <pollux@tilde.club> wrote in <vlh8it$14fe4$1@paganini.bofh.team>:
>
> > Stefan Claas wrote:
> > > Stefan Claas wrote:
> > > > Rich wrote:
> > > > > Stefan Claas <pollux@tilde.club> wrote:
> > > > > > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> > > > > > and see if you can get the *original* data back. The sci.crypt community
> > > > > > and me of course would appreciate your help very much!
> > > > >
> > > > > Since you have not "shown your work" (apologizes if you show it later,
> > > > > I'm replying as I encounter articles in date order) we can't help you
> > > > > diagnose your problem.
> > > >
> > > > > So, to the extent I can tell, you are doing something wrong somewhere.
> > > >
> > > > Please try your conversion steps with the encrypted image, I already
> > > > have shown:
> > > >
> > > > https://jmp.sh/HZM9ML9f
> > > >
> > > > It includes a padding byte, needed for ppm so that it is divideable by 3.
> > >
> > > Welln ot true, but the paading byte causes the issue, because it gets
> > > lost when converting.
> >
> > I will use encryption and then file2png, which makes the noise image
> > smaller in size, compared to the original image.
> >
> > https://github.com/706f6c6c7578/file2png
>
> All nice stuff, but an image with just noise makes one suspicious..
> and than have a go at hacking it perhaps
>
> Somehow embed the noise in a real image, like one looking at a TV with noise..
> 'my TV failed'
> Bit more complicated to code... sub=area of the image.

Well, I could use 'steg' from GitHub, which is another Go program and
allows to hide any data in a .png, for example.

--
Regards
Stefan

Stefan Claas wrote:
> Rich wrote:
> > Stefan Claas <pollux@tilde.club> wrote:
> > > Rich wrote:
> > > > Stefan Claas <pollux@tilde.club> wrote:
> > > > > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> > > > > and see if you can get the *original* data back. The sci.crypt community
> > > > > and me of course would appreciate your help very much!
> > > >
> > > > Since you have not "shown your work" (apologizes if you show it later,
> > > > I'm replying as I encounter articles in date order) we can't help you
> > > > diagnose your problem.
> > >
> > > > So, to the extent I can tell, you are doing something wrong somewhere.
> > >
> > > Please try your conversion steps with the encrypted image, I already
> > > have shown:
> > >
> > > https://jmp.sh/HZM9ML9f
> > >
> > > It includes a padding byte, needed for ppm so that it is divideable by 3.
> >
> > That PPM is over-sized. The image header claims:
> >
> > P6
> > # Created by GIMP version 2.10.34 PNM plug-in
> > 480 480
> > 255
> >
> > For 480x480 pixels, with a maxval of 255 (1 byte per color) and three
> > color channels, the binary part of the ppm should be:
> >
> > 480*480*3=691,200 bytes long.
> >
> > Instead, the binary part of the ppm is 691228 bytes long (28 bytes too
> > many are present).
> >
> > So when converting it to a PNG, 28 bytes are lost, which do not return
> > when converting back from PNG to PPM.
>
> Yes, I did something wrong. I stick with my fil2png program, which writes
> directly png files from any data. A Python3 version is uploaded as well,
> for those who do not use Go or do not want to use my binaries.

Well, now I managed it with a different approach. I use now bin2ppm.go,
which produces from (binary) input a valid P3 ppm file, which I loaded
into Gimp, converted to .png and re-converted back to ppm in Gimp.

I used the follwoing procedure:

$ bc <<< 64*32*3
6144
$ echo "Hello sci.crypt community. This is a little test with bin2ppm.go" | pad -p 6144 > message.txt
$ bin2ppm 64 32 < message.txt > message.ppm

After that I converted to .png and back to .ppm with Gimp and then:

$ bin2ppm -d < message-gimp-png.ppm > decoded-message.txt

https://jmp.sh/LexKevVb
https://github.com/706f6c6c7578/bin2ppm

--
Regards
Stefan

On 2025-01-03 06:03, Rich wrote:
> Stefan Claas <pollux@tilde.club> wrote:
>> My old pads program is already updated. It compiled flawlessly for
>> many different platforms, including macOS, but I do not know if they
>> all support TPM 2.0, like Windows and Linux does.
>>
>> https://github.com/706f6c6c7578/pads
>
> Looking over your pads program, while you are retreiving true random
> numbers from the TPM chip, you are introducing a bias when you use the
> random bytes from the TPM to output letters or digits.
>
> Take for example your "letters" arm:
>
> if l {
> random, _ := tpm2.GetRandom(rwc, 5)
> for m := 0; m < 5; m++ {
> fmt.Printf("%c", 'A'+(random[m]%26))
> }
> }
>
> Now, if I've decoded the awful documentation for the TPM2 module
> properly [1] the tpm2.GetRandom call will return five bytes (presumably
> unsigned bytes) of random data.
>
> Then, you loop over the five bytes, outputting the letter that
> corresponds to ASCII A plus the remainder after dividing the byte by
> 26. Which is where you introduce a bias.
>
> A byte will have a value from 0 to 255, for 256 total values.
>
> But 26 does not evenly divide 256. 256/26 ~ 9.846
>
> 26 divides 256 evenly 9 times, no problem here. That covers values 0
> to 233. But for any bytes returned from GetRandom that fall into the
> range 234 to 255, you have only 21 possible values that can return from
> the modulo. So your remainder will be only 0 through 21. You'll never
> get 22 through 25 out, because there is not enough numeric range in the
> "tail" to return 22 through 25 from the modulo. So for any bytes with
> values 234 to 255 from the TPM, you can return A through V but will
> never return W, X, Y or Z.
>
> So your resulting letters will have a bias for A through V.
>
> The fix is easy, first check the value of the byte you are about to
> use, and if it happens to be greater than 233, throw that byte away and
> pull another from the TPM.
Why waste 8.98% of random bytes, especially when generating large keys
from slow source of randomness? Lumbroso's FastDiceRoller algorithm
consumes the exact number of bits needed to produce integer in requested
range: https://arxiv.org/abs/1304.1916

Exhibit 1:
inline uint32_t FastDiceRoller(unsigned int n) {
uint64_t v = 1, c = 0;
while (true) {
v = v << 1;
c = (c << 1) + randombit;
if (v >= n) {
if (c < n) return c;
else {
v = v - n;
c = c - n;
}
}
}
}

Exhibit 2:
function FastDiceRoller(const n: longword): longword;
var
v, c: Int64;
begin
v := 1;
c := 0;
while (true) do
begin
v := (v shl 1);
c := (c shl 1) + RandomBit;
if (v >= n) then
begin
if (c < n) then
begin
result := LongWord(c);
Exit;
end
else
begin
v := v - n;
c := c - n;
end;
end;
end;
end;

--

-----BEGIN PGP PUBLIC KEY FINGERPRINT-----
5745 807C 2B82 14D8 AB06 422C 8876 5DFC 2A51 778C
------END PGP PUBLIC KEY FINGERPRINT------

Chax Plore <ftilojim@tznvy.pbz> wrote:
> On 2025-01-03 06:03, Rich wrote:
>> Stefan Claas <pollux@tilde.club> wrote:
>>> My old pads program is already updated. It compiled flawlessly for
>>> many different platforms, including macOS, but I do not know if they
>>> all support TPM 2.0, like Windows and Linux does.
>>>
>>> https://github.com/706f6c6c7578/pads
>>
>> Looking over your pads program, while you are retreiving true random
>> numbers from the TPM chip, you are introducing a bias when you use the
>> random bytes from the TPM to output letters or digits.
>>
>> Take for example your "letters" arm:
>>
>> if l {
>> random, _ := tpm2.GetRandom(rwc, 5)
>> for m := 0; m < 5; m++ {
>> fmt.Printf("%c", 'A'+(random[m]%26))
>> }
>> }
>>
>> Now, if I've decoded the awful documentation for the TPM2 module
>> properly [1] the tpm2.GetRandom call will return five bytes (presumably
>> unsigned bytes) of random data.
>>
>> Then, you loop over the five bytes, outputting the letter that
>> corresponds to ASCII A plus the remainder after dividing the byte by
>> 26. Which is where you introduce a bias.
>>
>> A byte will have a value from 0 to 255, for 256 total values.
>>
>> But 26 does not evenly divide 256. 256/26 ~ 9.846
>>
>> 26 divides 256 evenly 9 times, no problem here. That covers values 0
>> to 233. But for any bytes returned from GetRandom that fall into the
>> range 234 to 255, you have only 21 possible values that can return from
>> the modulo. So your remainder will be only 0 through 21. You'll never
>> get 22 through 25 out, because there is not enough numeric range in the
>> "tail" to return 22 through 25 from the modulo. So for any bytes with
>> values 234 to 255 from the TPM, you can return A through V but will
>> never return W, X, Y or Z.
>>
>> So your resulting letters will have a bias for A through V.
>>
>> The fix is easy, first check the value of the byte you are about to
>> use, and if it happens to be greater than 233, throw that byte away and
>> pull another from the TPM.

> Why waste 8.98% of random bytes, especially when generating large
> keys from slow source of randomness?

My post was to point out the bias, and offer a simple [1] solution that
is easy to understand.

> Lumbroso's FastDiceRoller algorithm
> consumes the exact number of bits needed to produce integer in requested
> range: https://arxiv.org/abs/1304.1916

Interesting algorithm, thanks for the reference, although I'll have to
spend some time later giving it a go over to fully grok what it is
doing.

[1] Note that "simple" does not mean "optimal".

On 1/1/2025 2:19 PM, Rich wrote:
> Stefan Claas <pollux@tilde.club> wrote:
>> Stefan Claas wrote:
>>> Rich wrote:
>>>> Stefan Claas <pollux@tilde.club> wrote:
>>>>> Stefan Claas wrote:
>>>>>>
>>>>>> echo 'Happy News Year 2025' | ternary
>>>>>> 2112102022020111101010222211010022112012102120110020100021120220
>>>>>> 10000111010121200020221000211000220022020
>>>>>>
>>>>>> $ echo 'Happy News Year 2025' | ternary | ternary -d
>>>>>> Happy News Year 2025
>>>>>>
>>>>>> (My program works with binary data as well.)
>>>>>>
>>>>>
>>>>> The nice thing is we can like xor use ternary exclusive or (txor)
>>>>> to encrypt/decrypt messages. :-)
>>>>>
>>>>> $ echo 'Happy News Year 2025' | ternary > message.txt
>>>>> $ txor -k k-1.txt < message.txt > message_encrypted.txt
>>>>> $ txor -k k-1.txt -d < message_encrypted.txt > message_decrypted.txt
>>>>> $ ternary -d < message_decrypted.txt
>>>>> Happy News Year 2025
>>>>
>>>> How does "ternary exclusive or" differ from the usual boolean xor?
>>>
>>> The usual Boolean XOR (exclusive or) operation takes two binary inputs
>>> and returns true (1) if exactly one of the inputs is true (1), and false
>>> (0) otherwise.
>>>
>>> Ternary XOR takes three binary inputs and returns true (1) if an odd
>>> number of the inputs are true (1).
>>
>> XOR:
>>
>> A B A⊕B
>> 0 0 0
>> 0 1 1
>> 1 0 1
>> 1 1 0
>>
>> Ternary XOR:
>>
>> A B C A⊕B⊕C
>> 0 0 0 0
>> 0 0 1 1
>> 0 1 0 1
>> 0 1 1 0
>> 1 0 0 1
>> 1 0 1 0
>> 1 1 0 0
>> 1 1 1 1
>
> Or simply "even parity".
>
> https://en.wikipedia.org/wiki/Parity_bit

Never forget about NAND cat:

https://youtu.be/IBR_unm3MKg

LOL!

Stefan Claas wrote:
> Stefan Claas wrote:
> > Rich wrote:
> > > Stefan Claas <pollux@tilde.club> wrote:
> > > > Rich wrote:
> > > > > Stefan Claas <pollux@tilde.club> wrote:
> > > > > > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> > > > > > and see if you can get the *original* data back. The sci.crypt community
> > > > > > and me of course would appreciate your help very much!
> > > > >
> > > > > Since you have not "shown your work" (apologizes if you show it later,
> > > > > I'm replying as I encounter articles in date order) we can't help you
> > > > > diagnose your problem.
> > > >
> > > > > So, to the extent I can tell, you are doing something wrong somewhere.
> > > >
> > > > Please try your conversion steps with the encrypted image, I already
> > > > have shown:
> > > >
> > > > https://jmp.sh/HZM9ML9f
> > > >
> > > > It includes a padding byte, needed for ppm so that it is divideable by 3.
> > >
> > > That PPM is over-sized. The image header claims:
> > >
> > > P6
> > > # Created by GIMP version 2.10.34 PNM plug-in
> > > 480 480
> > > 255
> > >
> > > For 480x480 pixels, with a maxval of 255 (1 byte per color) and three
> > > color channels, the binary part of the ppm should be:
> > >
> > > 480*480*3=691,200 bytes long.
> > >
> > > Instead, the binary part of the ppm is 691228 bytes long (28 bytes too
> > > many are present).
> > >
> > > So when converting it to a PNG, 28 bytes are lost, which do not return
> > > when converting back from PNG to PPM.
> >
> > Yes, I did something wrong. I stick with my fil2png program, which writes
> > directly png files from any data. A Python3 version is uploaded as well,
> > for those who do not use Go or do not want to use my binaries.
>
> Well, now I managed it with a different approach. I use now bin2ppm.go,
> which produces from (binary) input a valid P3 ppm file, which I loaded
> into Gimp, converted to .png and re-converted back to ppm in Gimp.
>
> I used the follwoing procedure:
>
> $ bc <<< 64*32*3
> 6144
> $ echo "Hello sci.crypt community. This is a little test with bin2ppm.go" | pad -p 6144 > message.txt
> $ bin2ppm 64 32 < message.txt > message.ppm
>
> After that I converted to .png and back to .ppm with Gimp and then:
>
> $ bin2ppm -d < message-gimp-png.ppm > decoded-message.txt
>
> https://jmp.sh/LexKevVb
> https://github.com/706f6c6c7578/bin2ppm

To make things simple again, I uploaded pngcrypt, so that one can use
file2png with pngcrypt. :-) https://github.com/706f6c6c7578/pngcrypt

--
Regards
Stefan

Stefan Claas wrote:

> To make things simple again, I uploaded pngcrypt, so that one can use
> file2png with pngcrypt. :-) https://github.com/706f6c6c7578/pngcrypt

https://jmp.sh/ENeHGh9r

$ echo "I wish the sci.crypt community a nice weekend!" | file2png | pngcrypt -p test > message.png

$ pngcrypt -d -p test < message.png | file2png -d
I wish the sci.crypt community a nice weekend!

--
Regards
Stefan

On 1/11/2025 2:15 AM, Stefan Claas wrote:
> Stefan Claas wrote:
>
>> To make things simple again, I uploaded pngcrypt, so that one can use
>> file2png with pngcrypt. :-) https://github.com/706f6c6c7578/pngcrypt
>
> https://jmp.sh/ENeHGh9r
>
> $ echo "I wish the sci.crypt community a nice weekend!" | file2png | pngcrypt -p test > message.png
>
> $ pngcrypt -d -p test < message.png | file2png -d
> I wish the sci.crypt community a nice weekend!
>

Make a big one, say 3840x2160 encrypting the same byte. See if you can
visually see any patterns wrt the encryption algo itself?

On 1/11/2025 2:47 AM, Chris M. Thomasson wrote:
> On 1/11/2025 2:15 AM, Stefan Claas wrote:
>> Stefan Claas wrote:
>>
>>> To make things simple again, I uploaded pngcrypt, so that one can use
>>> file2png with pngcrypt. :-) https://github.com/706f6c6c7578/pngcrypt
>>
>> https://jmp.sh/ENeHGh9r
>>
>> $ echo "I wish the sci.crypt community a nice weekend!" | file2png |
>> pngcrypt -p test > message.png
>>
>> $ pngcrypt -d -p test < message.png | file2png -d
>> I wish the sci.crypt community a nice weekend!
>>
>
> Make a big one, say 3840x2160 encrypting the same byte. See if you can
> visually see any patterns wrt the encryption algo itself?

I understand that the png can carry any payload generated from any
encryption algo, but looking at the ciphertext in a visual medium is
useful for sure.

Chris M. Thomasson wrote:
> On 1/11/2025 2:15 AM, Stefan Claas wrote:
> > Stefan Claas wrote:
> >
> > > To make things simple again, I uploaded pngcrypt, so that one can use
> > > file2png with pngcrypt. :-) https://github.com/706f6c6c7578/pngcrypt
> >
> > https://jmp.sh/ENeHGh9r
> >
> > $ echo "I wish the sci.crypt community a nice weekend!" | file2png | pngcrypt -p test > message.png
> >
> > $ pngcrypt -d -p test < message.png | file2png -d
> > I wish the sci.crypt community a nice weekend!
> >
>
> Make a big one, say 3840x2160 encrypting the same byte. See if you can
> visually see any patterns wrt the encryption algo itself?

Please try it yourself and report back, or haven't you installed Go yet?
;-)

--
Regards
Stefan

On 1/11/2025 4:18 AM, Stefan Claas wrote:
> Chris M. Thomasson wrote:
>> On 1/11/2025 2:15 AM, Stefan Claas wrote:
>>> Stefan Claas wrote:
>>>
>>>> To make things simple again, I uploaded pngcrypt, so that one can use
>>>> file2png with pngcrypt. :-) https://github.com/706f6c6c7578/pngcrypt
>>>
>>> https://jmp.sh/ENeHGh9r
>>>
>>> $ echo "I wish the sci.crypt community a nice weekend!" | file2png | pngcrypt -p test > message.png
>>>
>>> $ pngcrypt -d -p test < message.png | file2png -d
>>> I wish the sci.crypt community a nice weekend!
>>>
>>
>> Make a big one, say 3840x2160 encrypting the same byte. See if you can
>> visually see any patterns wrt the encryption algo itself?
>
> Please try it yourself and report back, or haven't you installed Go yet?
> ;-)
>

Nope. I have no Go on the system I am using now. Well, humm... I should
have some more time later on this week.