h a l f b a k e r y
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
or get an account
Modern encryption keys seem to be limited to a few modern alphabets. One can attempt to stop brute force efforts at cracking by making the keys ever longer.
But wouldn't it be more efficient to include the characters of all known alphabets, ciphered and undeciphered?
||That's not really how it works.
||An encryption key is really just a big, 'unguessable'
number. You can represent an arbitrary number as a
string of characters, in much the same way as you can
represent a large number like a million using the
string of digits "1000000".
Base 10 is traditional for human communication, but it's
not particularly 'better' for storing data in. Other
values which are commonly used in computing are 16
(hexadecimal), 64 (base64), and sometimes other
compromises between human readability and byte-
packing like 36 (case-insensitive letters and numbers),
95 (printable ASCII characters) or 256 (bytes).
||If you have more glyphs per character then you do need
fewer characters, however each individual char needs more
storage, so there's no saving - you still need as many
combinations as you have in your number-range.
||You might save a little storage space if the data is stored
unpacked in bytes - but when it gets significant it's
simpler to use bytes (or groups of bytes) internally. And
for human-mediated transfer, you definitely don't
want to require users to input a string of arbitrary
When people have problems getting the case right,
distinguishing 'I' and '1', 'O' and '0' etc. in the small set
available, it's probably not a good idea to bring in all of
||Unless you're a BOFH, in which case you might provide default
passwords in dingbats.
||Not to mention you'd have to freeze the can of spaghetti,
then very carefully de-frost it at the other end.
||Or presumably you could impregnate each spaghetti with
an iron solution, and use magnets to hold them in place