$ echo "Hello sci.crypt community. This is a test with seriation." | seriation Preprocessed text in lines:

HELLOSCICRYPTCOMMUNIT
YTHISISATESTWITHSERIA
TI
ON

Seriation:

HY ET LH LI OS SI CS IA CT RE YS PT TW CI OT MH MS UE NR II TA
TO IN

Seriation was used in the German WWII cipher Doppelkastenschlüssel
and I thought it is pretty cool. However, I did not managed yet to
understand how encryption and decryption works.

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Seriation is not a cipher, it is a technique used to build ciphers. Like substitution and permutation, of which it is a form of the latter.

It can be useful eg with digram-based ciphers like Playfair, where it
makes cryptanalysis based on the known frequency of occurrence of
digrams in the plaintext language much harder or impossible.

Peter Fairbrother



On 07/12/2024 15:27, Stefan Claas wrote:

$ echo "Hello sci.crypt community. This is a test with seriation." | seriation
Preprocessed text in lines:

HELLOSCICRYPTCOMMUNIT
YTHISISATESTWITHSERIA
TI
ON

Seriation:

HY ET LH LI OS SI CS IA CT RE YS PT TW CI OT MH MS UE NR II TA
TO IN

Seriation was used in the German WWII cipher Doppelkastenschlüssel
and I thought it is pretty cool. However, I did not managed yet to
understand how encryption and decryption works.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Peter Fairbrother wrote:

Seriation is not a cipher, it is a technique used to build ciphers. Like substitution and permutation, of which it is a form of the latter.

It can be useful eg with digram-based ciphers like Playfair, where it
makes cryptanalysis based on the known frequency of occurrence of
digrams in the plaintext language much harder or impossible.

Yes, thank you for the explanation! It could also be a nice replacement
for SCOS, here in sci.crypt, combined with an A-Z encoder/decoder and a
padding program, since SCOS was cracked and floating around on Bitmessage
and code for seriation I have not seen yet elsewhere.

As an example:

$ echo "I wish the sci.crypt community a nice weekend!" | pad -p 64 \
| az -l 16 > message.txt

$ cat message.txt

UJCQXHGZXDGYSAHU
WIGVSAHTWDGZSOGT
XCHZXAHUSAGTWPGN
WNHVWOGZXEHZSAGR
SAGOWJGTWFCQXHGV
WFGLWFGOWECRQKES
VJFXUJFSVKEOVEER
QJAQQAAQQAAQQAAQ

$ seriation < message.txt

UW JI CG QV XS HA GH ZT XW DD GG YZ SS AO HG UT
XW CN HH ZV XW AO HG UZ SX AE GH TZ WS PA GG NR
SW AF GG OL WW JF GG TO WW FE CC QR XQ HK GE VS
VQ JJ FA XQ UQ JA FA SQ VQ KA EA OQ VQ EA EA RQ

Maybe worth a little challenge, to have such a
format for sci.crypt, with an AZ encoder, a pad
and seriation program. :-)

--
Regards
Stefan

P.S. I have figured out the encryption/decrption
process for Doppelkastenschlüssel. :-) (Did not
had enough coffee ... :-D)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas <pollux@tilde.club> wrote:

Peter Fairbrother wrote:

Seriation is not a cipher, it is a technique used to build ciphers. Like
substitution and permutation, of which it is a form of the latter.

It can be useful eg with digram-based ciphers like Playfair, where it
makes cryptanalysis based on the known frequency of occurrence of
digrams in the plaintext language much harder or impossible.

Yes, thank you for the explanation! It could also be a nice replacement
for SCOS, here in sci.crypt, combined with an A-Z encoder/decoder and a padding program, since SCOS was cracked and floating around on Bitmessage
and code for seriation I have not seen yet elsewhere.

SCOS was never meant to be in any way 'secure'. Hense the name: (S)ci
(C)rypt (O)pen (S)ecret. It was meant as a fun exercise at
cryptanalysis and working out a crypt/decrypt algorithm given examples
of encrypted messages.

Maybe worth a little challenge, to have such a format for sci.crypt,
with an AZ encoder, a pad and seriation program. :-)

And why would you think it would not also eventually be "cracked" and
"floating around on bitmessage" after some time?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich wrote:

And why would you think it would not also eventually be "cracked" and "floating around on bitmessage" after some time?

I do not think that, I only propose something else to use.

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas wrote:

Maybe worth a little challenge, to have such a
format for sci.crypt, with an AZ encoder, a pad
and seriation program. :-)

Another example message: :-)

$ echo "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" | pad -p 80 | az -l 8 | seriation

UW IP GG VV WX MG GG MV
XW CF HE ZZ WX PH GG OZ
XX DF GG YR XW JM GG PM
WW BF GF OT WX JF GG TO
WQ EK GE RO XV JD CF RW
VV GI FE RP VU HK EE MZ
UV FH EE MO VV KB FE TY
VU AM EE MW UU DG EF PT
UV OF EF MT VU IF EF UW
SQ DA AA QQ QQ AA AA QQ

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

And why would you think it would not also eventually be "cracked" and
"floating around on bitmessage" after some time?

I do not think that, I only propose something else to use.

Ok, fair enough. But does it add anything of value over SCOS? SCOS's
'value' was in the practice of analysis and working out the algorithm
given just the encrypted messages (plus an 'oracle' who would encrypt
requested messages).

The actual 'obsfucation' factor was secondary.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas wrote:

Stefan Claas wrote:

Maybe worth a little challenge, to have such a
format for sci.crypt, with an AZ encoder, a pad
and seriation program. :-)

Another example message: :-)

$ echo "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" | pad -p 80 | az -l 8 | seriation

UW IP GG VV WX MG GG MV
XW CF HE ZZ WX PH GG OZ
XX DF GG YR XW JM GG PM
WW BF GF OT WX JF GG TO
WQ EK GE RO XV JD CF RW
VV GI FE RP VU HK EE MZ
UV FH EE MO VV KB FE TY
VU AM EE MW UU DG EF PT
UV OF EF MT VU IF EF UW
SQ DA AA QQ QQ AA AA QQ

Same message with pad -p 320 and az -l 16 settings:

UX IC GH VZ WW MP GG MO WW PF GE VZ XX GH GG VZ
XW DB GG YO XW JJ GG PT XW FF GF RT WX MF GG MO
WU EG GE RU XU JK CE RP QV KG EF OQ UV EF EF ZU
VU BD EF RY UV CF EE LW VU JF EF TS UU MB EE NR
VV HA EE LZ VU BI FE QN VV IA EF WV UU JB FE ZM
UV OG EF RX VU BL EE YK UU EI EF VQ VV DC FE ZM
UU DO EF SS VV KH EE LX UU BM FF XY UU LN FF TT
UV OB EF PY UU OM FF UY UU FE EF RV UV CG EF YX
VU EN EF VT VV AF EF KS UV FF EF RS UU PD EE OM
VV JA EE NP VU HC FE VO VU CD EE XS VV HE FF QK
VV HB EE ZN VV KE EE OL VV EC FE ZN VU EF EE SO
UU GG EF LT VV CB FF SK VV BB EE MK UV PA FF TS
UU JO FF VR VV HF EE XP VU HN FF ZZ UV GG FF XW
VU BK EF OS UU OO EF NR UU LI EE OK VU FC FF QU
UU FD FE UL VU BI EE VZ VV JE FE ZR VV KI FE KK
UV CC FF QW UU KF EF RY UV HC EE PT UV IC EF OV
UU FC EF OK UU OJ EE MY UV DJ EF PX UU JO EE TL
VU HC FF RS VV IC EE ZZ VU GH EE PM VV IK FE SZ
UU NN FE QM VV IK EF XY VV DB EE LU UU PL FE XV
UR GD FA XR UQ FA FA VQ UQ HA EA NQ UQ PA EA TQ

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

And why would you think it would not also eventually be "cracked" and "floating around on bitmessage" after some time?

I do not think that, I only propose something else to use.

Ok, fair enough. But does it add anything of value over SCOS? SCOS's 'value' was in the practice of analysis and working out the algorithm
given just the encrypted messages (plus an 'oracle' who would encrypt requested messages).

The actual 'obsfucation' factor was secondary.

To make it short, SCOS is dead and I liked to propose something
new for the community, so that we have more traffic here.

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07/12/2024 15:27, Stefan Claas wrote:

Seriation was used in the German WWII cipher Doppelkastenschlüssel
and I thought it is pretty cool. However, I did not managed yet to
understand how encryption and decryption works.

Doppelkastenschlüssel was a hand cipher of the type known as double
Playfair, or horizontal two square, used by the German Army throughout
WW2 as a field cipher.

It works pretty much like Playfair except there are two 5x5 Polybius
squares; the first letter of a plaintext digraph goes in the left square
and the second letter goes in the right square. As in Playfair, the
opposite corners of the rectangle form the ciphertext, with the letter
from the right hand box first.

If both letters were on the same horizontal line the previous letters in
the line were used, also usually with the letter from the right hand box
first.

The squares were random, not based on keywords (so they seldom ended
XYZ), and were distributed using a key network.

21-letter (usually) seriation was used to make both digraph frequency
analysis and transparency analysis harder.

Cascaded substitution, where the results of the digraph substitution
were used as inputs to a second substitution, was also used (sometimes).

It was broken by both US and UK cryptanalysts:

media.defense.gov/2021/Jun/29/2002751757/-1/-1/0/WORLD_WAR_II.PDF


A similar two-square cypher was also used by the Germans later in WW1,
but based on keywords and without seriation.



Peter Fairbrother

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Peter Fairbrother wrote:

On 07/12/2024 15:27, Stefan Claas wrote:

Seriation was used in the German WWII cipher Doppelkastenschlüssel
and I thought it is pretty cool. However, I did not managed yet to understand how encryption and decryption works.

Doppelkastenschlüssel was a hand cipher of the type known as double Playfair, or horizontal two square, used by the German Army throughout
WW2 as a field cipher.

It works pretty much like Playfair except there are two 5x5 Polybius
squares; the first letter of a plaintext digraph goes in the left square
and the second letter goes in the right square. As in Playfair, the
opposite corners of the rectangle form the ciphertext, with the letter
from the right hand box first.

If both letters were on the same horizontal line the previous letters in
the line were used, also usually with the letter from the right hand box first.

The squares were random, not based on keywords (so they seldom ended
XYZ), and were distributed using a key network.

21-letter (usually) seriation was used to make both digraph frequency analysis and transparency analysis harder.

According to the German WWII documentaion 17-letters per two lines,
a blank line and then again 17-letters per two lines and so on.

Cascaded substitution, where the results of the digraph substitution
were used as inputs to a second substitution, was also used (sometimes).

It was broken by both US and UK cryptanalysts:

media.defense.gov/2021/Jun/29/2002751757/-1/-1/0/WORLD_WAR_II.PDF

A similar two-square cypher was also used by the Germans later in WW1,
but based on keywords and without seriation.

Thanks for the info. I have read the following German docs, one original
from WWII[1] and the Wikipedia[2] article.

[1] <https://cryptocellar.org/wmc/schluesselanleitung-dk-1940.pdf>
[2] <https://de.wikipedia.org/wiki/Doppelkastenschl%C3%BCssel>

Interesting also Klaus Schmeh's articles on this subject.

<https://scienceblogs.de/klausis-krypto-kolumne/tag/doppelkasten-schluessel/>

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/12/2024 19:52, Stefan Claas wrote:

Peter Fairbrother wrote:

21-letter (usually) seriation was used to make both digraph frequency
analysis and transparency analysis harder.

According to the German WWII documentation 17-letters per two lines,
a blank line and then again 17-letters per two lines and so on.

There were variations, but the Army and most others used 21 letters. I
don't know what the blank lines were.

Peter Fairbrother

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Peter Fairbrother wrote:

On 08/12/2024 19:52, Stefan Claas wrote:

Peter Fairbrother wrote:

21-letter (usually) seriation was used to make both digraph frequency analysis and transparency analysis harder.

According to the German WWII documentation 17-letters per two lines,
a blank line and then again 17-letters per two lines and so on.

There were variations, but the Army and most others used 21 letters. I
don't know what the blank lines were.

Well, the reason for the blank line are IIRC not explained in the docs.

Anyways, I came up now with the idea to use hex values, so that
we may come up with some programs, for use in sci.crypt ... :-)

$ echo -n 'Hello sci.crypt! :-)' | xxd -ps | dkhf
48656C6C6F207363
692E637279707421
203A
2D29

$ echo -n 'Hello sci.crypt! :-)' | xxd -ps | dkhf | seriation
46 89 62 5E 66 C3 67 C2 67 F9 27 00 77 34 62 31
22 0D 32 A9

$ dokahex
Tagesschlüssel für den 09.12.2024 (UTC)

Tagesschlüssel 1:
Kasten: A Kasten: B
0 4 6 A 6 9 E 3
F 1 3 E 7 2 4 D
7 C D 5 1 C 0 5
B 2 9 8 F 8 A B

And to simplify the encryption/decryption process, we could
do it this way. We only mirror from a -> b and b -> a, like:

With the seriation from above and the example box a and b:

Ciphertext: 90 B4 E1 etc.

This doublebox hex variation with only mirroring is IMHO
easy and would allow to transmit small binary blobs. :-)

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas wrote:

Stefan Claas wrote:

Anyways, I came up now with the idea to use hex values, so that
we may come up with some programs, for use in sci.crypt ... :-)

$ echo -n 'Hello sci.crypt! :-)' | xxd -ps | dkhf
48656C6C6F207363
692E637279707421
203A
2D29

$ echo -n 'Hello sci.crypt! :-)' | xxd -ps | dkhf | seriation
46 89 62 5E 66 C3 67 C2 67 F9 27 00 77 34 62 31
22 0D 32 A9

To bring messages in the right hex format for seriation, which
can be a bit tricky, I suggest to use padding to the nearest
multiple of 16 bytes on the original message(s), prior converting
to hex and seriation.

Corrected above text.

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas wrote:

Anyways, I came up now with the idea to use hex values, so that
we may come up with some programs, for use in sci.crypt ... :-)

$ echo -n 'Hello sci.crypt! :-)' | xxd -ps | dkhf
48656C6C6F207363
692E637279707421
203A
2D29

$ echo -n 'Hello sci.crypt! :-)' | xxd -ps | dkhf | seriation
46 89 62 5E 66 C3 67 C2 67 F9 27 00 77 34 62 31
22 0D 32 A9

To bring messages in the right hex format for seriation, which
can be a bit tricky, I suggest to use padding (multiple of 16
bytes) on the original message(s), prior converting to hex and
seriation.

This guarantees that seriation always works properly.

And padding is in general good practice.

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas wrote:

$ echo -n 'Hello sci.crypt! :-)' | xxd -ps | dkhf
48656C6C6F207363
692E637279707421
203A
2D29

$ echo -n 'Hello sci.crypt! :-)' | xxd -ps | dkhf | seriation
46 89 62 5E 66 C3 67 C2 67 F9 27 00 77 34 62 31
22 0D 32 A9

$ dokahex
Tagesschlüssel für den 09.12.2024 (UTC)

Tagesschlüssel 1:
Kasten: A Kasten: B
0 4 6 A 6 9 E 3
F 1 3 E 7 2 4 D
7 C D 5 1 C 0 5
B 2 9 8 F 8 A B

And to simplify the encryption/decryption process, we could
do it this way. We only mirror from a -> b and b -> a, like:

With the seriation from above and the example box a and b:

Ciphertext: 90 B4 E1 etc.

This doublebox hex variation with only mirroring is IMHO
easy and would allow to transmit small binary blobs. :-)

I have now four programs ready. :-)

1. dkh (Doppelkasten Hex = doublebox hex)
2. dks (Doppelkasten Seration = doublebox seriation)
3. dkt (Doppelkasten Tagesschlüssel = doublebox daily keys)
4. dkk (Doppelkasten Krypto = doublebox crypto)

dkh takes an input file from stdin and pads it with 16 bytes
and produces always equal number of lines, due to padding, with
an output of 8 hex values per line. dks does then the seriation
and produces 16 hex bytes per line, with spaces between the values.

dkt produces n numbers of keys A and B per day, UTC time. With
a second version (for private use and not for sci.crpt) one can
generate the keys with a password and salt.

Finally dkk does the automatic encryption from the dks file and
with a -d parameter the decryption, while using the produced key
files from dkt.

In the next couple of days I like then to run a Christmas Challenge,
with a given cipher message, to see how fast your rig can crack the
provided encrypted message. There are small prices for the Winner
and Runner-Up. I like to do this because I like to see how fast can
such messages been cracked, while I for myself do not do cryptanalysis
and leave it to the experts like you.

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas wrote:

Stefan Claas wrote:

$ echo -n 'Hello sci.crypt! :-)' | xxd -ps | dkhf
48656C6C6F207363
692E637279707421
203A
2D29

$ echo -n 'Hello sci.crypt! :-)' | xxd -ps | dkhf | seriation
46 89 62 5E 66 C3 67 C2 67 F9 27 00 77 34 62 31
22 0D 32 A9

$ dokahex
Tagesschlüssel für den 09.12.2024 (UTC)

Tagesschlüssel 1:
Kasten: A Kasten: B
0 4 6 A 6 9 E 3
F 1 3 E 7 2 4 D
7 C D 5 1 C 0 5
B 2 9 8 F 8 A B

And to simplify the encryption/decryption process, we could
do it this way. We only mirror from a -> b and b -> a, like:

With the seriation from above and the example box a and b:

Ciphertext: 90 B4 E1 etc.

This doublebox hex variation with only mirroring is IMHO
easy and would allow to transmit small binary blobs. :-)

I have now four programs ready. :-)

1. dkh (Doppelkasten Hex = doublebox hex)
2. dks (Doppelkasten Seration = doublebox seriation)
3. dkt (Doppelkasten Tagesschlüssel = doublebox daily keys)
4. dkk (Doppelkasten Krypto = doublebox crypto)

Sample run with yesterdays's message and today's keys:

$ echo -n 'Hello sci.crypt! :-)' | dkh > message.txt

$ cat message.txt
48656C6C6F207363
692E637279707421
203A2D294A53594F
4848575350535A44

$ dks < message.txt > seriation.txt

$ cat seriation.txt
46 89 62 5E 66 C3 67 C2 67 F9 27 00 77 34 62 31
24 08 34 A8 25 D7 25 93 45 A0 55 33 55 9A 44 F4

$ dkk -k keys.txt < seriation.txt > ciphertext.txt

$ cat ciphertext.txt
06 2B 68 8E 66 4D 62 48 62 AB 72 C4 F2 5C 68 59
7C C5 5C B5 73 32 73 1D 03 B4 83 5D 83 1F 0C AC

$ cat keys.txt
Daily Keys for Dec.10.2024 (UTC)

Daily Keys 1:
Box: A Box: B
A B 8 3 B 9 2 5
7 E 0 4 F E C 0
C 1 F 9 4 D A 1
6 D 2 5 6 3 7 8

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas wrote:

Stefan Claas wrote:

