Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Rich Newsgroups: sci.crypt Subject: Re: xorpng Date: Mon, 6 Jan 2025 03:29:32 -0000 (UTC) Organization: A noiseless patient Spider Lines: 70 Message-ID: References: Injection-Date: Mon, 06 Jan 2025 04:29:33 +0100 (CET) Injection-Info: dont-email.me; posting-host="aacc148df4532970fbc7162b818dee32"; logging-data="1400238"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18J35bm591vgQ1RI6nxMniY" User-Agent: tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64)) Cancel-Lock: sha1:yEAGf8lse+zGsrG6SmZiJbKkDSQ= Bytes: 4489 Stefan Claas wrote: > Rich wrote: >> Stefan Claas wrote: >> > Rich wrote: >> > > Stefan Claas wrote: >> > > > Stefan Claas wrote: >> > > > > Rich wrote: >> > > > > > Stefan Claas 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?