VKHXMDLWWMGWSAESWPHYWLMTKEGNXAGWWFHSSAGKWBGXWFGO
SAFWWJGLXEGPXCCQXBHVWFHSSAMTLMGSWFHSSAGUWFGOSAGX
XCGPMDJPWFGOSAFTXJGMXEGVXCCQUEGVWJGTWICOSAFUWIGV
SAHRXFGZWDGLSAGSXCGPXHGOSAGWWPHYSAGKXFGNXAHTSAGP
XGGVXCCQXEGYWFCQWMGRXKHZSAGUWPGXSO

Stefan Claas wrote:

[...]

Da hätte ich ein X- oder x- setzen müssen.

--
Grüße
Stefan

Stefan Claas in de.test:

>Stefan Claas wrote:

>Da hätte ich ein X- oder x- setzen müssen.

Wo jetzt genau?

Beim Dekodieren kommt hier BTW etwas Binäres heraus.
Ist das korrekt so?

Marcel
--
╭──╮ ╭──╮ ╭────────╮ ╭─╮ ╭───╮ ..49..╭───╮ ╭─────╮
╭─╯ ╰──╯ │ │ ╭─────╯ ╭─╯ │ ╰─╮ │ ..49..│ ╰──╮ ╰──╮ ╰─
╰──╮ ...7..╰─╯ ╰──────╮ │ │ ╭─╯ ╰───╮ ╭──╮ ╰──╮ │ ╭───╯
────╯ ╰────╯ ╰──╯ ╰─╯ ╰───────╯ ╰─╯ ..67..

Marcel Logen wrote:

> Stefan Claas in de.test:
>
> >Stefan Claas wrote:
>
> >Da hätte ich ein X- oder x- setzen müssen.
>
> Wo jetzt genau?

Bei Content-Transfer-Encoding: x-az (gemäß RFC)
> Beim Dekodieren kommt hier BTW etwas Binäres heraus.
> Ist das korrekt so?

Nein. Ist auch kein base26 sondern, wie von Herbert
in sci.crypt vorgeschlagen, A-Z Kodierung.

--
Grüße
Stefan

Stefan Claas in de.test:

>Marcel Logen wrote:
>> Stefan Claas in de.test:

>> >Da hätte ich ein X- oder x- setzen müssen.
>>
>> Wo jetzt genau?
>
>Bei Content-Transfer-Encoding: x-az (gemäß RFC)

Ach so, ja. Ist ja nicht "registriert".

(Ich hatte bei den Namen der Headerfelder geschaut.)

>> Beim Dekodieren kommt hier BTW etwas Binäres heraus.
>> Ist das korrekt so?
>
>Nein. Ist auch kein base26 sondern, wie von Herbert
>in sci.crypt vorgeschlagen, A-Z Kodierung.

OK, danke. Das muß ich mir ansehen.

Marcel
--
╭─────╮ ╭──────────╮ ╭──╮ ╭───────╮ ..55..╭───╮ ╭─
╰─╮ ╰───╮ ╰─╮ ╭───╯ ╭─╯ ╰─────╯ ╭────╯ ..53..╭─╯ │ ╭─╯
─╮ │ ╭──╯ ╭────╯ │ ╭─╮ │ ..39..╰──╮ ╭─╮ ╭───╯ │ ╭─╯
╰─╯ ╰────╯ ╰──╯ ╰─╯ ╰──╯ ╰─╯ ..59..╰─╯

Marcel Logen in de.test:

>Stefan Claas in de.test:
>>Marcel Logen wrote:

>>> Beim Dekodieren kommt hier BTW etwas Binäres heraus.
>>> Ist das korrekt so?
>>
>>Nein. Ist auch kein base26 sondern, wie von Herbert
>>in sci.crypt vorgeschlagen, A-Z Kodierung.
>
>OK, danke. Das muß ich mir ansehen.

Kaum macht man's richtig, funktioniert es auch. :-)

| $ cat az-klee-decode12.py
| #!/usr/bin/python3
| a1='''
|
| VKHXMDLWWMGWSAESWPHYWLMTKEGNXAGWWFHSSAGKWBGXWFGO
| SAFWWJGLXEGPXCCQXBHVWFHSSAMTLMGSWFHSSAGUWFGOSAGX
| XCGPMDJPWFGOSAFTXJGMXEGVXCCQUEGVWJGTWICOSAFUWIGV
| SAHRXFGZWDGLSAGSXCGPXHGOSAGWWPHYSAGKXFGNXAHTSAGP
| XGGVXCCQXEGYWFCQWMGRXKHZSAGUWPGXSO
|
|
|
| '''
| b2=str.maketrans('','','\n\r\t ')
| c3=a1.translate(b2)
| d4=str.maketrans('ABCDEFGHIJKLMNOPQRSTUVWXYZ','0123456789abcdef0123456789')
| e5=c3.translate(d4)
| print(e5)

Marcel
--
╭───────╮ ╭─╮ ..59..╭────╮
╭──╮ ..32..╰─────╮ ╰─────╮ │ │ ╭─────╯ ╭─╯
╯ ╰─╮ ╭────╮ ╭──╮ ╭─╮ ╭─╮ ╰─╮ ╭──╯ │ │ │..60..╭─╯
╰──────╯ ╰─╯ ╰─────────╯ ╰───╯ ╰────╯ ╰────╯ ╰──╯..60..╰──────

Marcel Logen wrote:

