Re: ASCII Requires a Temporary Substitution During Encryption.
- From: WTShaw <lurens1@xxxxxxxxx>
- Date: Fri, 20 Feb 2009 01:45:44 -0800 (PST)
On Feb 19, 8:57 am, rossum <rossu...@xxxxxxxxxxxx> wrote:
On Thu, 19 Feb 2009 02:45:51 -0800 (PST), austin.oby...@xxxxxxxxxxx
wrote:
The creation of ASCII circa 1963 was a profound move by the US
government that greatly enhanced normal ‘overt’ communications. In the
notes that follow, the focus is on using the writable subset of ASCII
in ‘covert’ secret communications and more precisely the denary
representation of this set that is comprised of the positive integers
32 to 126 inclusively, as the encryption data for writing ciphers.
However, ASCII has now been replaced by Unicode:
http://www.unicode.org/
If you want your crypto system to by forward looking rather than
backward looking then you need to drop ASCII, which is now obsolete,
and move over to Unicode.
A failure to support Unicode is likely to impede use of your system at
the proposal stage. Almost all proposals will be required to support
Unicode; and any that fail to do so will not progress any further.
rossum
Dear Mr/Ms Rossum,
That is really a dumb idea! To do a lot of the things we need, we
don't need women with bound feet or need to march in single profile.
What hamstrings innovation can be the assumption of others people's
limitations. Being able to focus on specific problems requires
clearly defining our own objectives or we might all be required to
drive 60 passenger buses about or just walk.
The biggest problem with ascii as a would be succinct set of codes as
applied to common cryptological function is the inclusion of legacy
commands that muck up such processes with extra baggage. Austin and
many others are absolutely right in homing in on real historical
characters that might appear. Add a space and a line return character
to the usual keyboard 94 gives you 96. Others can be added as a
dealer's choice but you don't need to add even a single bell, # 7, to
produce a nice clean set.
Remember HEX? It's not so appropriate for many uses. I wrote a
converter I like, makes ascii 00 and then the 94 standard characters
above that; Line Feed is 99 and four other arbitrary characters, 95 to
98, can be assigned as need be. It's all about decimal digits and
will convert common text to 10 digit character groups, no different
in traffic size as ten characters of 0 to F in a binary representation
but without strange character fears.
Be serious, information can be flawlessly represented in any base, 16,
10, 26, or 100, whatever. For technical reasons, some bases are
otherwise more cryptologically convenient and/or mathematically useful
than others. Texts including,software source can be transmitted in
something as seemingly simple as 5 character groups using a 26 letter
set, amongst many others. Be ye hypnotized by unicode or understand
that any language's characters are just as good if assigned to a
nondistracting set like base 100.
BTW, the decimal digit system is far more universal and has a more
concrete future than any other including ascii and any unicode
illusion of comprehensive inclusion. Surely, there can be no new
justification for dispersing a mere conversion utility like what I
have described and it works according to my common criteria recently
posted and is easily emailed.
.
- References:
- ASCII Requires a Temporary Substitution During Encryption.
- From: austin . obyrne
- Re: ASCII Requires a Temporary Substitution During Encryption.
- From: rossum
- ASCII Requires a Temporary Substitution During Encryption.
- Prev by Date: Re: RSA question
- Next by Date: Re: ASCII Requires a Temporary Substitution During Encryption.
- Previous by thread: Re: ASCII Requires a Temporary Substitution During Encryption.
- Next by thread: Re: ASCII Requires a Temporary Substitution During Encryption.
- Index(es):
Relevant Pages
|
Loading
