Sujet : Re: [base64+]
De : rich (at) *nospam* example.invalid (Rich)
Groupes : sci.cryptDate : 01. Jan 2025, 00:25:50
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vl1uhu$2ef4n$2@dont-email.me>
References : 1 2 3
User-Agent : tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64))
Stefan Claas <
pollux@tilde.club> wrote:
Rich wrote:
Stefan Claas <pollux@tilde.club> 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 <
https://en.wikipedia.org/wiki/YEnc>
3) par2 exists (and goes far beyond base64+ in allowing recovery of
broken files) <
https://en.wikipedia.org/wiki/Parchive>
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%.