> Marcel Logen in de.test:
>
> >Stefan Claas in de.test:
> >>Marcel Logen wrote:
>
> >>> Beim Dekodieren kommt hier BTW etwas Binäres heraus.
> >>> Ist das korrekt so?
> >>
> >>Nein. Ist auch kein base26 sondern, wie von Herbert
> >>in sci.crypt vorgeschlagen, A-Z Kodierung.
> >
> >OK, danke. Das muß ich mir ansehen.
>
> Kaum macht man's richtig, funktioniert es auch. :-)
>
> | $ cat az-klee-decode12.py
> | #!/usr/bin/python3
> | a1='''
> |
> | VKHXMDLWWMGWSAESWPHYWLMTKEGNXAGWWFHSSAGKWBGXWFGO
> | SAFWWJGLXEGPXCCQXBHVWFHSSAMTLMGSWFHSSAGUWFGOSAGX
> | XCGPMDJPWFGOSAFTXJGMXEGVXCCQUEGVWJGTWICOSAFUWIGV
> | SAHRXFGZWDGLSAGSXCGPXHGOSAGWWPHYSAGKXFGNXAHTSAGP
> | XGGVXCCQXEGYWFCQWMGRXKHZSAGUWPGXSO
> |
> |
> |
> | '''
> | b2=str.maketrans('','','\n\r\t ')
> | c3=a1.translate(b2)
> | d4=str.maketrans('ABCDEFGHIJKLMNOPQRSTUVWXYZ','0123456789abcdef0123456789')
> | e5=c3.translate(d4)
> | print(e5)

Das ging ja fix! :-) Kannst du damit auch binäre Daten verarbeiten?

Hier mal ein weiterer Test:

$ openssl rand 32 > bin
$ shasum -a 256 bin
cdbb0384d76a39a2001ac903b13056cf21b5c2f301fb8353aaffdc7e73454652 bin
$ az -l 48 < bin
LBLWKMPRTIHKPOJRKMDUNCETUGKWMKLNTGGYUIMMXMPLWAIQ
QEGWYINMWKITPLGM

Neben base26 für Handy finde ich az für Telefax sehr gut, da ich damit
genau 2000 Zeichen, also 1000 byte, auf eine DIN A4 Seite bekomme, wenn
ich in LibreOffice 16 pt Liberation mono Zeichensatz nutze, wobei dann
bei dem az Encoder die Zeilenlänge auf 50 Zeichen gestellt ist.

Ich muss nur mal sehen welche OCR Software unter Linux dafür geeignet
ist, da ich das unter Windows mache. Vielleicht geht das unter Linux
noch besser, wenn man eine kleinere Punktgröße wählt? QR-Codes auf eine
Seite, wie Herbet das macht, ist zwar besser was die Anzahl an bytes
betrifft, jedoch für Menschen nicht lesbar.

--
Grüße
Stefan

Stefan Claas wrote:

> Marcel Logen wrote:
>
> > Marcel Logen in de.test:
> >
> > >Stefan Claas in de.test:
> > >>Marcel Logen wrote:
> >
> > >>> Beim Dekodieren kommt hier BTW etwas Binäres heraus.
> > >>> Ist das korrekt so?
> > >>
> > >>Nein. Ist auch kein base26 sondern, wie von Herbert
> > >>in sci.crypt vorgeschlagen, A-Z Kodierung.
> > >
> > >OK, danke. Das muß ich mir ansehen.
> >
> > Kaum macht man's richtig, funktioniert es auch. :-)
> >
> > | $ cat az-klee-decode12.py
> > | #!/usr/bin/python3
> > | a1='''
> > |
> > | VKHXMDLWWMGWSAESWPHYWLMTKEGNXAGWWFHSSAGKWBGXWFGO
> > | SAFWWJGLXEGPXCCQXBHVWFHSSAMTLMGSWFHSSAGUWFGOSAGX
> > | XCGPMDJPWFGOSAFTXJGMXEGVXCCQUEGVWJGTWICOSAFUWIGV
> > | SAHRXFGZWDGLSAGSXCGPXHGOSAGWWPHYSAGKXFGNXAHTSAGP
> > | XGGVXCCQXEGYWFCQWMGRXKHZSAGUWPGXSO
> > |
> > |
> > |
> > | '''
> > | b2=str.maketrans('','','\n\r\t ')
> > | c3=a1.translate(b2)
> > | d4=str.maketrans('ABCDEFGHIJKLMNOPQRSTUVWXYZ','0123456789abcdef0123456789')
> > | e5=c3.translate(d4)
> > | print(e5)
>
> Das ging ja fix! :-) Kannst du damit auch binäre Daten verarbeiten?
>
> Hier mal ein weiterer Test:
>
> $ openssl rand 32 > bin
> $ shasum -a 256 bin
> cdbb0384d76a39a2001ac903b13056cf21b5c2f301fb8353aaffdc7e73454652 bin
> $ az -l 48 < bin
> LBLWKMPRTIHKPOJRKMDUNCETUGKWMKLNTGGYUIMMXMPLWAIQ
> QEGWYINMWKITPLGM

Ja geht auch. :-) Musste nur newline am Ende löschen.

--
Grüße
Stefan

Stefan Claas in de.test:

>Stefan Claas wrote:
>> Marcel Logen wrote:

[...]
>> > | b2=str.maketrans('','','\n\r\t ')
>> > | c3=a1.translate(b2)
>> > | d4=str.maketrans('ABCDEFGHIJKLMNOPQRSTUVWXYZ','0123456789abcdef0123456789')
>> > | e5=c3.translate(d4)
>> > | print(e5)
>>
>> Das ging ja fix! :-)

Ist ja auch nur ein Dekoder.

Weil es beim Kodieren mehrere Möglichkeiten gibt,
ist mir noch nicht klar, wie das genau laufen soll.

>> Kannst du damit auch binäre Daten verarbeiten?

Ja, da das "print(e5)" nur Hex-Daten ausgibt.
Ggf. muß ich dann noch ein "xxr -p -r" dahinterschalten.

