Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Rich <rich@example.invalid>
Newsgroups: sci.crypt
Subject: Re: xorpng
Date: Mon, 6 Jan 2025 03:50:15 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <vlfjtn$1ande$7@dont-email.me>
References: <vl243l$3jkpe$1@paganini.bofh.team>   <vlc8om$k8s5$3@dont-email.me> <vlc9d8$irra$1@paganini.bofh.team> <vlcahc$ks00$1@dont-email.me> <vlcbki$j00g$1@paganini.bofh.team> <vlccrh$lb6a$1@dont-email.me> <vlchr0$j921$1@paganini.bofh.team> <vlcivh$md8n$2@dont-email.me> <vlcjan$oal1$2@paganini.bofh.team> <vld86b$tdna$1@dont-email.me> <vldj6q$pqvr$2@paganini.bofh.team> <vlevq2$17khf$4@dont-email.me> <vlf07h$17khf$5@dont-email.me> <vlf0f4$s1t0$1@paganini.bofh.team> <vlf1fi$17khf$9@dont-email.me>
Injection-Date: Mon, 06 Jan 2025 04:50:15 +0100 (CET)
Injection-Info: dont-email.me; posting-host="aacc148df4532970fbc7162b818dee32";
	logging-data="1400238"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18rcm6GtKvCuEEF7u9dD6fw"
User-Agent: tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64))
Cancel-Lock: sha1:bs86ffivcCG8ivk4Ga3tGV6gI5I=
Bytes: 3917

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.