Stefan Claas wrote:

$ echo -n 'Hello sci.crypt! :-)' | xxd -ps | dkhf
48656C6C6F207363
692E637279707421
203A
2D29

$ echo -n 'Hello sci.crypt! :-)' | xxd -ps | dkhf | seriation
46 89 62 5E 66 C3 67 C2 67 F9 27 00 77 34 62 31
22 0D 32 A9

$ dokahex
Tagesschlüssel für den 09.12.2024 (UTC)

Tagesschlüssel 1:
Kasten: A Kasten: B
0 4 6 A 6 9 E 3
F 1 3 E 7 2 4 D
7 C D 5 1 C 0 5
B 2 9 8 F 8 A B

And to simplify the encryption/decryption process, we could
do it this way. We only mirror from a -> b and b -> a, like:

With the seriation from above and the example box a and b:

Ciphertext: 90 B4 E1 etc.

This doublebox hex variation with only mirroring is IMHO
easy and would allow to transmit small binary blobs. :-)

I have now four programs ready. :-)

1. dkh (Doppelkasten Hex = doublebox hex)
2. dks (Doppelkasten Seration = doublebox seriation)
3. dkt (Doppelkasten Tagesschlüssel = doublebox daily keys)
4. dkk (Doppelkasten Krypto = doublebox crypto)

Added dkt+, with -p for password and -s for salt parameter, so
that it can be used outside of sci.crypt. :-)

Additionally dkk can now use key sequences, like -s 23,5,17 etc.,
for using mutliple keys, thus making it harder to crack. Default
is to use keys 1,2 from the daily list.

Example run:

$ echo -n 'Hello sci.crypt! :-)' | dkh > message.txt
$ cat message.txt
48656C6C6F207363
692E637279707421
203A2D2946584256
4E465A5A4E535A59

$ dks < message.txt > seriation.txt
$ cat seriation.txt
46 89 62 5E 66 C3 67 C2 67 F9 27 00 77 34 62 31
24 0E 34 A6 25 DA 25 9A 44 6E 55 83 45 2A 55 69

$ dkk -s 5,1,3 < seriation.txt > ciphertext.txt
$ cat ciphertext.txt
C0 AF 9B 79 90 24 97 2B 97 1F 47 EE F7 5D 9B 5A
4D E9 5D D0 42 38 42 B8 CD 99 72 A4 C2 48 72 9F

$ cat keys.txt
Tagesschlüssel für den 14.12.2024 (UTC)

Tagesschlüssel 1:
Kasten: A Kasten: B
5 2 7 B C B F 5
0 E 6 A 6 1 2 D
F 9 C 3 7 E 8 3
4 D 1 8 4 9 0 A

Tagesschlüssel 2:
Kasten: A Kasten: B
3 9 1 B 6 9 B 5
C 4 D F E 4 2 1
E A 7 2 A C 0 F
0 6 8 5 7 D 3 8

Tagesschlüssel 3:
Kasten: A Kasten: B
4 A F 8 E 9 3 7
1 6 D 5 C 2 1 0
2 C E 0 D B 5 8
B 9 7 3 F 4 A 6

Tagesschlüssel 4:
Kasten: A Kasten: B
5 B F 0 E F 4 2
2 E D 9 6 0 B 1
1 C 3 7 3 A C 9
6 8 A 4 8 5 D 7

Tagesschlüssel 5:
Kasten: A Kasten: B
7 1 D A 2 3 7 6
3 B 2 5 9 B D C
E 8 0 9 1 F 4 5
C F 4 6 0 A E 8

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas wrote:

Added dkt+, with -p for password and -s for salt parameter, so
that it can be used outside of sci.crypt. :-)

Additionally dkk can now use key sequences, like -s 23,5,17 etc.,
for using mutliple keys, thus making it harder to crack. Default
is to use keys 1,2 from the daily list.

Uploaded to GitHub.

<https://github.com/706f6c6c7578/Doppelkastenschluessel-Hex>

--
Regards
Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/12/2024 17:10, Stefan Claas wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

And why would you think it would not also eventually be "cracked" and
"floating around on bitmessage" after some time?

I do not think that, I only propose something else to use.

Ok, fair enough. But does it add anything of value over SCOS? SCOS's
'value' was in the practice of analysis and working out the algorithm
given just the encrypted messages (plus an 'oracle' who would encrypt
requested messages).

The actual 'obsfucation' factor was secondary.

To make it short, SCOS is dead and I liked to propose something
new for the community, so that we have more traffic here.

scos2 31 41

x=i# rB b(N5m cFt# g)f3 :Q(VF2

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/12/2024 05:58, Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Peter Fairbrother wrote:

Seriation is not a cipher, it is a technique used to build ciphers. Like >>> substitution and permutation, of which it is a form of the latter.

It can be useful eg with digram-based ciphers like Playfair, where it
makes cryptanalysis based on the known frequency of occurrence of
digrams in the plaintext language much harder or impossible.

Yes, thank you for the explanation! It could also be a nice replacement
for SCOS, here in sci.crypt, combined with an A-Z encoder/decoder and a
padding program, since SCOS was cracked and floating around on Bitmessage
and code for seriation I have not seen yet elsewhere.

SCOS was never meant to be in any way 'secure'. Hense the name: (S)ci (C)rypt (O)pen (S)ecret. It was meant as a fun exercise at
cryptanalysis and working out a crypt/decrypt algorithm given examples
of encrypted messages.

I think that's almost, but not quite, 100% correct.

If I recall correctly (and it's entirely possible that I don't),
what I was after in SCOS was something just a little bit harder
to read than ROT-13, because people here were having ROT-13
conversations that they clearly believed some regulars (eg aob)
couldn't read, but I couldn't quite bring myself to believe that
anyone could be incapable of decrypting ROT-13.

The point of SCOS was a little like the point of the scary devil
monastery. If you could post in asr, it proved you were good
enough to post in asr, and if you could post and decrypt SCOS
messages it proved... well, that you were good enough to take
part in SCOS conversations.

But yes, being easy (but not /quite/ trivial) to crack was indeed
at the heart of SCOS.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

On 08/12/2024 17:10, Stefan Claas wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

And why would you think it would not also eventually be "cracked" and "floating around on bitmessage" after some time?

I do not think that, I only propose something else to use.

Ok, fair enough. But does it add anything of value over SCOS? SCOS's 'value' was in the practice of analysis and working out the algorithm given just the encrypted messages (plus an 'oracle' who would encrypt requested messages).

The actual 'obsfucation' factor was secondary.

To make it short, SCOS is dead and I liked to propose something
new for the community, so that we have more traffic here.

scos2 31 41

x=i# rB b(N5m cFt# g)f3 :Q(VF2