>> Hier mal ein weiterer Test:
>>
>> $ openssl rand 32 > bin
>> $ shasum -a 256 bin
>> cdbb0384d76a39a2001ac903b13056cf21b5c2f301fb8353aaffdc7e73454652 bin
>> $ az -l 48 < bin
>> LBLWKMPRTIHKPOJRKMDUNCETUGKWMKLNTGGYUIMMXMPLWAIQ
>> QEGWYINMWKITPLGM
>
>Ja geht auch. :-) Musste nur newline am Ende löschen.

Klappt hier auch.

Ausgabe der binären Daten im Hex-Format:

| $ ./az-klee-decode12.py
| b1b6acf1387afe91ac34d24346a6cabd366848cc7cfb6080046688dc6a83fb6c

Berechnung der Prüfsumme:

| $ ./az-klee-decode12.py | xxd -p -r | sha256sum
| cdbb0384d76a39a2001ac903b13056cf21b5c2f301fb8353aaffdc7e73454652 -

Marcel
--
╮ ╭─╮ ╭─╮ ╭────╮ ╭────────╮ ..52..╭────────╮
│ │ ╰─╯ │ │ ╰─╮ ╰─────╮ ╰───╮ ..52..╰──╮ ╰───╮
│ ╭───╮ ╭─╮ ╭───╯ ╭──╯ ╰──╮ ╰─╮ ╭──╯ ╭───╯ ╭──╮ ╭───╯ ..65..╰─
╰─╯ ╰──╯ ╰─╯ ╰────────╯ ╰───╯ ╰─────╯ ╰─╯ ..67..

Stefan Claas in de.test:

>Stefan Claas wrote:
>> Marcel Logen wrote:

[...]
>> > | b2=str.maketrans('','','\n\r\t ')
>> > | c3=a1.translate(b2)
>> > | d4=str.maketrans('ABCDEFGHIJKLMNOPQRSTUVWXYZ','0123456789abcdef0123456789')
>> > | e5=c3.translate(d4)
>> > | print(e5)
>>
>> Das ging ja fix! :-)

Ist ja auch nur ein Dekoder.

Weil es beim Kodieren mehrere Möglichkeiten gibt,
ist mir noch nicht klar, wie das genau laufen soll.

>> Kannst du damit auch binäre Daten verarbeiten?

Ja, da das "print(e5)" nur Hex-Daten ausgibt.
Ggf. muß ich dann noch ein "xxd -p -r" dahinterschalten.

>> Hier mal ein weiterer Test:
>>
>> $ openssl rand 32 > bin
>> $ shasum -a 256 bin
>> cdbb0384d76a39a2001ac903b13056cf21b5c2f301fb8353aaffdc7e73454652 bin
>> $ az -l 48 < bin
>> LBLWKMPRTIHKPOJRKMDUNCETUGKWMKLNTGGYUIMMXMPLWAIQ
>> QEGWYINMWKITPLGM
>
>Ja geht auch. :-) Musste nur newline am Ende löschen.

Klappt hier auch.

Ausgabe der binären Daten im Hex-Format:

| $ ./az-klee-decode12.py
| b1b6acf1387afe91ac34d24346a6cabd366848cc7cfb6080046688dc6a83fb6c

Berechnung der Prüfsumme:

| $ ./az-klee-decode12.py | xxd -p -r | sha256sum
| cdbb0384d76a39a2001ac903b13056cf21b5c2f301fb8353aaffdc7e73454652 -

Marcel

[supersedes]
--
╭─────╮ ╭────╮ ╭────╮ ╭──╮ ╭─────╮ ..67..
─╮ │ ╭──╯ ╰─╮ ╰─╮ ╭─╮ │ │ │ ╰─╮ ╰───╮ ╰─╮ ..67..
│ │ ╰─╮ ╭─╯ ╰─╯ ╰─╮ │ ╰──╯ ╭─╯ ╭───╮ ╭─────╯ ╰─╮ ╭───
╰──╯ ╰───╯ ╰─╯ ╰─────╯ ╰───╯ ..60..╰──╯

Marcel Logen wrote:

> Stefan Claas in de.test:
>
> >Stefan Claas wrote:
> >> Marcel Logen wrote:
>
> [...]
> >> > | b2=str.maketrans('','','\n\r\t ')
> >> > | c3=a1.translate(b2)
> >> > | d4=str.maketrans('ABCDEFGHIJKLMNOPQRSTUVWXYZ','0123456789abcdef0123456789')
> >> > | e5=c3.translate(d4)
> >> > | print(e5)
> >>
> >> Das ging ja fix! :-)
>
> Ist ja auch nur ein Dekoder.
>
> Weil es beim Kodieren mehrere Möglichkeiten gibt,
> ist mir noch nicht klar, wie das genau laufen soll.

Mein az Encoder/Decoder funktioniert so (hoffe ich doch),
wie Herbert es erklärt hat.

Quote Herbert:

But I still don't understand the advantage over base16.
If you only can use A-Z as transferable digits, you can
use an alternative to the standard hex encoding:

0 A or Q
1 B or R
2 C or S
3 D or T
4 E or U
5 F or V
6 G or W
7 H or X
8 I or Y
9 J or Z
10 K
11 L
12 M
13 N
14 O
15 P

Because there are two ways to encode 0-9, you
can use this to send a second data stream. If
A-J is used a 0 bit transferred and if Q-Z is used
a 1 bit is transferred on this second channel. You
can use this for example for a check sum or an
error correcting code.

--
Grüße
Stefan

Stefan Claas in de.test:

>Marcel Logen wrote:

>> Weil es beim Kodieren mehrere Möglichkeiten gibt,
>> ist mir noch nicht klar, wie das genau laufen soll.
>
>Mein az Encoder/Decoder funktioniert so (hoffe ich doch),
>wie Herbert es erklärt hat.
>
>Quote Herbert:
[...]
>Because there are two ways to encode 0-9, you
>can use this to send a second data stream. If
>A-J is used a 0 bit transferred and if Q-Z is used
>a 1 bit is transferred on this second channel. You
>can use this for example for a check sum or an
>error correcting code.

Nutzt Du denn den "second channel", oder kodiert Dein
Encoder immer nur die jeweils erste Variante der beiden
Möglichkeiten?

Marcel
--
╮ ╭─────╮ ╭─╮ ╭───╮ ╭──╮ ..67..
│ ╭───╮ ╰──╮ ╰─╮ │ │ ╭─╮ ╭──╯ ╰───╯ ╰───╮ ..67..
╰─╯ ╰──╮ │ ╰─╯ │ │ ╰─╮ │ ╭──────────────╯ ╭─╮ ╭─╮ ╭──╮ ╭──╮
╰──╯ ..16..╰──╯ ╰─╯ ╰─────────────────╯ ╰──╯ ╰───╯ ╰─╯ ╰─

Marcel Logen wrote:

> Stefan Claas in de.test:
>
> >Marcel Logen wrote:
>
> >> Weil es beim Kodieren mehrere Möglichkeiten gibt,
> >> ist mir noch nicht klar, wie das genau laufen soll.
> >
> >Mein az Encoder/Decoder funktioniert so (hoffe ich doch),
> >wie Herbert es erklärt hat.
> >
> >Quote Herbert:
> [...]
> >Because there are two ways to encode 0-9, you
> >can use this to send a second data stream. If
> >A-J is used a 0 bit transferred and if Q-Z is used
> >a 1 bit is transferred on this second channel. You
> >can use this for example for a check sum or an
> >error correcting code.
>
> Nutzt Du denn den "second channel", oder kodiert Dein
> Encoder immer nur die jeweils erste Variante der beiden
> Möglichkeiten?

Mein Encoder/Decoder nutzt auch den zweiten Kanal, um A-Z
abzudecken. Zuvor hatte ich nur ein Kanal und dann ging das
nur bis P. So verstehe ich das zumindest.

--
Grüße
Stefan

Stefan Claas in de.test:

>Marcel Logen wrote:
>> Stefan Claas in de.test:
>> >Marcel Logen wrote:

>> >> Weil es beim Kodieren mehrere Möglichkeiten gibt,
>> >> ist mir noch nicht klar, wie das genau laufen soll.
[...]
>Mein Encoder/Decoder nutzt auch den zweiten Kanal, um A-Z
>abzudecken. Zuvor hatte ich nur ein Kanal und dann ging das
>nur bis P. So verstehe ich das zumindest.

Dann geht das wahrscheinlich nach dem Zufallsprinzip.

Aber eine spezielle Verwendung (wie von Herbert geschrie-
ben, z. B. für Error correction) für den zweiten Kanal
hast Du wohl nicht.

MOMPL

Ich habe mir jetzt mal Deinen Quellcode angesehen.

Da scheint tatsächlich eine Art Randomisierung vorge-
nommen zu werden, wenn ich das richtig verstanden habe:

Jedes Byte wird in zwei Teile geteilt, und dann wird
ein Teil mit Kanal 1 kodiert und der andere mit Kanal 2.
Beim nächsten Byte werden dann die Kanäle vertauscht.

Marcel
--
╭───────╮ ╭────╮ ╭───╮ ╭──────╮ ..63..╭──╮
╰────╮ ╰─╮ ╰──╮ ╰─╯ │ ..42..╭─╮ ╭─╯ ╭─╮ ╰──╮ ╭─╯ ╰
─╮ ╭─╮ ..10..╭─╮ ╰──╮ ╰──╮ │ ╭────╯ ╭──╮ │ │ │ ╭─╯ ╰────╯ ╰──╮
╰───╯ ╰───────╯ ╰─────╯ ╰──╯ ╰──────╯ ╰──╯ ╰─╯ ╰──────────────╯

Marcel Logen wrote:

> Stefan Claas in de.test:
>
> >Marcel Logen wrote:
> >> Stefan Claas in de.test:
> >> >Marcel Logen wrote:
>
> >> >> Weil es beim Kodieren mehrere Möglichkeiten gibt,
> >> >> ist mir noch nicht klar, wie das genau laufen soll.
> [...]
> >Mein Encoder/Decoder nutzt auch den zweiten Kanal, um A-Z
> >abzudecken. Zuvor hatte ich nur ein Kanal und dann ging das
> >nur bis P. So verstehe ich das zumindest.
>
> Dann geht das wahrscheinlich nach dem Zufallsprinzip.
>
> Aber eine spezielle Verwendung (wie von Herbert geschrie-
> ben, z. B. für Error correction) für den zweiten Kanal
> hast Du wohl nicht.

Nein, denn der wird ja für Q-Z genutzt.
> MOMPL
>
> Ich habe mir jetzt mal Deinen Quellcode angesehen.
>
> Da scheint tatsächlich eine Art Randomisierung vorge-
> nommen zu werden, wenn ich das richtig verstanden habe:
>
> Jedes Byte wird in zwei Teile geteilt, und dann wird
> ein Teil mit Kanal 1 kodiert und der andere mit Kanal 2.
> Beim nächsten Byte werden dann die Kanäle vertauscht.

Ja genau. Beim ersten High-Nibble, von byte 1 Kanal zwei
und Low-Nibble auf Kanal 1. Das wechselt dann immer.

--
Grüße
Stefan

Stefan Claas in de.test:

>Marcel Logen wrote:

>> Aber eine spezielle Verwendung (wie von Herbert geschrie-
>> ben, z. B. für Error correction) für den zweiten Kanal
>> hast Du wohl nicht.
>
>Nein, denn der wird ja für Q-Z genutzt.

