| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 29 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 60:19:04 |
| Calls: | 446 |
| Calls today: | 1 |
| Files: | 1,039 |
| Messages: | 92,549 |
@@@ BEGIN MSG.XZ.B64.17.76.SCOS @@@ JTMY$ew:&y020Z{vYn;Gxxn\=5p{R!.;.OJQ4){i'$&vwe@4F$d|LFdM0_FEswtR*0ZJ]"+
[...]
@@@ BEGIN MSG.XZ.B64.17.76.SCOS @@@
On 09/02/2025 14:00, Byrl Raze Buckbriar wrote:
@@@ BEGIN MSG.XZ.B64.17.76.SCOS @@@
Key: 12 34
ewBn :k8PsbZ 1]T0 ; k!Rz&Ou 'f*Ea#!
4Lj q=/b m) /EZt @F Nl 3{Vc[D \cm_'KeQ
On Sat, 22 Feb 2025 08:57:02 +0000, Richard Heathfield wrote:
Assumes "facts" not in evidence.
Quite right to ask. :)
You are probably correct in a lot of what you say, and I accept I may be wrong in much of what I say. Particularly emulation, maybe that isn't the cause of my problem.
I've posted some test sequences of the SCOS character set to uk.telecom.
Feel free to have a look using your preferred reader.
I've concentrated on
the sequences where I've noticed I have a problem. There may be others I haven't thought about. They set off as a tidy column of numbers, letters
and punctuation marks that are taken from the SCOS character set. I have included back tick, for completeness.
I've then read the posts using Pan and Thunderbird. Both exhibit some
issues which would prohibit successful decryption in certain
circumstances.
Some of the sequence of characters that could be interpreted as emoticons
get removed and are replaced by unicode characters (or something else) and displayed as an emoticon in both readers. In both cases the underlying characters never reach the reader's display, so any attempt at
decrytption, using the ciphertext as presented, will fail. This includes:
:) – Smiley face
:( – Sad face
;) – Wink
:'( – Crying
of a uphill task, which is easy to avoid if we accept some restriction on
the character set.
Please don't feel I getting at you over this.
I'd like to take a greater
part in sci.crypt, but I don't think we're all seeing the same things,
which makes participation difficult.
Assumes "facts" not in evidence.
I did. I found no articles under your name in the current feed for that group.
I have found nothing of the kind in that group.
If your newsreader turns valid C into sad faces, your newsreader is
broken. Solution: download a newsreader that works.
I will not deny that I find it a little frustrating that you have
continually ignored my substantive point, which is that you are
attempting to fix the wrong software. But a reasonable man is open to persuasion, and you do strike me as being a reasonable man, so I live in hope.
The fix is simple. Get a newsreader that doesn't mangle articles, not
least because much of what is posted here is source code, and an attempt
to change programming language syntax to indulge Pan's corrupting whim
is not likely to succeed.
On Sun, 23 Feb 2025 10:55:41 +0000, Richard Heathfield wrote:
I did. I found no articles under your name in the current feed for that
group.
I have found nothing of the kind in that group.
Oh dear. Stephan found them. Perhaps your reader. ;)
they should start at:
Subject: Character Test
Message-ID: <vpeakb$cgsc$1@dont-email.me>
On 24/02/2025 10:17, Richard Harnden wrote:
On 24/02/2025 09:51, David Entwistle wrote:
On Sun, 23 Feb 2025 10:55:41 +0000, Richard Heathfield wrote:
I did. I found no articles under your name in the current feed for that >>>> group.
I have found nothing of the kind in that group.
Oh dear. Stephan found them. Perhaps your reader. ;)
they should start at:
Subject: Character Test
Message-ID: <vpeakb$cgsc$1@dont-email.me>
I think you said uk.telecom. That is uk.test :)
That would certainly explain it. Test groups tend to be huge. Let David
post here if he wants us to read his examples.
On Sun, 23 Feb 2025 10:55:41 +0000, Richard Heathfield wrote:
I did. I found no articles under your name in the current feed for that
group.
I have found nothing of the kind in that group.
Oh dear. Stephan found them. Perhaps your reader. ;)
they should start at:
Subject: Character Test
Message-ID: <vpeakb$cgsc$1@dont-email.me>
If your newsreader turns valid C into sad faces, your newsreader is
broken. Solution: download a newsreader that works.
Okay, but I've now used a couple of popular newsgroup readers, and with default settings I don't see valid C code in the reader message display of either.
My concern is that if we get three new human readers of sci.crypt, keen to learn, but relatively inexperienced, and as an introduction we post a SCOS-encrypted ciphertext as a challenge, and then ask each how many characters are there in the ciphertext, we will likely get three different answers.
I will not deny that I find it a little frustrating that you have
continually ignored my substantive point, which is that you are
attempting to fix the wrong software. But a reasonable man is open to
persuasion, and you do strike me as being a reasonable man, so I live in
hope.
Sorry for the frustration - I recognize I must be causing it and it pains
me. However, I feel I am speaking on behalf of the other new and less- experienced readers and potential readers.
The fix is simple. Get a newsreader that doesn't mangle articles, not
least because much of what is posted here is source code, and an attempt
to change programming language syntax to indulge Pan's corrupting whim
is not likely to succeed.
Pan's and Thunderbird's whim... I'll think about it.
On 24/02/2025 09:51, David Entwistle wrote:
On Sun, 23 Feb 2025 10:55:41 +0000, Richard Heathfield wrote:
I did. I found no articles under your name in the current feed
for that
group.
I have found nothing of the kind in that group.
Oh dear. Stephan found them. Perhaps your reader. ;)
they should start at:
Subject: Character Test
Message-ID: <vpeakb$cgsc$1@dont-email.me>
I think you said uk.telecom. That is uk.test :)
On Sun, 23 Feb 2025 10:55:41 +0000, Richard Heathfield wrote:
I did. I found no articles under your name in the current feed for that
group.
I have found nothing of the kind in that group.
Oh dear. Stephan found them. Perhaps your reader. ;)
they should start at:
Subject: Character Test
Message-ID: <vpeakb$cgsc$1@dont-email.me>
If your newsreader turns valid C into sad faces, your newsreader is
broken. Solution: download a newsreader that works.
Okay, but I've now used a couple of popular newsgroup readers, and with >default settings I don't see valid C code in the reader message display of >either. I don't see the original characters of the ciphertext. I have >programmed in C, but I don't at the moment (I should). The younger >participants in the National Cipher Challenge (some of who, from my >experience, are very very gifted) are generally using Python.
My concern is that if we get three new human readers of sci.crypt, keen to >learn, but relatively inexperienced, and as an introduction we post a >SCOS-encrypted ciphertext as a challenge, and then ask each how many >characters are there in the ciphertext, we will likely get three different >answers. At least two of those readers will not have a valid ciphertext
which they can decrypt. We have now presented a whole different challenge. >There are ways around it - tell them to get a new reader, or convert the >characters themselves, or validate the characters with a hash function,
but that isn't an easy and friendly introduction to cryptography. You
could, possibly do, argue that cryptography isn't and shouldn't be easy,
nor friendly, but we've given each individual a different challenge
dependant on their newsreader - there is little prospect for really useful >and valid support if individual human readers are looking at a different >problem.
I will not deny that I find it a little frustrating that you have
continually ignored my substantive point, which is that you are
attempting to fix the wrong software. But a reasonable man is open to
persuasion, and you do strike me as being a reasonable man, so I live in
hope.
Sorry for the frustration - I recognize I must be causing it and it pains
me. However, I feel I am speaking on behalf of the other new and less- >experienced readers and potential readers.
The fix is simple. Get a newsreader that doesn't mangle articles, not
least because much of what is posted here is source code, and an attempt
to change programming language syntax to indulge Pan's corrupting whim
is not likely to succeed.
Pan's and Thunderbird's whim... I'll think about it.
On 24/02/2025 10:45, Richard Harnden wrote:
On 24/02/2025 10:28, Richard Heathfield wrote:
On 24/02/2025 10:17, Richard Harnden wrote:
On 24/02/2025 09:51, David Entwistle wrote:
On Sun, 23 Feb 2025 10:55:41 +0000, Richard Heathfield wrote:
I did. I found no articles under your name in the current feed for >>>>>> that
group.
I have found nothing of the kind in that group.
Oh dear. Stephan found them. Perhaps your reader. ;)
they should start at:
Subject: Character Test
Message-ID: <vpeakb$cgsc$1@dont-email.me>
I think you said uk.telecom. That is uk.test :)
That would certainly explain it. Test groups tend to be huge. Let
David post here if he wants us to read his examples.
That one isn't.
Okay. Found them.
Anyway, in my thunderbird: x^2 superscripts, x ^ 2 does not.
In mine, neither do.
x^2 (x hat 2) is perfectly valid C code, so superscripting it wrongly
changes its meaning.
Given this input:
32 ^ ^ *
...
126 ~ ^~ ^~*
scos2 e 98 76 gives this output:
8q l U F
...
vfS X /@ zwT
$md5sum charset.txt
d5c6d06587dbac07fed831293ff0580d charset.txt
$ md5sum charset.scos2
87ea4967605a5ba4d69ff6cf0fb541f5 charset.scos2
Anyone get anything different?
I think you said uk.telecom. That is uk.test
On 24/02/2025 10:28, Richard Heathfield wrote:
On 24/02/2025 10:17, Richard Harnden wrote:
On 24/02/2025 09:51, David Entwistle wrote:
On Sun, 23 Feb 2025 10:55:41 +0000, Richard Heathfield wrote:
I did. I found no articles under your name in the current
feed for that
group.
I have found nothing of the kind in that group.
Oh dear. Stephan found them. Perhaps your reader. ;)
they should start at:
Subject: Character Test
Message-ID: <vpeakb$cgsc$1@dont-email.me>
I think you said uk.telecom. That is uk.test :)
That would certainly explain it. Test groups tend to be huge.
Let David post here if he wants us to read his examples.
That one isn't.
Anyway, in my thunderbird: x^2 superscripts, x ^ 2 does not.
+ !n cF,9u f T< ]4u
That would certainly explain it. Test groups tend to be huge. Let David
post here if he wants us to read his examples.
On 24/02/2025 11:18, Richard Heathfield wrote:
On 24/02/2025 10:45, Richard Harnden wrote:
On 24/02/2025 10:28, Richard Heathfield wrote:
On 24/02/2025 10:17, Richard Harnden wrote:
On 24/02/2025 09:51, David Entwistle wrote:
On Sun, 23 Feb 2025 10:55:41 +0000, Richard Heathfield wrote:
I did. I found no articles under your name in the current
feed for that
group.
I have found nothing of the kind in that group.
Oh dear. Stephan found them. Perhaps your reader. ;)
they should start at:
Subject: Character Test
Message-ID: <vpeakb$cgsc$1@dont-email.me>
I think you said uk.telecom. That is uk.test :)
That would certainly explain it. Test groups tend to be huge.
Let David post here if he wants us to read his examples.
That one isn't.
Okay. Found them.
Anyway, in my thunderbird: x^2 superscripts, x ^ 2 does not.
In mine, neither do.
x^2 (x hat 2) is perfectly valid C code, so superscripting it
wrongly changes its meaning.
Given this input:
32 ^ ^ *
...
126 ~ ^~ ^~*
scos2 e 98 76 gives this output:
You don't need the e/d flag, just negate the numbers.
One thing that is mildly annoying: if the encoded line of text
happens to start with a "> ", then thunderbird thinks its quoted
text.
I can turn this (dis)functionality off,
but many users new to USENET and
encryption will not be aware of what is happening.
I thiunk an easy compromise is already in place. I'd suggest, as an introduction, SCOSc, for compatibility with any newsreader, is used
without the punctuation characters. I don't see any issues with that, if
no one finds the idea disagreeable.
On another subject, reading "A12.1 Trigraph Sequences" of the ANSI
standard version of "The C Programming Language", does that apply to
Strings, at preprocessing - where '??=' gets replaced with '#' etc. during preprocessing? Sorry if this a stupid question - I'm no longer familiar
with C.
Given this input:
[long input snipped]
$md5sum charset.txt
d5c6d06587dbac07fed831293ff0580d charset.txt
$ md5sum charset.scos2
87ea4967605a5ba4d69ff6cf0fb541f5 charset.scos2
Anyone get anything different?
One thing that is mildly annoying: if the encoded line of text
happens to start with a "> ", then thunderbird thinks its quoted
text.
Richard Heathfield <rjh@cpax.org.uk> wrote:
Given this input:
[long input snipped]
$md5sum charset.txt
d5c6d06587dbac07fed831293ff0580d charset.txt
$ md5sum charset.scos2
87ea4967605a5ba4d69ff6cf0fb541f5 charset.scos2
Anyone get anything different?
Mouse copy/paste from Tin running inside a Urxvt terminal results in identical md5's to yours above:
$ md5sum *
d5c6d06587dbac07fed831293ff0580d charset.txt
87ea4967605a5ba4d69ff6cf0fb541f5 charset.scos2
On 24/02/2025 18:08, Rich wrote:
Richard Heathfield <rjh@cpax.org.uk> wrote:
Given this input:
[long input snipped]
$md5sum charset.txt
d5c6d06587dbac07fed831293ff0580d charset.txt
$ md5sum charset.scos2
87ea4967605a5ba4d69ff6cf0fb541f5 charset.scos2
Anyone get anything different?
Mouse copy/paste from Tin running inside a Urxvt terminal results in
identical md5's to yours above:
$ md5sum *
d5c6d06587dbac07fed831293ff0580d charset.txt
87ea4967605a5ba4d69ff6cf0fb541f5 charset.scos2
Thanks for that. So it is beginning to look like a fair lot of
noise over not very much.
Richard Heathfield <rjh@cpax.org.uk> wrote:
On 24/02/2025 18:08, Rich wrote:
Richard Heathfield <rjh@cpax.org.uk> wrote:
Given this input:
[long input snipped]
$md5sum charset.txt
d5c6d06587dbac07fed831293ff0580d charset.txt
$ md5sum charset.scos2
87ea4967605a5ba4d69ff6cf0fb541f5 charset.scos2
Anyone get anything different?
Mouse copy/paste from Tin running inside a Urxvt terminal results in
identical md5's to yours above:
$ md5sum *
d5c6d06587dbac07fed831293ff0580d charset.txt
87ea4967605a5ba4d69ff6cf0fb541f5 charset.scos2
Thanks for that. So it is beginning to look like a fair lot of
noise over not very much.
I'd say if one is using a newsreader that /does/ perform such "transformations" -- and one is unaware such is happening, that for
those "ones" it is more than noise. In fact, with Tin, if one
surrounds words/strings with stars or forward slashes, Tin attempts to highlight those, and IIRC it hides the stars/slashes, so depending on
just what character sequence is output, I might have had a different
md5 from mouse copy/paste.
I.e. the word bold below should end up bold in Tin but without stars:
*bold*
On 24/02/2025 21:36, Rich wrote:
Richard Heathfield <rjh@cpax.org.uk> wrote:
On 24/02/2025 18:08, Rich wrote:
Richard Heathfield <rjh@cpax.org.uk> wrote:
Given this input:
[long input snipped]
$md5sum charset.txt
d5c6d06587dbac07fed831293ff0580d charset.txt
$ md5sum charset.scos2
87ea4967605a5ba4d69ff6cf0fb541f5 charset.scos2
Anyone get anything different?
Mouse copy/paste from Tin running inside a Urxvt terminal results in
identical md5's to yours above:
$ md5sum *
d5c6d06587dbac07fed831293ff0580d charset.txt
87ea4967605a5ba4d69ff6cf0fb541f5 charset.scos2
Thanks for that. So it is beginning to look like a fair lot of
noise over not very much.
I'd say if one is using a newsreader that /does/ perform such
"transformations" -- and one is unaware such is happening, that for
those "ones" it is more than noise. In fact, with Tin, if one
surrounds words/strings with stars or forward slashes, Tin attempts to
highlight those, and IIRC it hides the stars/slashes, so depending on
just what character sequence is output, I might have had a different
md5 from mouse copy/paste.
I.e. the word bold below should end up bold in Tin but without stars:
*bold*
My newsreader correctly echoed the asterisk characters, and your
newsreader correctly sent the text without corrupting the text. Here's
the article source (between the +rows):
+++++++++++++++++++++++++++++++++++++++
I.e. the word bold below should end up bold in Tin but without stars:
*bold*
And the word italics below should be in italics (if my terminal 'did' italics, that is):
/italics/
I suspect if you send back a reply with a 'starred' or 'slashed' word,
I won't see the stars or the slashes. But this is a lower likelyhood accidental pattern vs 2^2.
+++++++++++++++++++++++++++++++++++++++
So your reader works and so does mine, and it seems that neither is a
good example of a reader that corrupts data.
Yes, of course it's true that if you're using broken software you might
have trouble with corrupted data, but frankly if my accounts software
started turning 7s into 1s, I would achieve better results by replacing
my accounts software than I would by asking my accountant to stop using
7s in his sums.
However, in this case, possibly suggesting that folks go looking for save/pipe/turn off options might be more fruitful than suggesting they
switch away from X to Y when they presumably have some preference for X
(or at least familarity with X).
On 24/02/2025 21:36, Rich wrote:
Richard Heathfield <rjh@cpax.org.uk> wrote:
On 24/02/2025 18:08, Rich wrote:
Richard Heathfield <rjh@cpax.org.uk> wrote:
Given this input:
[long input snipped]
$md5sum charset.txt
d5c6d06587dbac07fed831293ff0580d charset.txt
$ md5sum charset.scos2
87ea4967605a5ba4d69ff6cf0fb541f5 charset.scos2
Anyone get anything different?
Mouse copy/paste from Tin running inside a Urxvt terminal results in
identical md5's to yours above:
$ md5sum *
d5c6d06587dbac07fed831293ff0580d charset.txt
87ea4967605a5ba4d69ff6cf0fb541f5 charset.scos2
Thanks for that. So it is beginning to look like a fair lot of
noise over not very much.
I'd say if one is using a newsreader that /does/ perform such
"transformations" -- and one is unaware such is happening, that for
those "ones" it is more than noise. In fact, with Tin, if one
surrounds words/strings with stars or forward slashes, Tin attempts to
highlight those, and IIRC it hides the stars/slashes, so depending on
just what character sequence is output, I might have had a different
md5 from mouse copy/paste.
I.e. the word bold below should end up bold in Tin but without stars:
*bold*
My newsreader correctly echoed the asterisk characters, and your
newsreader correctly sent the text without corrupting the text.
Here's the article source (between the +rows):
+++++++++++++++++++++++++++++++++++++++
I.e. the word bold below should end up bold in Tin but without stars:
*bold*
And the word italics below should be in italics (if my terminal
'did'
italics, that is):
/italics/
So your reader works and so does mine, and it seems that neither
is a good example of a reader that corrupts data.
Yes, of course it's true that if you're using broken software you
might have trouble with corrupted data, but frankly if my accounts
software started turning 7s into 1s, I would achieve better results
by replacing my accounts software than I would by asking my
accountant to stop using 7s in his sums.
On 25/02/2025 16:32, Rich wrote:
However, in this case, possibly suggesting that folks go looking for
save/pipe/turn off options might be more fruitful than suggesting they
switch away from X to Y when they presumably have some preference for X
(or at least familarity with X).
Absolutely - free country and all that. (Or perhaps they've been
bitten by Y.)
But people who choose to use newsreaders that can't handle
printable ASCII non-destructively cannot reasonably expect
software developers to amend their code as a workaround. I would
reason that it's the people with the problem who need to own and
address their problem. That's not to say they can't seek and
receive help and advice, of course, but they can't expect to be
able to bend other people around them.
On Mon, 10 Feb 2025 03:29:37 +0000, Richard Heathfield wrote:
01000001011...
I'm afraid I haven't been following the discussion on SCOS Message Format, but would offer a comment, which may have been covered. If not here it is:
Due to some recent technical challenges I have been reading USENET using
two newsreaders; Thunderbird and Pan. Both are excellent, but handle
certain parts of the character set differently.
Under some circumstances, Thunderbird removes the caret (character 94
dec.) and makes the following character a superscript - indicating one character raised to the power of the second. This is excellent when that
is what is intended. Not so good, when it is not what was intended. Pan doesn't do this.
Pan uses the asterisk (character 42 dec.) to embolden characters. I think
it looks for pairs and intends to act on anything between, but the rules concerning spaces and other characters may complicate the interpretation.
As I recall, the asterisks are not removed. I'm not sure exactly what's
going on, but a sequence of glyphs seems to result in the loss of
character return and line feeds.
There are probably some other more subtle consequences, but I don't think
we can assume that all readers will reliably receive all the characters we intend them to receive, other than the basic alphanumeric ones, via their various newsreaders. Checking compatibility would be challenging and there isn't much you can do about it.
Consequently, if SCOS introduces a lot of these lesser used characters,
which may have different actions in different newsreaders, we're going to confuse all but the most technical and dedicated readers (this is possibly considered a good thing).
Just a thought for consideration.
Well, a newsreader that can't correctly render ASCII is - um... - shall
we say in urgent need of a bug report?
SCOS does the best it can to help Pan out by leaving untouched anything
it doesn't understand. Perhaps Pan could extend SCOS the same courtesy?
;-)
Seriously, though, I don't see what can be done. We could remove caret
from the alphabet... but then who's to say that the next Pan release
won't interpret zz as a snooze emoji and 314 as a Greek pi symbol? We
could end up with no alphabet at all!
The following is based on my partial and limited understanding of the
matter. None of this is very important, nor causing any significant
problems, but maybe should be considered. It could be wrong...
On Fri, 21 Feb 2025 02:54:21 +0000, Richard Heathfield wrote:
Well, a newsreader that can't correctly render ASCII is - um... - shall
we say in urgent need of a bug report?
Not really. The ASCII specification includes caret notation for control characters. In has been like that since the early days.
<https://en.wikipedia.org/wiki/ASCII#Table_of_codes>
The interpretation of the caret and the subsequent character will be
platform and application dependant.
PS I do like SCOS.
On Sat, 22 Feb 2025 06:36:18 +0000, Richard Heathfield wrote:
Irrelevant, I'm afraid, David.
I don't believe so.
Any newsreader will have at its heart a terminal emulation function, where the characteristics of the early electromechanical terminals are
accurately reproduced via software.
Although convenient to forget that, it
remains true.
The details of the implementation of the caret control set
will have depended on the details of the emulation chosen.
The newsreader software developers may, like us, may have forgotten about this detail but it will remain embedded in any software that has been with
us for as long as USENET.
For more recently developed readers, the
behaviour may be less well defined. In either case it would be unwise to assume that sending a caret followed by a capital letter A to the reader
will result in those two characters being displayed.
A perfectly correct
and compliant implementation will not. If the emulation says it should
treat it as a control sequence, that is what it will do.
Irrelevant, I'm afraid, David.