$ echo "long live SCOS3 with German Umlauts support! :-)" | ./scos3 e 31 41 $Pz' e$Zt ^\v>+ Kh'R Ö>t[N7 [r#Q(Qä ,j&Pz\lC 5?c

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

On 08/12/2024 17:10, Stefan Claas wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

And why would you think it would not also eventually be "cracked" and "floating around on bitmessage" after some time?

I do not think that, I only propose something else to use.

Ok, fair enough. But does it add anything of value over SCOS? SCOS's 'value' was in the practice of analysis and working out the algorithm given just the encrypted messages (plus an 'oracle' who would encrypt requested messages).

The actual 'obsfucation' factor was secondary.

To make it short, SCOS is dead and I liked to propose something
new for the community, so that we have more traffic here.

scos2 31 41

x=i# rB b(N5m cFt# g)f3 :Q(VF2

56 4C 66 89 66 95 77 33 22 00 67 14 76 0F 72 00
52 30 47 37 46 F5 56 3C 36 2C 22 00 62 1E 72 3E
25 EA 44 F2 45 73 45 B5 45 32 55 41 45 99 55 17
(Doppelkasten-Hex with seriation applied...:-))

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/02/2025 11:55, Stefan Claas wrote:

Richard Heathfield wrote:

On 08/12/2024 17:10, Stefan Claas wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

And why would you think it would not also eventually be "cracked" and >>>>>> "floating around on bitmessage" after some time?

I do not think that, I only propose something else to use.

Ok, fair enough. But does it add anything of value over SCOS? SCOS's >>>> 'value' was in the practice of analysis and working out the algorithm
given just the encrypted messages (plus an 'oracle' who would encrypt
requested messages).

The actual 'obsfucation' factor was secondary.

To make it short, SCOS is dead and I liked to propose something
new for the community, so that we have more traffic here.

scos2 31 41

x=i# rB b(N5m cFt# g)f3 :Q(VF2

$ echo "long live SCOS3 with German Umlauts support! :-)" | ./scos3 e 31 41 $Pz' e$Zt ^\v>+ Kh'R Ö>t[N7 [r#Q(Qä ,j&Pz\lC 5?c

Regards
Stefan

scos2 59 26

8q !<Ss(Fhw#F Z!> [cm)DJ\ Vx^Ekr)Ng 4.N4%Ar2AbF #,i$H Xz-Fe7.T
M1-Qji <k0 BPm[<Y7>I t+?i8\ Mu2/ P6&Nu&'Pu% ,d!= Wk7FS w:!
h$#V4%Di1 tr0)CR">U,


--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas wrote:

Richard Heathfield wrote:

On 08/12/2024 17:10, Stefan Claas wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

And why would you think it would not also eventually be "cracked" and
"floating around on bitmessage" after some time?

I do not think that, I only propose something else to use.

Ok, fair enough. But does it add anything of value over SCOS? SCOS's 'value' was in the practice of analysis and working out the algorithm given just the encrypted messages (plus an 'oracle' who would encrypt requested messages).

The actual 'obsfucation' factor was secondary.

To make it short, SCOS is dead and I liked to propose something
new for the community, so that we have more traffic here.

scos2 31 41

x=i# rB b(N5m cFt# g)f3 :Q(VF2

$ echo "long live SCOS3 with German Umlauts support! :-)" | ./scos3 e 31 41 $Pz' e$Zt ^\v>+ Kh'R Ö>t[N7 [r#Q(Qä ,j&Pz\lC 5?c

For you to review (SCOS2 31 41):

RN7,uDb( [-Vu|upcf
"7Mq|x+W eZ&|w?bjWZ
51Gk?r&Q YT9Hn/adQT
zvAe~l9K S<3Io){!%
EAu}h;O4 $0Dg_e$(47
\.o)b[Iy 65]f%eWJM

sj[a)X3 ?d)H9 DD=X%O4Fv,m~d_U!L1Cs?j[a*R7IÄÖÜẞ.
zq:h[e! :j:O* KKO4Fv,m~d_U!L1Cs?j[a*R7Iy|päöüßB
6x\o:l( ;k{Z[ RRv,m~d_U!L1D
8zAq?n_ Ey:V# TT7kx\o@f+W$N3Eu>l#c)T9K0Br/i}Z&Q5GS

{^P5I2? M6B1 Cm#Q) M4Mj, X(P6R 2Hp_k

sj[a)X3 *g7W U9)V9C'Hc/a8R>*V5QP4

n/Y n k

KBr/k@V j 0=

N3[s=Q ^R5\ m>n%PCL3Ck B@ _W!D y#yT
%
#M2Fnav k nF Z <n s+sa
g6Hz/-A ~O TwT' I -W b4bJ
KmBr'Z }6
|

\s\ g9R"pvAv (i$IR <r[q P43UyN[
e
o&e"Or@p{!t[B$X$< M1I!

wIwBr .P9C8kz {n^dJz > "Q0LX
J!J3E w(W4V<M lAb;"M x Y)N% Cw:r3

v/_(i$I Q Y~
h
h#h &Rv, ' YW~R+z*p'E_ P4 LBAe . u = i!
5Iw@ g]g $G&/g\Z R c)Q7CoUS}N(v%l, 2Jp@P U8a~
{a^H yDy @Y/R"A . Fv?k-R<>1;uYrO^ f#S7/ <lD5
0Dr[ V*X E XC
Id{Q=y% ,qo
u&U2T>K =:j$ 6 m?Z^?
'g-N "K3 h 0f
a)Rz DmG _ <(

"F^:f<Y Q O$Pp:_#V@HvNov B6/wvI
ClFe}N H F3Gg{!)M+Fz'< sIj\<z
t~w U X6as:y[]

:R7Ksfz>U7U1nWW%]RA& ?>pa 7T ;p+?
n
p}s Q O$Pp:_#V@( X~O)(e

W8u0K3|l"N4rr,=W
*
{c*To?b/77M<z
/
~j;R
K
N5? ~ CX~M6Q;;v=ld J3oB
?fRa)G 'p V(Ix4
J
Q4I # ;i" 3 0QrG/
_Z+ 2 7Jn' & QY7b ; 9Z0PO*
!E% k] 'X:Q!|C
,f| $ !T",nai(lY _j!ZY]

)PBL2:h Z^ kz
E
LzD +W :w{my
:
<l@ 7I DyF>
.o~f0FnE_-j!ZFKyC[R_
M
H3Kl
e
l;e=Cw@vVV&0N
v
>
k
g<f=N7Noaq:Q6T82 RR?{vC4
<
/o>W
P
M)L2?n?UGW$,m|oi <<>8;l} m"X*b zBf+ b!ew>2' j)m"Qu5u|Y_-2R%Ex /i$V &BoDf.[dSYHlAw~g- U!.o? V{N +QwHh> g- Z&|zFt U b)Hx < m>Z'k*U81 i {Y"a=N6F,peCyL
t

1's?f* dI
q

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas wrote:

Stefan Claas wrote:

Richard Heathfield wrote:

On 08/12/2024 17:10, Stefan Claas wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

And why would you think it would not also eventually be "cracked" and
"floating around on bitmessage" after some time?

I do not think that, I only propose something else to use.

Ok, fair enough. But does it add anything of value over SCOS? SCOS's
'value' was in the practice of analysis and working out the algorithm given just the encrypted messages (plus an 'oracle' who would encrypt requested messages).

The actual 'obsfucation' factor was secondary.

To make it short, SCOS is dead and I liked to propose something
new for the community, so that we have more traffic here.

scos2 31 41

x=i# rB b(N5m cFt# g)f3 :Q(VF2

$ echo "long live SCOS3 with German Umlauts support! :-)" | ./scos3 e 31 41 $Pz' e$Zt ^\v>+ Kh'R Ö>t[N7 [r#Q(Qä ,j&Pz\lC 5?c

For you to review (SCOS2 31 41):

RN7,uDb( [-Vu|upcf
"7Mq|x+W eZ&|w?bjWZ
51Gk?r&Q YT9Hn/adQT
zvAe~l9K S<3Io){!%
EAu}h;O4 $0Dg_e$(47
\.o)b[Iy 65]f%eWJM

sj[a)X3 ?d)H9 DD=X%O4Fv,m~d_U!L1Cs?j[a*R7IÄÖÜẞ.
zq:h[e! :j:O* KKO4Fv,m~d_U!L1Cs?j[a*R7Iy|päöüßB
6x\o:l( ;k{Z[ RRv,m~d_U!L1D
8zAq?n_ Ey:V# TT7kx\o@f+W$N3Eu>l#c)T9K0Br/i}Z&Q5GS

{^P5I2? M6B1 Cm#Q) M4Mj, X(P6R 2Hp_k

sj[a)X3 *g7W U9)V9C'Hc/a8R>*V5QP4

n/Y n k

KBr/k@V j 0=

N3[s=Q ^R5\ m>n%PCL3Ck B@ _W!D y#yT
%
#M2Fnav k nF Z <n s+sa
g6Hz/-A ~O TwT' I -W b4bJ
KmBr'Z }6
|

\s\ g9R"pvAv (i$IR <r[q P43UyN[
e
o&e"Or@p{!t[B$X$< M1I!

wIwBr .P9C8kz {n^dJz > "Q0LX
J!J3E w(W4V<M lAb;"M x Y)N% Cw:r3

v/_(i$I Q Y~
h
h#h &Rv, ' YW~R+z*p'E_ P4 LBAe . u = i!
5Iw@ g]g $G&/g\Z R c)Q7CoUS}N(v%l, 2Jp@P U8a~
{a^H yDy @Y/R"A . Fv?k-R<>1;uYrO^ f#S7/ <lD5
0Dr[ V*X E XC
Id{Q=y% ,qo
u&U2T>K =:j$ 6 m?Z^?
'g-N "K3 h 0f
a)Rz DmG _ <(

"F^:f<Y Q O$Pp:_#V@HvNov B6/wvI
ClFe}N H F3Gg{!)M+Fz'< sIj\<z
t~w U X6as:y[]

:R7Ksfz>U7U1nWW%]RA& ?>pa 7T ;p+?
n
p}s Q O$Pp:_#V@( X~O)(e

W8u0K3|l"N4rr,=W
*
{c*To?b/77M<z
/
~j;R
K
N5? ~ CX~M6Q;;v=ld J3oB
?fRa)G 'p V(Ix4
J
Q4I # ;i" 3 0QrG/
_Z+ 2 7Jn' & QY7b ; 9Z0PO*
!E% k] 'X:Q!|C
,f| $ !T",nai(lY _j!ZY]

)PBL2:h Z^ kz
E
LzD +W :w{my
:
<l@ 7I DyF>
.o~f0FnE_-j!ZFKyC[R_
M
H3Kl
e
l;e=Cw@vVV&0N
v
>
k
g<f=N7Noaq:Q6T82 RR?{vC4
<
/o>W
P
M)L2?n?UGW$,m|oi <<>8;l} m"X*b zBf+ b!ew>2' j)m"Qu5u|Y_-2R%Ex /i$V &BoDf.[dSYHlAw~g- U!.o? V{N +QwHh> g- Z&|zFt U b)Hx < m>Z'k*U81 i {Y"a=N6F,peCyL
t

1's?f* dI
q

To get no warnings add
#include <wctype.h>

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas wrote:

Richard Heathfield wrote:

On 01/02/2025 11:55, Stefan Claas wrote:

Richard Heathfield wrote:

On 08/12/2024 17:10, Stefan Claas wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

And why would you think it would not also eventually be "cracked" and
"floating around on bitmessage" after some time?

I do not think that, I only propose something else to use.

Ok, fair enough. But does it add anything of value over SCOS? SCOS's
'value' was in the practice of analysis and working out the algorithm
given just the encrypted messages (plus an 'oracle' who would encrypt
requested messages).

The actual 'obsfucation' factor was secondary.

To make it short, SCOS is dead and I liked to propose something
new for the community, so that we have more traffic here.

scos2 31 41

x=i# rB b(N5m cFt# g)f3 :Q(VF2

$ echo "long live SCOS3 with German Umlauts support! :-)" | ./scos3 e 31 41
$Pz' e$Zt ^\v>+ Kh'R Ö>t[N7 [r#Q(Qä ,j&Pz\lC 5?c

Regards
Stefan

scos2 59 26

8q !<Ss(Fhw#F Z!> [cm)DJ\ Vx^Ekr)Ng 4.N4%Ar2AbF #,i$H Xz-Fe7.T M1-Qji
<k0 BPm[<Y7>I t+?i8\ Mu2/ P6&Nu&'Pu% ,d!= Wk7FS w:! h$#V4%Di1 tr0)CR">U,

SCOS2 47 11

3^?@ uqy) -||WWm26 /@LK Ilvv]>F CcW| q- ;@< WPmp "+>,SSjt
!9( <LNWjzx_ %BLLq0! [=>G HV uu$;/z .Tf0 ""'FHK Th 1%'
|\G PY1y n28]( ?r%="FK bct wv@ [AQYYh9 -_# FSSiq4"+ GNemiv
4##\ ~ Zv4* {/HTPZB

IMHO € and £ should be included as well, because we both and
many others live in Europe. ;-)

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/02/2025 12:19, Stefan Claas wrote:

<snip>

IIRC when encoding with Umlauts etc. at the same position
the original Umlauts will be shown.

Yes. By design, SCOS and SCOS2 preserve not only whitespace but
anything else they have not been told how to process[1]. We have
seen aob come a cropper by making whitespace significant in
Usenet ciphertexts, and that was precisely the problem I was
guarding against, but it also makes sense only to digest text it
knows about and pass through unmodified everything it doesn't,
thus making copy-and-paste ciphertext in an ASCII medium Just Work.

This should be not
the case IMHO.

It is of course your prerogative to disagree with my design, but
it is likewise my prerogative to prefer a deliberately ASCII-only
design for use in an ASCII environment such as Usenet.

I like bananas. You prefer pears. Great! By all means eat pears.
But I'll stick to bananas, thanks.

[1] It would be simple enough to make it understand /everything/,
but to do so requires departing from a printable ciphertext the
same size as its printable plaintext, could make the algorithm
significantly harder to crack from ciphertext only (and thus work
to defeat the whole point of the exercise), and might even (as in
your example, which I did look at BTW) result in a non-ASCII
source file.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

On 01/02/2025 11:55, Stefan Claas wrote:

Richard Heathfield wrote:

On 08/12/2024 17:10, Stefan Claas wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

And why would you think it would not also eventually be "cracked" and
"floating around on bitmessage" after some time?

I do not think that, I only propose something else to use.

Ok, fair enough. But does it add anything of value over SCOS? SCOS's
'value' was in the practice of analysis and working out the algorithm given just the encrypted messages (plus an 'oracle' who would encrypt requested messages).

The actual 'obsfucation' factor was secondary.

To make it short, SCOS is dead and I liked to propose something
new for the community, so that we have more traffic here.

scos2 31 41

x=i# rB b(N5m cFt# g)f3 :Q(VF2

$ echo "long live SCOS3 with German Umlauts support! :-)" | ./scos3 e 31 41 $Pz' e$Zt ^\v>+ Kh'R Ö>t[N7 [r#Q(Qä ,j&Pz\lC 5?c

Regards
Stefan

scos2 59 26

8q !<Ss(Fhw#F Z!> [cm)DJ\ Vx^Ekr)Ng 4.N4%Ar2AbF #,i$H Xz-Fe7.T M1-Qji
<k0 BPm[<Y7>I t+?i8\ Mu2/ P6&Nu&'Pu% ,d!= Wk7FS w:! h$#V4%Di1 tr0)CR">U,

SCOS2 47 11

3^?@ uqy) -||WWm26 /@LK Ilvv]>F CcW| q- ;@< WPmp "+>,SSjt
!9( <LNWjzx_ %BLLq0! [=>G HV uu$;/z .Tf0 ""'FHK Th 1%'
|\G PY1y n28]( ?r%="FK bct wv@ [AQYYh9 -_# FSSiq4"+ GNemiv
4##\ ~ Zv4* {/HTPZB

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

On 01/02/2025 12:19, Stefan Claas wrote:

<snip>

IIRC when encoding with Umlauts etc. at the same position
the original Umlauts will be shown.

Yes. By design, SCOS and SCOS2 preserve not only whitespace but anything
else they have not been told how to process[1]. We have seen aob come a cropper by making whitespace significant in Usenet ciphertexts, and that
was precisely the problem I was guarding against, but it also makes
sense only to digest text it knows about and pass through unmodified everything it doesn't, thus making copy-and-paste ciphertext in an ASCII medium Just Work.

This should be not
the case IMHO.

It is of course your prerogative to disagree with my design, but it is likewise my prerogative to prefer a deliberately ASCII-only design for
use in an ASCII environment such as Usenet.

Well, maybe only a very few US hosting service are ASCII only in 2025,
but we should ignore them, as Eurasiens ... ;-) I added also the british
pound sign and Euro symbol. :-)

I like bananas. You prefer pears. Great! By all means eat pears. But
I'll stick to bananas, thanks.

I never liked bananas and you are right I stick with pears. :-)

[1] It would be simple enough to make it understand /everything/, but to
do so requires departing from a printable ciphertext the same size as
its printable plaintext, could make the algorithm significantly harder
to crack from ciphertext only (and thus work to defeat the whole point
of the exercise), and might even (as in your example, which I did look
at BTW) result in a non-ASCII source file.

We live for decades in UTF-8 times, as Eurasiens, mind you. :-)

Well, anyways, I hope you don't mind a SCOS3 version, while people
in the U.S. and UK can stick with your original v2 design. SCOS was
anyways cracked and floating around in Bitmessage chans, in various
Programming Languages. I thought a little improvement for us litte
Sauerkrauts (Marcel ,Thomas and me etc.) would not hurt. :-)

Best regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas <fgrsna.pynnf@vagrearg.eh> wrote:

Richard Heathfield wrote:

On 01/02/2025 12:19, Stefan Claas wrote:

<snip>

IIRC when encoding with Umlauts etc. at the same position the
original Umlauts will be shown.

Yes. By design, SCOS and SCOS2 preserve not only whitespace but
anything else they have not been told how to process[1]. We have
seen aob come a cropper by making whitespace significant in Usenet
ciphertexts, and that was precisely the problem I was guarding
against, but it also makes sense only to digest text it knows about
and pass through unmodified everything it doesn't, thus making
copy-and-paste ciphertext in an ASCII medium Just Work.

This should be not the case IMHO.

You may want to return to the original SCOS posting and reread the
purpose. SCOS's purpose, and your purpose, are divergent, so naturally
SCOS will make some choices that your purpose finds to be incorrect for
your purpose.

It is of course your prerogative to disagree with my design, but it is
likewise my prerogative to prefer a deliberately ASCII-only design for
use in an ASCII environment such as Usenet.

Well, maybe only a very few US hosting service are ASCII only in 2025,
but we should ignore them, as Eurasiens ... ;-) I added also the british pound sign and Euro symbol. :-)

Reality is that while Usenet /can/ carry UTF-8 encoded text, the vast
vast majority of non-binaries Usenet (i.e., the 'text' portion) is
plain ASCII. This is mostly "self imposed" as most posters self-limit
to just the ASCII character set.

Note, I'm not saying this is good or bad (and one can make a very
coherent argument that in 2025 more non-ascii characters should be
seeing use) -- rather I'm just pointing out the reality of the current
use of the medium.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Welcome back, after a long silence.

Richard Heathfield <rjh@cpax.org.uk> wrote:

On 08/12/2024 05:58, Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Peter Fairbrother wrote:

Seriation is not a cipher, it is a technique used to build ciphers. Like >>>> substitution and permutation, of which it is a form of the latter.

It can be useful eg with digram-based ciphers like Playfair, where it
makes cryptanalysis based on the known frequency of occurrence of
digrams in the plaintext language much harder or impossible.

Yes, thank you for the explanation! It could also be a nice replacement
for SCOS, here in sci.crypt, combined with an A-Z encoder/decoder and a
padding program, since SCOS was cracked and floating around on Bitmessage >>> and code for seriation I have not seen yet elsewhere.

SCOS was never meant to be in any way 'secure'. Hense the name: (S)ci
(C)rypt (O)pen (S)ecret. It was meant as a fun exercise at
cryptanalysis and working out a crypt/decrypt algorithm given examples
of encrypted messages.

I think that's almost, but not quite, 100% correct.

What I posted was what I took to be the meaning from your posts.
Naturally I may have 'diverged' slightly in my interpretation from your
true intent (my not having a Usenet crystal ball with which to read
minds remotely certianly helps explain some divergence).

If I recall correctly (and it's entirely possible that I don't), what
I was after in SCOS was something just a little bit harder to read
than ROT-13, because people here were having ROT-13 conversations
that they clearly believed some regulars (eg aob) couldn't read, but
I couldn't quite bring myself to believe that anyone could be
incapable of decrypting ROT-13.

I do believe there were some rot-13 posts, and quite possibly an
assumption that AOB could not crack them.

But that was AOB we were dealing with. His knowledge of actual
cryptography was very much suspect, so it is 'possible' he could not
crack them himself. Now, might he have found a rot-13 decryptor web
page to use, possibly.....

The point of SCOS was a little like the point of the scary devil
monastery. If you could post in asr, it proved you were good enough
to post in asr, and if you could post and decrypt SCOS messages it
proved... well, that you were good enough to take part in SCOS conversations.

Ah, so maybe I did miss a sublety in your intent -- beyond a "christmas
holiday fun exercise in decrypting a new system".

But yes, being easy (but not /quite/ trivial) to crack was indeed at
the heart of SCOS.

Do note that by "secure" I was referring to Claus' usual statements
about being able to communicate from "inside enemy lines in a hostile environment". I doubt very much you'd recommend SCOS or SCOS2 for such
usage. I certianly would not recommend use of either variant for a
"behind enemy lines" or "hostile environment" situation.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich wrote:

Reality is that while Usenet /can/ carry UTF-8 encoded text, the vast
vast majority of non-binaries Usenet (i.e., the 'text' portion) is
plain ASCII. This is mostly "self imposed" as most posters self-limit
to just the ASCII character set.

This may be true for US groups, but it is not true for German, Dutch,
French, Polish, Russian, Chinese Newsgroups etc.

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/02/2025 12:34, Stefan Claas wrote:

<snip>

IMHO € and £ should be included as well, because we both and
many others live in Europe. ;-)

Depends on your definition of "continent". Mine doesn't include
islands.

"FOG IN CHANNEL - CONTINENT CUT OFF"

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas <fgrsna.pynnf@vagrearg.eh> wrote:

Rich wrote:

Reality is that while Usenet /can/ carry UTF-8 encoded text, the vast
vast majority of non-binaries Usenet (i.e., the 'text' portion) is
plain ASCII. This is mostly "self imposed" as most posters self-limit
to just the ASCII character set.

This may be true for US groups, but it is not true for German, Dutch,
French, Polish, Russian, Chinese Newsgroups etc.

Fair enough. As I cannot read any of those languages, I do not peek
into those groups to see what is being posted, nor what characters are
being used.

So amend my statement to: "the vast majority of US (or English)
non-binaries Usenet".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/02/2025 13:05, Stefan Claas wrote:

Richard Heathfield wrote:

On 01/02/2025 12:19, Stefan Claas wrote:

<snip>

This should be not
the case IMHO.

It is of course your prerogative to disagree with my design, but it is
likewise my prerogative to prefer a deliberately ASCII-only design for
use in an ASCII environment such as Usenet.

Well, maybe only a very few US hosting service are ASCII only in 2025,
but we should ignore them, as Eurasiens ... ;-) I added also the british pound sign and Euro symbol. :-)

The NNTP RFC says: "Commands and replies are composed of
characters from the ASCII character set. When the transport
service provides an 8-bit byte (octet) transmission channel, each
7-bit character is transmitted right justified in an octet with
the high order bit cleared to zero."

...which makes UTF-8 characters contra regs.

<snip>

We live for decades in UTF-8 times, as Eurasiens, mind you. :-)

"We" meaning people to whom it applies. Clearly they include you.
I live in simpler and happier times.

Well, anyways, I hope you don't mind a SCOS3 version

Of course I don't mind. That's freedom for you...

, while people
in the U.S. and UK can stick with your original v2 design. SCOS was
anyways cracked and floating around in Bitmessage chans, in various Programming Languages. I thought a little improvement for us litte Sauerkrauts (Marcel ,Thomas and me etc.) would not hurt. :-)

It's not actually an improvement. ;-)

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

On 01/02/2025 16:10, Stefan Claas wrote:

Rich wrote:

Reality is that while Usenet /can/ carry UTF-8 encoded text, the vast vast majority of non-binaries Usenet (i.e., the 'text' portion) is
plain ASCII. This is mostly "self imposed" as most posters self-limit
to just the ASCII character set.

This may be true for US groups, but it is not true for German, Dutch, French, Polish, Russian, Chinese Newsgroups etc.

Use SCOS a lot in those groups, do you?

People used in the past, in German Newsgroups, SCOS, but with limitations
due to the lack of Umlauts support.

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/02/2025 16:10, Stefan Claas wrote:

Rich wrote:

Reality is that while Usenet /can/ carry UTF-8 encoded text, the vast
vast majority of non-binaries Usenet (i.e., the 'text' portion) is
plain ASCII. This is mostly "self imposed" as most posters self-limit
to just the ASCII character set.

This may be true for US groups, but it is not true for German, Dutch,
French, Polish, Russian, Chinese Newsgroups etc.

Use SCOS a lot in those groups, do you?

Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/02/2025 16:04, Rich wrote:

Welcome back, after a long silence.

Bloody Thunderbird. I start using a new computer for the first
time since Trafalgar and BING! --- Usenet is working again!

What I posted was what I took to be the meaning from your posts.

And you may well be righter than me, it all being several
centuries ago now.

Naturally I may have 'diverged' slightly in my interpretation from your
true intent (my not having a Usenet crystal ball with which to read
minds remotely certianly helps explain some divergence).

Yeah, that's your problem right there - failing not only to read
minds but /future/ minds.

If I recall correctly (and it's entirely possible that I don't), what
I was after in SCOS was something just a little bit harder to read
than ROT-13, because people here were having ROT-13 conversations
that they clearly believed some regulars (eg aob) couldn't read, but
I couldn't quite bring myself to believe that anyone could be
incapable of decrypting ROT-13.

I do believe there were some rot-13 posts, and quite possibly an
assumption that AOB could not crack them.

I do actually stand by those two claims.

But that was AOB we were dealing with.

Well, quite so.

His knowledge of actual
cryptography was very much suspect, so it is 'possible' he could not
crack them himself. Now, might he have found a rot-13 decryptor web
page to use, possibly.....

Indeed, or he might not have been quite so dense as he made out?

The point of SCOS was a little like the point of the scary devil
monastery. If you could post in asr, it proved you were good enough
to post in asr, and if you could post and decrypt SCOS messages it
proved... well, that you were good enough to take part in SCOS
conversations.

Ah, so maybe I did miss a sublety in your intent -- beyond a "christmas holiday fun exercise in decrypting a new system".

Isn't that just another way of saying the same thing? Well, okay,
not exactly... but the kind of people it was meant for were the
kind of people who'd have a crack at it.

But yes, being easy (but not /quite/ trivial) to crack was indeed at
the heart of SCOS.

Do note that by "secure" I was referring to Claus' usual statements
about being able to communicate from "inside enemy lines in a hostile environment". I doubt very much you'd recommend SCOS or SCOS2 for such usage. I certianly would not recommend use of either variant for a
"behind enemy lines" or "hostile environment" situation.

You doubt correctly, of course, but frankly communicating from
inside enemy lines isn't all that hard if you put your mind to
it. Step 1: don't attract suspicion. Step 2: keep your messages
short. Step 3: use something strong eg AES. Step 4: hide it in a
bitmap or a MIDI or a WAV or whatever. Step 5: apply for a
transfer back to Head Office because frankly life's too short to
waste it pissing about with spying and stuff. But if you must,
Steps 1-4 should see you through.


--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

On 01/02/2025 16:04, Rich wrote:

Do note that by "secure" I was referring to Claus' usual statements
about being able to communicate from "inside enemy lines in a hostile environment". I doubt very much you'd recommend SCOS or SCOS2 for such usage. I certianly would not recommend use of either variant for a
"behind enemy lines" or "hostile environment" situation.

You doubt correctly, of course, but frankly communicating from inside
enemy lines isn't all that hard if you put your mind to it. Step 1:
don't attract suspicion. Step 2: keep your messages short. Step 3: use something strong eg AES. Step 4: hide it in a bitmap or a MIDI or a WAV
or whatever. Step 5: apply for a transfer back to Head Office because
frankly life's too short to waste it pissing about with spying and
stuff. But if you must, Steps 1-4 should see you through.

"inside enenemy lines" could also mean nowadays, when you communicate from
home (on social media etc.) while your Govenemnt becomes more and more left wing facist and your are only a *your* country loving patriot!

So, a second offline device is in order for proper encryption, to protect against undetectible Government trojans on your online PC and no smartphones, because they can listen to the keystrokes of your PC's keyboard, in a room. (remember Snowden, when his visitors had to put their phones in his fridge)

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield <rjh@cpax.org.uk> wrote:

On 01/02/2025 16:04, Rich wrote:

Welcome back, after a long silence.

Bloody Thunderbird. I start using a new computer for the first time
since Trafalgar and BING! --- Usenet is working again!

One of the reasons I use Tin and read/post from an xterm. :)

What I posted was what I took to be the meaning from your posts.

And you may well be righter than me, it all being several centuries
ago now.

Yeah, what was it, circa Dec 2019 timeframe. So "around" five years
now.

Naturally I may have 'diverged' slightly in my interpretation from
your true intent (my not having a Usenet crystal ball with which to
read minds remotely certianly helps explain some divergence).

Yeah, that's your problem right there - failing not only to read
minds but /future/ minds.

If I only had that "future mindreading crystal ball". I'd own my own
Caribbean island by now.

If I recall correctly (and it's entirely possible that I don't),
what I was after in SCOS was something just a little bit harder to
read than ROT-13, because people here were having ROT-13
conversations that they clearly believed some regulars (eg aob)
couldn't read, but I couldn't quite bring myself to believe that
anyone could be incapable of decrypting ROT-13.

I do believe there were some rot-13 posts, and quite possibly an
assumption that AOB could not crack them.

I do actually stand by those two claims.

Was not refuting your memory. I believe your claims re posts and the
general consensus on AOB are correct (or at least within the same
ballpark as my own recollections).

But that was AOB we were dealing with.

Well, quite so.

Of note, his website is no longer on the internet. I suspect (but have
no evidence) that "time" has come for him by now.

His knowledge of actual cryptography was very much suspect, so it is
'possible' he could not crack them himself. Now, might he have
found a rot-13 decryptor web page to use, possibly.....

Indeed, or he might not have been quite so dense as he made out?

Also possible. Although I'd give that maybe a 10% chance. Otherwise
he was expert master class at both trolling and appearing to be a
cryptographic and programming imbecile. Another very unlikely, but not
zero likelyhood, opinion.

The point of SCOS was a little like the point of the scary devil
monastery. If you could post in asr, it proved you were good
enough to post in asr, and if you could post and decrypt SCOS
messages it proved... well, that you were good enough to take part
in SCOS conversations.

Ah, so maybe I did miss a sublety in your intent -- beyond a
"christmas holiday fun exercise in decrypting a new system".

Isn't that just another way of saying the same thing? Well, okay,
not exactly... but the kind of people it was meant for were the kind
of people who'd have a crack at it.

Yes, and it did get quick uptake in the group at the time. I had no
time at the time to devote to it, but months later when I did have
time, digging out the algorithm was a fun exercise.

But yes, being easy (but not /quite/ trivial) to crack was indeed
at the heart of SCOS.

It took me some WTF's before I finally sussed out the critical bit of
SCOS1 that made everything finally make sense. You obviously know of
what "finer point of the algorithm" of which I speak. :) And of course
once SCOS was understood, understanding SCOS2 was less of an effort.

Do note that by "secure" I was referring to Claus' usual statements
about being able to communicate from "inside enemy lines in a
hostile environment". I doubt very much you'd recommend SCOS or
SCOS2 for such usage. I certianly would not recommend use of either
variant for a "behind enemy lines" or "hostile environment"
situation.

You doubt correctly, of course, but frankly communicating from inside
enemy lines isn't all that hard if you put your mind to it. Step 1:
don't attract suspicion. Step 2: keep your messages short. Step 3:
use something strong eg AES. Step 4: hide it in a bitmap or a MIDI
or a WAV or whatever. Step 5: apply for a transfer back to Head
Office because frankly life's too short to waste it pissing about
with spying and stuff. But if you must, Steps 1-4 should see you
through.

Agreed, not having to do so is the much preferred state of being.
Sadly, not everyone gets that luxury at all times.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 1 Feb 2025 11:00:19 +0000, Richard Heathfield wrote:

But yes, being easy (but not /quite/ trivial) to crack was indeed at the heart of SCOS.

Welcome back. I very much enjoyed the challenges that you and a few others provided in the past. I've spent a bit of time working through the
National Cipher Challenges and I'm now following the Alan Turing
Cryptography Competition and Mathsbombe. I'm definitely not an cipher
expert, but it is fun and I can see it's a skill that takes time and
effort to develop.

I'm quite old and have a lot of interests, so sometimes I don't follow everything as closely as I would like. That was the case with SCOS.

I did have a bit of trouble with SCOS, not because it was hard to decrypt,
but my implementation wasn't... There's a word, but I'm not sure what it
is... When you perform an operation on a set, the result of that operation
is should be guaranteed to belong to the same original set, but in my case
it wasn't. So in this case, when encrypting and decrypting occasionally,
due to some odd punctuation mark, or an accented character, the result
would lie outside the reasonable bounds of characters. The web, which I
often use as a source of plain text, is full of such characters. That was
my problem, not a problem with SCOS, but it did cause me some grief.

Best wishes, good to have you back.

--
David Entwistle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/02/2025 10:43, David Entwistle wrote:

On Tue, 4 Feb 2025 06:10:59 +0000, Richard Heathfield wrote:

It now occurs to me that I could remove other characters to have them
left treated untreated. For example, the following ciphertext is the
(key 31 41) output from a SCOS2 variant (with just one line of code
changed) that passes through everything but alphabetical characters:

Indeed. SCOS(31, 41):

DyB, G gJztf dGow oVQwd QI tv fYQHtpNKrpk, GN ss kRMsZ LLAsp cPqsi YI qYiG KnZSQ quèeL xCûléT EGl bMU yy.

C bRvnc Tzoc hR vv oZMt AhZH Fp RJ wxlSKukid h'Jh lOKCojKAtv OIuheNB zA ZSKvdaHFAWeIDr.

uMPF xYXBnq,

xyn qVI.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Let them eat cake." - Jean-Jacques Rousseau, 1766.
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 4 Feb 2025 06:10:59 +0000, Richard Heathfield wrote:

It now occurs to me that I could remove other characters to have them
left treated untreated. For example, the following ciphertext is the
(key 31 41) output from a SCOS2 variant (with just one line of code
changed) that passes through everything but alphabetical characters:

Indeed. SCOS(31, 41):

DyB, G gJztf dGow oVQwd QI tv fYQHtpNKrpk, GN ss kRMsZ LLAsp cPqsi YI qYiG KnZSQ quèeL xCûléT EGl bMU yy.

C bRvnc Tzoc hR vv oZMt AhZH Fp RJ wxlSKukid h'Jh lOKCojKAtv OIuheNB zA ZSKvdaHFAWeIDr.

uMPF xYXBnq,
--
David Entwistle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 8 Feb 2025 10:58:26 +0000, Richard Heathfield wrote:

xyn qVI.

What did the cheese slice say to the onion slice?

SCOS(C, O):

"cs'NI ah c BGLT".

--
David Entwistle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/02/2025 20:18, David Entwistle wrote:

On Sat, 8 Feb 2025 10:58:26 +0000, Richard Heathfield wrote:

xyn qVI.

What did the cheese slice say to the onion slice?

SCOS(C, O):

"cs'NI ah c BGLT".

How did you get from "C O" to "6 8"?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 9 Feb 2025 13:00:46 +0000, Richard Harnden wrote:

How did you get from "C O" to "6 8"?

Ah, that's elementary...

How did you get to 6 and 8 without guessing that? Brute force?

--
David Entwistle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/02/2025 17:08, David Entwistle wrote:

On Sun, 9 Feb 2025 13:00:46 +0000, Richard Harnden wrote:

How did you get from "C O" to "6 8"?

Ah, that's elementary...

How did you get to 6 and 8 without guessing that? Brute force?

Brute force, yes - there are only possible 52^2 keys.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 9 Feb 2025 19:40:25 +0000, Richard Harnden wrote:

Brute force, yes - there are only possible 52^2 keys.

Well done.

I noticed in the National Cipher Challenge that some people can show
remarkable tenacity once they engage in a challenge.
--
David Entwistle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2 Feb 2025 10:06:03 -0000 (UTC), David Entwistle wrote:

I did have a bit of trouble with SCOS, not because it was hard to
decrypt,
but my implementation wasn't... There's a word, but I'm not sure what it is... When you perform an operation on a set, the result of that
operation is should be guaranteed to belong to the same original set,
but in my case it wasn't. So in this case, when encrypting and
decrypting occasionally, due to some odd punctuation mark, or an
accented character, the result would lie outside the reasonable bounds
of characters. The web, which I often use as a source of plain text, is
full of such characters. That was my problem, not a problem with SCOS,
but it did cause me some grief.

"Closure: In mathematics, a subset of a given set is closed under an
operation of the larger set if performing that operation on members of the subset always produces a member of that subset".

So, should an encryption / decryption operation always be closed? Maybe
SCOS was closed, but I think it would depend how you defined the full
character set and that may have to be quite wide.

--
David Entwistle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03/02/2025 09:00, David Entwistle wrote:

On Sun, 2 Feb 2025 10:06:03 -0000 (UTC), David Entwistle wrote:

I did have a bit of trouble with SCOS, not because it was hard to
decrypt,
but my implementation wasn't... There's a word, but I'm not sure what it
is... When you perform an operation on a set, the result of that
operation is should be guaranteed to belong to the same original set,
but in my case it wasn't. So in this case, when encrypting and
decrypting occasionally, due to some odd punctuation mark, or an
accented character, the result would lie outside the reasonable bounds
of characters. The web, which I often use as a source of plain text, is
full of such characters. That was my problem, not a problem with SCOS,
but it did cause me some grief.

"Closure: In mathematics, a subset of a given set is closed under an operation of the larger set if performing that operation on members of the subset always produces a member of that subset".

So, should an encryption / decryption operation always be closed? Maybe
SCOS was closed, but I think it would depend how you defined the full character set and that may have to be quite wide.

In a sense, SCOS's character set is defined by these four lines:

#define UPPER "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
#define LOWER "abcdefghijklmnopqrstuvwxyz"
#define DIGIT "0123456789"
#define PUNCT "!\"$%^&*()_-+={}[]#~'@;:/?.>,<\\|"

which isn't particularly wide, but any encryption of any of those
characters will *always* produce a character drawn from the same
set. When faced with something *not* from that set, SCOS leaves
it unchanged. So I think I'm right in saying that by the above
definition SCOS /is/ closed.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 3 Feb 2025 10:17:24 +0000, Richard Heathfield wrote:

#define UPPER "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
#define LOWER "abcdefghijklmnopqrstuvwxyz"
#define DIGIT "0123456789"
#define PUNCT "!\"$%^&*()_-+={}[]#~'@;:/?.>,<\\|"

which isn't particularly wide, but any encryption of any of those
characters will *always* produce a character drawn from the same set.
When faced with something *not* from that set, SCOS leaves it unchanged.
So I think I'm right in saying that by the above definition SCOS /is/
closed.

Yes, as I recall, and as a rather sloppy adversary unaware of your implementation, my character set ran from char(33) ! to char(126) ~. I
think it was the gap between char(95) _ and char(97) a which caused me the
most trouble. char(96) is top left on a QWERTY keyboard. I never use it,
but it gets used as an apostrophe in some text on the web. As a result
some of my checks failed to do what I expected and I didn't feel confident posting SCOS-based ciphers.

Happy days though.
--
David Entwistle

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04/02/2025 01:31, David Entwistle wrote:

On Mon, 3 Feb 2025 10:17:24 +0000, Richard Heathfield wrote:

#define UPPER "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
#define LOWER "abcdefghijklmnopqrstuvwxyz"
#define DIGIT "0123456789"
#define PUNCT "!\"$%^&*()_-+={}[]#~'@;:/?.>,<\\|"

which isn't particularly wide, but any encryption of any of those
characters will *always* produce a character drawn from the same set.
When faced with something *not* from that set, SCOS leaves it unchanged.
So I think I'm right in saying that by the above definition SCOS /is/
closed.

Yes, as I recall, and as a rather sloppy adversary unaware of your implementation, my character set ran from char(33) ! to char(126) ~. I
think it was the gap between char(95) _ and char(97) a which caused me the most trouble. char(96) is top left on a QWERTY keyboard. I never use it,
but it gets used as an apostrophe in some text on the web. As a result
some of my checks failed to do what I expected and I didn't feel confident posting SCOS-based ciphers.

Well, blow moi down with a feather! I had no idea! The backtick
does indeed fall by the wayside... and I *do* use it a lot --- as
`` for "open speech marks" and \` (grave accent) in LaTeX --- so
I really ought to have remembered it, but it turns out I did
overlook it.

And *that* means that if I use my completely insecure program to
encode a LaTeX document for posting on the Net with the express
intent of allowing a few people I've never met to crack the
ciphertext, as well as having an easy task they'll have the
additional benefit of having the backticks pre-cracked for them.

In the real world it would of course be an embarrassing screw-up
that hopefully would be caught by a proper test plan. In the
rarified atmosphere of sci.crypt, however, I can afford to be
sanguine.

It now occurs to me that I could remove other characters to have
them left treated untreated. For example, the following
ciphertext is the (key 31 41) output from a SCOS2 variant (with
just one line of code changed) that passes through everything but
alphabetical characters:

Byuj, ONFC hYH rroU SttW E ymXfIuw! C Qyq pf OyoZ! HKw iWNKImVS
AAfi NHmcRF wggV AM wZL SlyhMwm... XZE Y *ii* dQr kk G Gys --- OV
`` xvn "ZPtr lXBqdX RuAif" CEj \` (bbzJh SJypni) MG TXFFn --- xi
r PrccRT ytUKL Ak SAKi kMJqnRJLnb VV, sAo SS HxjUO zui m wqa
aWuwfXMx kk.

gIn *sVDL* taLNH xaIQ ug y ZMn kl EFskVDHhdf EysTGNzb bSEllJK Gq
VTxycS D dhPPx ssVcJqoj KIA nbUKoiQ NB wZL jpt lMMp qTF uCjaCFu
ZTOomh Rx hhWOLmgO x rfm UyxnYG Z'BZ XDJhj TAE td GKiZW Uxj
WRNugiZzHs, OV OlhW AH lTdFzh QS yjql Vryf dGsB'dS DlvT XAm
XPEyycXLnn SKIoeWW Gm dLVxrZ bEq cQHECgPMJ vmO-BFdURAo fdV MpbY.

jD ybN Prcc cJBkR LL DkfLs sY KLGsiJ vn Ya GDhVbQovkPJr sRVxE-rb
Uxfn QMCgWaGvx kRMsZ ME renOEF co F JAmcGI zZcS DoSU. ey tWI
KioUGyjX JRzqjVCoqS Rx zYT.CGCib, EAxUayA, G PCE gaPNFg lV xp
sPRzCfZF.

Yy hXU BeTaMC sc Pw AdLT X ghcIp sURIEc bVykm MGouSJPprh XH pXhF
JmYV Jrhk ZMoZhHv BjeRtemMA. Rph JRjkcNv, zcO ECodVStnV
GBxeQSJjrc GF vYK (Fox 31 41) cXLwqe FGsf I pOPI2 auAgNPK (CddG
xxka Kye aMGm lR DEiY LFnpXKy) DgOW HhodEH xaZLGhX JPnplVyoiQ AIw
SSLsaQIMqZMM smUaypvVXN:

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield <rjh@cpax.org.uk> writes:

On 01/02/2025 13:05, Stefan Claas wrote:

Richard Heathfield wrote:

On 01/02/2025 12:19, Stefan Claas wrote:

<snip>

This should be not
the case IMHO.

It is of course your prerogative to disagree with my design, but it is
likewise my prerogative to prefer a deliberately ASCII-only design for
use in an ASCII environment such as Usenet.

Well, maybe only a very few US hosting service are ASCII only in 2025,
but we should ignore them, as Eurasiens ... ;-) I added also the british
pound sign and Euro symbol. :-)

The NNTP RFC says: "Commands and replies are composed of characters from

s/The/An obsolete/

the ASCII character set. When the transport service provides an 8-bit byte (octet) transmission channel, each 7-bit character is transmitted right justified in an octet with the high order bit cleared to zero."

Another says "The character set for all NNTP commands is UTF-8" and that
one is the one that most current servers adhere to. It OK to pick and
choose ones sources, but you should not suggest that your opinion is the
only one supported by the RFCs, and you should certainly not suggest
that what you quote is authoritative.

...which makes UTF-8 characters contra regs.

It means that UTF-8 characters contravene an obsolete regulation.

We live for decades in UTF-8 times, as Eurasiens, mind you. :-)

"We" meaning people to whom it applies. Clearly they include you. I live in simpler and happier times.

It is certainly simpler to have a more restricted character set, but I
was brought up by parents and teachers who would consider being forced
to write the modern forms of, for example, "facade", "nee" and "Zoe" an abomination. I still prefer to write them the traditional way (though I
have not done so here so you can see what I am talking about).

Quite apart from what spellings one prefers, there are all sorts of
English subjects like writing about phonetics or indicating stress in
poetry where, for me, the simpler times were not happier ones.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/02/2025 12:01, Ben Bacarisse wrote:

It OK to pick and
choose ones sources, but you should not suggest that your opinion is the
only one supported by the RFCs, and you should certainly not suggest
that what you quote is authoritative.

You are of course 100% correct as usual, but I'm old enough now
to have earned a little grump from time to time.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield <rjh@cpax.org.uk> writes:

On 04/02/2025 01:31, David Entwistle wrote:

...

Yes, as I recall, and as a rather sloppy adversary unaware of your
implementation, my character set ran from char(33) ! to char(126) ~. I
think it was the gap between char(95) _ and char(97) a which caused me the >> most trouble. char(96) is top left on a QWERTY keyboard. I never use it,
but it gets used as an apostrophe in some text on the web. As a result
some of my checks failed to do what I expected and I didn't feel confident >> posting SCOS-based ciphers.

Well, blow moi down with a feather! I had no idea!

I think you have just forgotten. It was brought up at the time (I have
a post of 7th Dec 2021 about it).

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/02/2025 23:44, Ben Bacarisse wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:

On 04/02/2025 01:31, David Entwistle wrote:

...

Yes, as I recall, and as a rather sloppy adversary unaware of your
implementation, my character set ran from char(33) ! to char(126) ~. I
think it was the gap between char(95) _ and char(97) a which caused me the >>> most trouble. char(96) is top left on a QWERTY keyboard. I never use it, >>> but it gets used as an apostrophe in some text on the web. As a result
some of my checks failed to do what I expected and I didn't feel confident >>> posting SCOS-based ciphers.

Well, blow moi down with a feather! I had no idea!

I think you have just forgotten. It was brought up at the time (I have
a post of 7th Dec 2021 about it).

Then I have indeed just forgotten. Unfortunately, my Deja News
doesn't cover the period in question, so I can't check, but I
have no reason to doubt you.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield <rjh@cpax.org.uk> writes:

On 10/02/2025 23:44, Ben Bacarisse wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:

On 04/02/2025 01:31, David Entwistle wrote:

...

Yes, as I recall, and as a rather sloppy adversary unaware of your
implementation, my character set ran from char(33) ! to char(126) ~. I >>>> think it was the gap between char(95) _ and char(97) a which caused me the >>>> most trouble. char(96) is top left on a QWERTY keyboard. I never use it, >>>> but it gets used as an apostrophe in some text on the web. As a result >>>> some of my checks failed to do what I expected and I didn't feel confident >>>> posting SCOS-based ciphers.

Well, blow moi down with a feather! I had no idea!

I think you have just forgotten. It was brought up at the time (I have
a post of 7th Dec 2021 about it).

Then I have indeed just forgotten. Unfortunately, my Deja News doesn't
cover the period in question, so I can't check, but I have no reason to
doubt you.

Well, easy to forget as it's hardly matters. But this does raise a
question I don't recall being asked... Do you remember why you
hand-coded a character set rather than just taking it to be ASCII 33 to
126 (inclusive)? That would have made the code a bit simpler. All that
occurs to me is that you might have done so to make it more fun reverse engineer. But then I can imagine you might have mixed up the order of
some the more obvious runs (like A to Z to 0 to 9) to make it even more
so.

Good to see you back, by the way...

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/02/2025 23:41, Ben Bacarisse wrote:

<snip>

But this does raise a
question I don't recall being asked... Do you remember why you
hand-coded a character set

Yes. :-)

rather than just taking it to be ASCII 33 to
126 (inclusive)?

Cast your mind back, if you will, to the dark days of the second
millennium, when small furry creatures from Alph... [Ach, sod
poetry, it's almost 4am.]

Not hard-coding ASCII values into the source was mere habit; I
only ever hard-coded when I couldn't avoid it (eg when converting
between character sets), because it was a source of
non-portability that 99.99(+)% of the time I simply didn't need.

That would have made the code a bit simpler. All that
occurs to me is that you might have done so to make it more fun reverse engineer. But then I can imagine you might have mixed up the order of
some the more obvious runs (like A to Z to 0 to 9) to make it even more
so.

It would have been (and remains) very easy to do, in fact - just
fiddle with the #defines at the top. But one must know when to
stop, or one risks turn a mild teaser into the head-scratching
challenge it was never my intent to make it.

Good to see you back, by the way...

Thank you. Thunderbird just stopped playing sillybuggers... again...

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)