Ich habe das so verstanden, daß man wegen der doppelten
Möglichkeiten (Q-Z statt A-J) noch weitere Informationen
im kodierten Text unterbringen kann. Also binär: 0, wenn
A-J genutzt wurde, und 1, wenn Q-Z genutzt wurde.

Leider habe ich gerade keine Zeit, ein Beispiel zu kon-
struieren, aber ich denke, das sollte prinzipiell gehen.

Marcel
--
╮ ╭─╮ ╭───╮ ╭───────╮ ..44..╭─╮ ╭──╮ ╭──╮
│ ╭─╮ ╭─╯ ╰──╮ ╰─╮ ╰──╯ ╭───╯ ╭──────╮ ╭───╯ ╰───╯ ╰─────╯ ╰─╮
╰──╯ ╰─╯ ╭──╯ ╭─╯ ╭────╯ ╭──╯ ╭───╯ │ ..58..╭─────╯
╰─────╯ ╰───────╯ ╰───────╯ ..58..╰───────╮

Marcel Logen in de.test:

>Ich habe das so verstanden, daß man wegen der doppelten
>Möglichkeiten (Q-Z statt A-J) noch weitere Informationen
>im kodierten Text unterbringen kann. Also binär: 0, wenn
>A-J genutzt wurde, und 1, wenn Q-Z genutzt wurde.
>
>Leider habe ich gerade keine Zeit, ein Beispiel zu kon-
>struieren, aber ich denke, das sollte prinzipiell gehen.

Hier doch noch schnell ein Beispiel:

| $ echo -n 'Hallo, Welt!' | xxd -p
| 48616c6c6f2c2057656c7421

Weitere Information sollen die acht Bits für den
Buchstaben "M" und acht Bits für "a" sein.

M: hex 4d

| $ bc -lq
| obase=2
| ibase=16
| 4D
| 1001101

a: hex 61 = 0110 0001

Also: 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1

0 1
0 A Q
1 B R
2 C S
3 D T
4 E U
5 F V
6 G W
7 H X
8 I Y
9 J Z
a K
b L
c M
d N
e O
f P

48616c6c6f2c2057656c7421
01001 1 0 1 0110000 1000 (nur bei Ziffern 0-9 möglich)
^^^ das ist sozusagen 'padding'
EYGBWMWMGPSMCQVHGFGMHECB

Damit hat man in dem 'Chiffrat' noch zwei zusätzliche
Bytes (16 Bits) untergebracht.

Es läßt sich 'normal' dekodieren - enthält aber außer-
dem noch die Information "Ma".

Leider weiß man im voraus nicht, wie viele Bits man noch
kodieren kann, da das ja nur bei den Hex-Ziffern 0 bis 9
geht. Das ist ein wenig doof.

Mir kommt das System wie eine Art Steganographie oder
Geheimschrift vor. ;-)

Marcel
--
╭─╮ ╭──────╮ ..29..╭──────╮ ╭─╮ ╭─────╮ ╭───────╮ ╭──╮
│ ╰─╮ ╭───╯ ╰───╮ ╭───╮ │..36..╰─╯ ╰─╯ │ ╰─────╮ │ ╭─╯ ╰
╭─╯ ╰─╯ ╭──────────╯ │ ╰─╮ │ ╭──╯..55..╭─╯ ╰─╯
╯ ╰─────────────╯ ╰─╯ ╰─────────╯ ..67..

Marcel Logen wrote:

> Marcel Logen in de.test:
>
> >Ich habe das so verstanden, daß man wegen der doppelten
> >Möglichkeiten (Q-Z statt A-J) noch weitere Informationen
> >im kodierten Text unterbringen kann. Also binär: 0, wenn
> >A-J genutzt wurde, und 1, wenn Q-Z genutzt wurde.
> >
> >Leider habe ich gerade keine Zeit, ein Beispiel zu kon-
> >struieren, aber ich denke, das sollte prinzipiell gehen.
>
> Hier doch noch schnell ein Beispiel:
>
> | $ echo -n 'Hallo, Welt!' | xxd -p
> | 48616c6c6f2c2057656c7421
>
> Weitere Information sollen die acht Bits für den
> Buchstaben "M" und acht Bits für "a" sein.
>
> M: hex 4d
>
> | $ bc -lq
> | obase=2
> | ibase=16
> | 4D
> | 1001101
>
> a: hex 61 = 0110 0001
>
> Also: 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1
>
> 0 1
> 0 A Q
> 1 B R
> 2 C S
> 3 D T
> 4 E U
> 5 F V
> 6 G W
> 7 H X
> 8 I Y
> 9 J Z
> a K
> b L
> c M
> d N
> e O
> f P
>
> 48616c6c6f2c2057656c7421
> 01001 1 0 1 0110000 1000 (nur bei Ziffern 0-9 möglich)
> ^^^ das ist sozusagen 'padding'
> EYGBWMWMGPSMCQVHGFGMHECB
>
> Damit hat man in dem 'Chiffrat' noch zwei zusätzliche
> Bytes (16 Bits) untergebracht.
>
> Es läßt sich 'normal' dekodieren - enthält aber außer-
> dem noch die Information "Ma".

Bei mir lässt sich das auch dekodieren, jedoch enthält
es nicht Ma.

> Leider weiß man im voraus nicht, wie viele Bits man noch
> kodieren kann, da das ja nur bei den Hex-Ziffern 0 bis 9
> geht. Das ist ein wenig doof.
>
> Mir kommt das System wie eine Art Steganographie oder
> Geheimschrift vor. ;-)

Na ja, ich sehe das als Ersatz für base16, wenn man keine
Ziffern unterbringen kann.

