Path: ...!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Rich Newsgroups: sci.crypt Subject: Re: [base64+] Date: Tue, 31 Dec 2024 23:25:50 -0000 (UTC) Organization: A noiseless patient Spider Lines: 40 Message-ID: References: Injection-Date: Wed, 01 Jan 2025 00:25:51 +0100 (CET) Injection-Info: dont-email.me; posting-host="8c10bf53f7fd2c88970ece96e6e64bf0"; logging-data="2571415"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19GNiVk1O3Khuq8y4T+68qx" User-Agent: tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64)) Cancel-Lock: sha1:Ja9EWgKrZHa3ZEloAN9xmMlfR7c= Bytes: 2441 Stefan Claas wrote: > Rich wrote: >> Stefan Claas wrote: >> > Hi all, >> > >> > while no encryption, this is an enhanced version of a standard >> > base64 encoder/decoder. >> > >> > It writes the filename, file size and SHA256 hashsum as a Header, >> > like in this example: >> >> So, somewhat like an 'extended' uuencode. >> >> https://en.wikipedia.org/wiki/Uuencoding > > Well, yes. :-) > > I wonder why nobody else came up with the idea of base64+ in the past. Several ideas (all mostly guesses): 1) Uuencode already exists (although, granted, your base64+ goes beyond what Uuencode does in providing a hash over the data) 2) yenc exists 3) par2 exists (and goes far beyond base64+ in allowing recovery of broken files) 4) (I feel this one is most likely) The 99.9'th percentile of computer user has no idea what base64 even is, and all the mechanics are hidden from them behind their email UI. They simply drag and drop a file onto their email client, and it becomes an "attachment" (and looks to them to be a "file" via UI trickery) and they don't know, nor care, about the how/why. MIME specifies base64 encoding for the attached files, and includes features for including the filenames and sizes (which is how the "attached files" can appear to be "files" to the users), and so 99.9% of the "need" has been met. So no one is worried about meeting the missing 0.1%.