--
Grüße
Stefan

Stefan Claas wrote:

> Marcel Logen wrote:

> > Mir kommt das System wie eine Art Steganographie oder
> > Geheimschrift vor. ;-)
>
> Na ja, ich sehe das als Ersatz für base16, wenn man keine
> Ziffern unterbringen kann.

Was natürlich auch ein plus von az oder besser base26 ist, man
kann Fremdsprachen damit kodieren und dann damit alte heimische Handys,
für SMS Nachrichten, nutzen, da die keine Fremdsprachen unterstützen.

--
Grüße
Stefan

Stefan Claas in de.test:

>Stefan Claas wrote:
>> Marcel Logen wrote:

>> > Mir kommt das System wie eine Art Steganographie oder
>> > Geheimschrift vor. ;-)
>>
>> Na ja, ich sehe das als Ersatz für base16, wenn man keine
>> Ziffern unterbringen kann.

Mit dem Obigen meinte ich aber nicht den az-Encoder an
sich, sondern die Möglichkeit, da sozusagen 'unsichtbar'
weitere Daten unterbringen zu können.

Ich wollte das heute eigentlich noch näher erläutern,
bin aber leider nicht dazu gekommen.

>Was natürlich auch ein plus von az oder besser base26 ist, man
>kann Fremdsprachen damit kodieren und dann damit alte heimische Handys,
>für SMS Nachrichten, nutzen, da die keine Fremdsprachen unterstützen.

Ja, wenn ein Encoder mit binären Daten umgehen kann,
ist das immer gut. Alles andere ist IMHO 'Murks'.

Marcel
--
╭──╮ ╭──╮ ╭──╮ ╭───╮ ╭──╮ ╭───╮ ╭─╮ ..49..╭─────╮ ╭──╮
│ ╰──╯ ╰─╯ ╰─╮ ╰─╮ ╰─╯ │ │ ╰──╯ ╰──╮ ╭───────╯ ╭──╯ │ ╰─╮
─╯ ╰─╮ ╰───╮ ╰─╯ ╭─────╯ │ ..49..╭──╯ ╰─╮ │
╰──────╯ ╰────────╯ ..49..╰──────────╯ ╰───

Stefan Claas in de.test:

>Marcel Logen wrote:
>> Marcel Logen in de.test:

>> >Ich habe das so verstanden, daß man wegen der doppelten
>> >Möglichkeiten (Q-Z statt A-J) noch weitere Informationen
>> >im kodierten Text unterbringen kann. Also binär: 0, wenn
>> >A-J genutzt wurde, und 1, wenn Q-Z genutzt wurde.
>> >
>> >Leider habe ich gerade keine Zeit, ein Beispiel zu kon-
>> >struieren, aber ich denke, das sollte prinzipiell gehen.
>>
>> Hier doch noch schnell ein Beispiel:
>>
>> | $ echo -n 'Hallo, Welt!' | xxd -p
>> | 48616c6c6f2c2057656c7421
>>
>> Weitere Information sollen die acht Bits für den
>> Buchstaben "M" und acht Bits für "a" sein.
>>
>> M: hex 4d
>>
>> | $ bc -lq
>> | obase=2
>> | ibase=16
>> | 4D
>> | 1001101
>>
>> a: hex 61 = 0110 0001
>>
>> Also: 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1
>>
>> 0 1
>> 0 A Q
>> 1 B R
>> 2 C S
>> 3 D T
>> 4 E U
>> 5 F V
>> 6 G W
>> 7 H X
>> 8 I Y
>> 9 J Z
>> a K
>> b L
>> c M
>> d N
>> e O
>> f P
>>
>> 48616c6c6f2c2057656c7421
>> 01001 1 0 1 0110000 1000 (nur bei Ziffern 0-9 möglich)
>> ^^^ das ist sozusagen 'padding'
>> EYGBWMWMGPSMCQVHGFGMHECB
>>
>> Damit hat man in dem 'Chiffrat' noch zwei zusätzliche
>> Bytes (16 Bits) untergebracht.
>>
>> Es läßt sich 'normal' dekodieren - enthält aber außer-
>> dem noch die Information "Ma".
>
>Bei mir lässt sich das auch dekodieren, jedoch enthält
>es nicht Ma.

Das "Ma" steht ja auch nicht im Ergebnis der Dekodierung,
sondern ist eine (auf den ersten Blick) unsichtbare Zusatz-
information.

Den Text "Hallo, Welt!" kann man auch so kodieren, wenn
man immer die linke Spalte nimmt (die mit der Null drüber):

48616c6c6f2c2057656c7421
EIGBGMGMGPCMCAFHGFGMHECB

Noch mal zum Vergleich (von oben; wo auch ab und zu die
rechte Spalte zum Einsatz kommt):

EYGBWMWMGPSMCQVHGFGMHECB

Die Unterschiede resultieren also daraus, daß man je nach
Bit-Wert der Zusatzinformation "Ma" mal die rechte oder
linke Spalte benutzt.

Marcel
--
╭────╮ ╭──╮ ╭────────╮ ╭──────────╮ ..67..
╭─╮ ╰──╮ ╰───╯ ╰─╮ ╰────╮ ╰──╮ ╰──╮ ╭──╯ ╭─╮ ..67..
╯ │ ╭─────╯ ╭──────╯ ╭─╮ ╭─╯ ╭───╯ ╭─╯ ╰─╮ ╭─╮ │ ╰─────╮ ╭─
╰──╯ ╰────────╯ ╰─╯ ╰────────╯ ╰─╯ ╰───╯ ..62..╰──╯

Marcel Logen wrote:

> Stefan Claas in de.test:
>
> >Marcel Logen wrote:
> >> Marcel Logen in de.test:
>
> >> >Ich habe das so verstanden, daß man wegen der doppelten
> >> >Möglichkeiten (Q-Z statt A-J) noch weitere Informationen
> >> >im kodierten Text unterbringen kann. Also binär: 0, wenn
> >> >A-J genutzt wurde, und 1, wenn Q-Z genutzt wurde.
> >> >
> >> >Leider habe ich gerade keine Zeit, ein Beispiel zu kon-
> >> >struieren, aber ich denke, das sollte prinzipiell gehen.
> >>
> >> Hier doch noch schnell ein Beispiel:
> >>
> >> | $ echo -n 'Hallo, Welt!' | xxd -p
> >> | 48616c6c6f2c2057656c7421
> >>
> >> Weitere Information sollen die acht Bits für den
> >> Buchstaben "M" und acht Bits für "a" sein.
> >>
> >> M: hex 4d
> >>
> >> | $ bc -lq
> >> | obase=2
> >> | ibase=16
> >> | 4D
> >> | 1001101
> >>
> >> a: hex 61 = 0110 0001
> >>
> >> Also: 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1
> >>
> >> 0 1
> >> 0 A Q
> >> 1 B R
> >> 2 C S
> >> 3 D T
> >> 4 E U
> >> 5 F V
> >> 6 G W
> >> 7 H X
> >> 8 I Y
> >> 9 J Z
> >> a K
> >> b L
> >> c M
> >> d N
> >> e O
> >> f P
> >>
> >> 48616c6c6f2c2057656c7421
> >> 01001 1 0 1 0110000 1000 (nur bei Ziffern 0-9 möglich)
> >> ^^^ das ist sozusagen 'padding'
> >> EYGBWMWMGPSMCQVHGFGMHECB
> >>
> >> Damit hat man in dem 'Chiffrat' noch zwei zusätzliche
> >> Bytes (16 Bits) untergebracht.
> >>
> >> Es läßt sich 'normal' dekodieren - enthält aber außer-
> >> dem noch die Information "Ma".
> >
> >Bei mir lässt sich das auch dekodieren, jedoch enthält
> >es nicht Ma.
>
> Das "Ma" steht ja auch nicht im Ergebnis der Dekodierung,
> sondern ist eine (auf den ersten Blick) unsichtbare Zusatz-
> information.
>
> Den Text "Hallo, Welt!" kann man auch so kodieren, wenn
> man immer die linke Spalte nimmt (die mit der Null drüber):
>
> 48616c6c6f2c2057656c7421
> EIGBGMGMGPCMCAFHGFGMHECB
>
> Noch mal zum Vergleich (von oben; wo auch ab und zu die
> rechte Spalte zum Einsatz kommt):
>
> EYGBWMWMGPSMCQVHGFGMHECB
>
> Die Unterschiede resultieren also daraus, daß man je nach
> Bit-Wert der Zusatzinformation "Ma" mal die rechte oder
> linke Spalte benutzt.

Muss das nochmal in Ruhe und bei Zeiten durchgehen!

Kommt dein Decoder[1] damit auch klar, bzw. wäre das so auch richtig?

$ echo -n 'Hallo, Welt!' | az
UIGRWMGMWPCMSAFXWFGMXECR

$ echo -n 'Hallo, Welt!' | ./az2 -h Ma
UYGRGMGMWPSMSAFHWVGMHUCB

[1] Meiner hat deine beiden Beispiele richtig interpretiert,
also nur mit Kanal 1 und dann mit beiden.

--
Grüße
Stefan

Stefan Claas in de.test:

>Marcel Logen wrote:

[...]

>> Die Unterschiede resultieren also daraus, daß man je nach
>> Bit-Wert der Zusatzinformation "Ma" mal die rechte oder
>> linke Spalte benutzt.
>
>Muss das nochmal in Ruhe und bei Zeiten durchgehen!
>
>Kommt dein Decoder[1] damit auch klar, bzw. wäre das so auch richtig?
>
>$ echo -n 'Hallo, Welt!' | az
>UIGRWMGMWPCMSAFXWFGMXECR
>
>$ echo -n 'Hallo, Welt!' | ./az2 -h Ma
>UYGRGMGMWPSMSAFHWVGMHUCB

Beides wird hier korrekt dekodiert.

Allerdings muß ich meinen Dekoder noch umbauen, damit
mir auch angezeigt wird, ob jeweils die linke oder rech-
te Spalte benutzt wurde. Händisch ist mir das jetzt zu
aufwendig und zu fehlerträchtig.

Heißt das "-h Ma", daß da sozusagen 'hidden' der String
"Ma" drinsteckt?

Marcel
--
╭────────╮ ╭─╮ ╭─╮ ..55..╭──╮ ╭──╮ │
╭─╮ ╭─────╮ ..21..╭─╮ ╰────╮ ╰─╯ │ ╭──╯ ╰─╮ │ ╰──╯ ╰─╯
╭─────╯ │ ╰──╮ │ ╭──╮ ╭─╯ ╰──╮ ╭─╯ ╭──╯ │ ╭───╯ ╰───────╮
│ ╰─────╯ ╰─╯ ╰─╯ ╰──╯..36..╰─────╯ ╰─────────────────╯

Marcel Logen wrote:

> Stefan Claas in de.test:
>
> >Marcel Logen wrote:
>
> [...]
>
> >> Die Unterschiede resultieren also daraus, daß man je nach
> >> Bit-Wert der Zusatzinformation "Ma" mal die rechte oder
> >> linke Spalte benutzt.
> >
> >Muss das nochmal in Ruhe und bei Zeiten durchgehen!
> >
> >Kommt dein Decoder[1] damit auch klar, bzw. wäre das so auch richtig?
> >
> >$ echo -n 'Hallo, Welt!' | az
> >UIGRWMGMWPCMSAFXWFGMXECR
> >
> >$ echo -n 'Hallo, Welt!' | ./az2 -h Ma
> >UYGRGMGMWPSMSAFHWVGMHUCB
>
> Beides wird hier korrekt dekodiert.

Sehr gut! Wie es aussieht ist es zwischen uns beiden
egal ob wir zuerst Kanal 1 oder 2 nutzen, da unsere
Decoder beides verstehen. :-)
> Allerdings muß ich meinen Dekoder noch umbauen, damit
> mir auch angezeigt wird, ob jeweils die linke oder rech-
> te Spalte benutzt wurde. Händisch ist mir das jetzt zu
> aufwendig und zu fehlerträchtig.
>
> Heißt das "-h Ma", daß da sozusagen 'hidden' der String
> "Ma" drinsteckt?

Ja, das sollte so sein. Ich nehme das aber wieder mit dem
-h flag heraus, weil ich da Probleme beim dekodieren habe
und es nur sinnvoll ist wenn beide Parteien IMHO anonym,
gegenüber Dritte, wären. Ist aber trotzdem eine nette Idee
von dir! ;-)

--
Grüße
Stefan

Stefan Claas in de.test:

>Marcel Logen wrote:
>> Stefan Claas in de.test:
>> >Marcel Logen wrote:

>> >$ echo -n 'Hallo, Welt!' | az
>> >UIGRWMGMWPCMSAFXWFGMXECR
>> >
>> >$ echo -n 'Hallo, Welt!' | ./az2 -h Ma
>> >UYGRGMGMWPSMSAFHWVGMHUCB
>>
>> Beides wird hier korrekt dekodiert.
>
>Sehr gut! Wie es aussieht ist es zwischen uns beiden
>egal ob wir zuerst Kanal 1 oder 2 nutzen, da unsere
>Decoder beides verstehen. :-)

Ob bei den Dezimalziffern die Spalte 0 oder die Spalte 1
benutzt wird, sollte keinen Unteschied machen.

>> Allerdings muß ich meinen Dekoder noch umbauen, damit
>> mir auch angezeigt wird, ob jeweils die linke oder rech-
>> te Spalte benutzt wurde. Händisch ist mir das jetzt zu
>> aufwendig und zu fehlerträchtig.

| $ ./az-klee-decode13.py
| {'A': ('0', '0'), 'B': ('1', '0'), 'C': ('2', '0'), 'D': ('3', '0'), 'E': ('4', '0'), 'F': ('5', '0'), 'G': ('6', '0'), 'H': ('7', '0'), 'I': ('8', '0'), 'J': ('9', '0'), 'K': ('a', '-'), 'L': ('b', '-'), 'M': ('c', '-'), 'N': ('d', '-'), 'O': ('e', '-'), 'P': ('f', '-'), 'Q': ('0', '1'), 'R': ('1', '1'), 'S': ('2', '1'), 'T': ('3', '1'), 'U': ('4', '1'), 'V': ('5', '1'), 'W': ('6', '1'), 'X': ('7', '1'), 'Y': ('8', '1'), 'Z': ('9', '1')}
| UIGRWMGMWPCMSAFXWFGMXECR
| 48616c6c6f2c2057656c7421
| 10011-0-1-0-1001100-1001

| $ vi az-klee-decode13.py

| $ ./az-klee-decode13.py
| {'A': ('0', '0'), 'B': ('1', '0'), 'C': ('2', '0'), 'D': ('3', '0'), 'E': ('4', '0'), 'F': ('5', '0'), 'G': ('6', '0'), 'H': ('7', '0'), 'I': ('8', '0'), 'J': ('9', '0'), 'K': ('a', '-'), 'L': ('b', '-'), 'M': ('c', '-'), 'N': ('d', '-'), 'O': ('e', '-'), 'P': ('f', '-'), 'Q': ('0', '1'), 'R': ('1', '1'), 'S': ('2', '1'), 'T': ('3', '1'), 'U': ('4', '1'), 'V': ('5', '1'), 'W': ('6', '1'), 'X': ('7', '1'), 'Y': ('8', '1'), 'Z': ('9', '1')}
| UYGRGMGMWPSMSAFHWVGMHUCB
| 48616c6c6f2c2057656c7421
| 11010-0-1-1-1000110-0100

In der (binären) letzten Zeile wird angezeigt, ob Spalte 0
oder Spalte 1 benutzt wurde.

Allerdings kann ich jetzt da kein "Ma" (01001101 01100001)
erkennen. Ich vermute, daß da Dein Abwechslungs-Mechanis-
mus noch zugeschlagen hat, oder so.

>> Heißt das "-h Ma", daß da sozusagen 'hidden' der String
>> "Ma" drinsteckt?
>
>Ja, das sollte so sein. Ich nehme das aber wieder mit dem
>-h flag heraus, weil ich da Probleme beim dekodieren habe
>und es nur sinnvoll ist wenn beide Parteien IMHO anonym,
>gegenüber Dritte, wären. Ist aber trotzdem eine nette Idee
>von dir! ;-)

Die Idee stammt aus dem Posting von Herbert, nicht von
mir. Ist aber in der Tat ein wenig umständlich in der Um-
setzung.

Marcel
--
╮ ╭─╮ ╭─╮ ..21..╭─────╮ ╭──╮ ╭───╮ ╭─╮ ╭─────╮ ╭───
╰──╮ │ ╰─╯ ╰──╮ ..19..╭─╯ ╰───╯ ╰─╮ ╰─╮ ╰──╯ ╰──╯ ╭──╯ ╭─╯
╭─╯ ╰──╮ ╭──╯ ╭────╯ ╰────╯ ..54..╰──────╯
╰────────╯ ╰─────╯ ..67..