info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: dragon-cipher C-Quelle (vollständig)
2 views
Skip to first unread message
Helmut Schellong
Apr 10, 2022, 6:23:50 AM4/10/22
to
On 04/09/2022 15:55, Helmut Schellong wrote:
> On 04/09/2022 13:41, Enrik Berkhan wrote:
>> Helmut Schellong <r...@schellong.biz> wrote:
>>> Die Beschreibung ist deutlich weniger genau als die von Rabbit.
>>> Hinsichtlich Text und der Pseudo-Programmiersprache.
>>> Das hatte Folgen.
>>> https://www.ecrypt.eu.org/stream/p3ciphers/dragon/dragon_p3.pdf
>>
>> Ich denke, in dem Paper sind bei der Initialisierung und
>> Stromgenerierung die Schiebeoperationen und die Neuzuweisungen an die
>> Schieberegisterelemente ungünstig beschrieben.
>>
>> Ich gebe aber zu, dass meine Implementierung auch noch nicht
>> funktioniert.
>>
>>
> Meine funktioniert ja offenbar einwandfrei - nur eben nicht mit Ausgabe-Übereinstimmung.
> Die kryptographische Qualität scheint ungebrochen.
>
> Es fängt mit der F-Funktion an (Table 1, Fig 1):
> Es wird von input-words a b c d e f und output-words a' b' c' d' e' f' geschrieben.
> Also 2 x 6 Variablen, was allerdings nach einiger Überlegung unlogisch wirkt.
> x' wird später als geSWAPter Inhalt beschrieben: x' = x>>16 | x<<16
> Auch dieses wirkt jedenfalls für a'..f' unlogisch.
> Logisch ist, daß b d f verändert werden und nachfolgend bei c e a verwendet werden.
> Und zwar jeweils in allen drei Gruppen in gleicher Weise (1.2.|3.4.|5.6.).
> Das sieht man in meiner Quelle.
>
> Der Verkettungsoperator || ist komplett unbeschrieben.
> In Rabbit ist in X = a || b das 'a' (links) stets der hochwertige Teil.
> Also habe ich auch in dragon das so getan.
> Bei x = x0||x1||x2||x3 ist x0 das höchstwertige Byte, etc.
> In Code-Schnipseln aus dem Netz hat sich das bestätigt:
> u32 a, b, c, d;
> u32 e = 0x00004472;
> u32 f = 0x61676F6E;
> (M= 0x0000447261676F6E, M= e||f; etc.)
> In Table 2-1. weiß man nicht sicher, wie genau zugewiesen werden soll.
> Sicher ist nur 1024 bit = 4 x 256 bit.
> Ich habe gleichsinnig zugewiesen.
>
> In Table 2-7 endet die Operation mit W1 = W0 (shifting).
> Danach haben W1 und W0 den gleichen Wert.
> Beim realen Shiften werden aber 0-bits nachgezogen.
>
> In Table 3-5 müßte es logisch
> for (i=31; i>1; --i) B[i]= B[i-2];
> lauten.
> Also abwärts, wie in Table 2-7.
>
>
> Die fehlende Übereinstimmung kann mir aber egal sein, weil ich bei der Anwendung
> niemals mit einer _anderen_ Implementation (auf einem Server) zusammenarbeite, sondern
> nur auf lokaler Festplatte.
> Andernfalls müßten sogar die Formate von Key und Ausgabe in den write()-Puffer
> (k --> buf[]) geklärt werden.
>
>
>
Von de.sci.electronics nach de.comp.lang.c kopiert.
Vorläufer-Posting:
------------------
http://www.schellong.de/htm/dragon.c.html (Aktuell zwei Zeilen mehr.)
Die Beschreibung ist deutlich weniger genau als die von Rabbit.
Hinsichtlich Text und der Pseudo-Programmiersprache.
Das hatte Folgen.
https://www.ecrypt.eu.org/stream/p3ciphers/dragon/dragon_p3.pdf
Der Algorithmus funktioniert.
Allerdings sind die Test-Ausgaben meiner Implementation
nicht gleich mit den Referenz-Ausgaben.
Es ist mir auch in mehreren Tagen nicht gelungen, das erfolgreich zu ändern.
Das ist wegen meiner Verwendungsart jedoch egal.
Meine Testausgaben sind in den Zeilen 275..349.
Die Testausgaben zeigen ein gutes random-Verhalten.
Änderungen von einzelnen Key-Bits ändern den Keystream jeweils total.
Die verschlüsselte Textdatei dragon.c ist vom Überblick her einwandfrei verschlüsselt:
dragon.c':
11b+272 e0 d4 29 4c ee c6 4d a7 67 2d 68 be f4 b3 14 7c ..)L..M.g-h....|
11b+288 84 07 11 73 a4 25 86 3c 4b bb 08 1b f7 de dd 3a ...s.%.<K......:
11b+304 db d7 c4 9e 22 3f a2 72 61 41 fa 0a ab da 0d 82 ...."?.raA......
11b+320 f2 d3 e7 15 ba 21 d4 e7 b2 0f a4 34 cf 78 69 e6 .....!.....4.xi.
11b+336 c7 aa 95 04 f4 b3 9d ee f7 c4 07 6d d5 b8 f1 df ...........m....
11b+352 24 a9 e7 a5 65 7d 8d 41 3f e4 76 b3 a5 ff a4 74 $...e}.A?.v....t
11b+368 b1 2a 47 7f 77 b3 e1 8e fe a1 5d 0d 4f 09 cf 09 .*G.w.....].O...
11b+384 46 58 44 1e f5 92 1a 2e b5 d5 9c c0 c0 c2 ef 75 FXD............u
11b+400 08 ee 38 b0 4c 58 d1 7e 96 08 26 7a 60 23 b6 a3 ..8.LX.~..&z`#..
11b+416 c7 a6 7f 18 54 d9 07 e9 2e 4d 8d 8b 58 00 0a 49 ....T....M..X..I
11b+432 55 8c 6e 8f 46 79 02 6d f1 3f dc 69 0a 99 0f b8 U.n.Fy.m.?.i....
11b+448 6f 5f 87 89 5a f7 c4 99 c5 fe a4 00 f4 a4 53 8f o_..Z.........S.
11b+464 8b ad ff 69 23 10 a7 ed 00 5b 14 1f f6 b5 99 ac ...i#....[......
11b+480 90 5f eb 72 27 31 96 eb ac 18 57 c2 2a 1a b9 b5 ._.r'1....W.*...
11b+496 89 a7 57 c9 e2 67 e3 f0 7f 6c 6d b1 37 dc 65 da ..W..g...lm.7.e.
12b+000 a1 33 96 5d 3b 7c 35 fb 4e 05 59 cb 45 08 f2 33 .3.];|5.N.Y.E..3
12b+016 82 9c a9 47 b8 dc 87 af 01 20 83 50 ab 1e 1b 1d ...G..... .P....
12b+032 11 22 bf 86 2c c1 47 10 97 1f 30 73 e7 c6 a5 7f ."..,.G...0s....
12b+048 9e ea 43 80 ef 83 19 1b b3 48 46 89 19 a4 53 43 ..C......HF...SC
12b+064 6c 8e bd b7 fa 3e 89 36 a0 a2 c3 89 65 ee cc c5 l....>.6....e...
12b+080 3a 81 f0 2d 87 dd c3 92 1e 94 7d ce 81 f3 ab 17 :..-......}.....
12b+096 b3 2f 04 3b 83 96 84 32 6d 2e 46 8a cb f9 ad 84 ./.;...2m.F.....
12b+112 94 60 33 b4 63 45 eb ce 02 19 50 02 93 b7 e4 80 .`3.cE....P.....
12b+128 a7 20 fe 3e 9f 34 ce e7 e7 b3 c7 9f 6a 0d 33 e3 . .>.4......j.3.
12b+144 28 f4 ec b7 53 82 0f bd f4 4a 3a bb fe a1 08 38 (...S....J:....8
12b+160 0c b4 30 ea 24 ef 54 cd e5 99 cf 79 67 45 7c 8e ..0.$.T....ygE|.
12b+176 d2 e0 a7 51 d2 fb b2 5b 76 b2 c2 5f ae 19 18 64 ...Q...[v.._...d
12b+192 c1 5c 24 02 44 1a 47 c2 52 9c 5f 47 d6 85 32 d9 .\$.D.G.R._G..2.
12b+208 87 a8 f8 0a 42 df 99 a5 5b b1 0d 09 1e 69 d6 02 ....B...[....i..
12b+224 73 3a a0 da ba 98 69 6b 14 03 37 07 73 ad 6a b5 s:....ik..7.s.j.
12b+240 39 77 3c f8 4d 6d 89 8b fd 30 ce 10 29 45 4c 1b 9w<.Mm...0..)EL.
12b+256 35 6d de e5 83 b0 b1 e4 32 3d d7 49 d5 bc e5 86 5m......2=.I....
12b+272 1d 00 0e 6b d6 58 c9 02 72 d0 e2 2a e0 3b 15 08 ...k.X..r..*.;..
12b+288 82 fe 53 44 31 49 a8 3d 43 11 12 bb f4 05 0d 01 ..SD1I.=C.......
12b+304 61 7e 40 21 ac a6 12 2f 4f ac db ca 54 f1 53 3f a~@!.../O...T.S?
12b+320 3f 21 f7 16 1e 34 ff f5 d8 6a 4b 63 2c 06 05 62 ?!...4...jKc,..b
--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm
> On 04/09/2022 13:41, Enrik Berkhan wrote:
>> Helmut Schellong <r...@schellong.biz> wrote:
>>> Die Beschreibung ist deutlich weniger genau als die von Rabbit.
>>> Hinsichtlich Text und der Pseudo-Programmiersprache.
>>> Das hatte Folgen.
>>> https://www.ecrypt.eu.org/stream/p3ciphers/dragon/dragon_p3.pdf
>>
>> Ich denke, in dem Paper sind bei der Initialisierung und
>> Stromgenerierung die Schiebeoperationen und die Neuzuweisungen an die
>> Schieberegisterelemente ungünstig beschrieben.
>>
>> Ich gebe aber zu, dass meine Implementierung auch noch nicht
>> funktioniert.
>>
>>
> Meine funktioniert ja offenbar einwandfrei - nur eben nicht mit Ausgabe-Übereinstimmung.
> Die kryptographische Qualität scheint ungebrochen.
>
> Es fängt mit der F-Funktion an (Table 1, Fig 1):
> Es wird von input-words a b c d e f und output-words a' b' c' d' e' f' geschrieben.
> Also 2 x 6 Variablen, was allerdings nach einiger Überlegung unlogisch wirkt.
> x' wird später als geSWAPter Inhalt beschrieben: x' = x>>16 | x<<16
> Auch dieses wirkt jedenfalls für a'..f' unlogisch.
> Logisch ist, daß b d f verändert werden und nachfolgend bei c e a verwendet werden.
> Und zwar jeweils in allen drei Gruppen in gleicher Weise (1.2.|3.4.|5.6.).
> Das sieht man in meiner Quelle.
>
> Der Verkettungsoperator || ist komplett unbeschrieben.
> In Rabbit ist in X = a || b das 'a' (links) stets der hochwertige Teil.
> Also habe ich auch in dragon das so getan.
> Bei x = x0||x1||x2||x3 ist x0 das höchstwertige Byte, etc.
> In Code-Schnipseln aus dem Netz hat sich das bestätigt:
> u32 a, b, c, d;
> u32 e = 0x00004472;
> u32 f = 0x61676F6E;
> (M= 0x0000447261676F6E, M= e||f; etc.)
> In Table 2-1. weiß man nicht sicher, wie genau zugewiesen werden soll.
> Sicher ist nur 1024 bit = 4 x 256 bit.
> Ich habe gleichsinnig zugewiesen.
>
> In Table 2-7 endet die Operation mit W1 = W0 (shifting).
> Danach haben W1 und W0 den gleichen Wert.
> Beim realen Shiften werden aber 0-bits nachgezogen.
>
> In Table 3-5 müßte es logisch
> for (i=31; i>1; --i) B[i]= B[i-2];
> lauten.
> Also abwärts, wie in Table 2-7.
>
>
> Die fehlende Übereinstimmung kann mir aber egal sein, weil ich bei der Anwendung
> niemals mit einer _anderen_ Implementation (auf einem Server) zusammenarbeite, sondern
> nur auf lokaler Festplatte.
> Andernfalls müßten sogar die Formate von Key und Ausgabe in den write()-Puffer
> (k --> buf[]) geklärt werden.
>
>
>
Von de.sci.electronics nach de.comp.lang.c kopiert.
Vorläufer-Posting:
------------------
http://www.schellong.de/htm/dragon.c.html (Aktuell zwei Zeilen mehr.)
Die Beschreibung ist deutlich weniger genau als die von Rabbit.
Hinsichtlich Text und der Pseudo-Programmiersprache.
Das hatte Folgen.
https://www.ecrypt.eu.org/stream/p3ciphers/dragon/dragon_p3.pdf
Der Algorithmus funktioniert.
Allerdings sind die Test-Ausgaben meiner Implementation
nicht gleich mit den Referenz-Ausgaben.
Es ist mir auch in mehreren Tagen nicht gelungen, das erfolgreich zu ändern.
Das ist wegen meiner Verwendungsart jedoch egal.
Meine Testausgaben sind in den Zeilen 275..349.
Die Testausgaben zeigen ein gutes random-Verhalten.
Änderungen von einzelnen Key-Bits ändern den Keystream jeweils total.
Die verschlüsselte Textdatei dragon.c ist vom Überblick her einwandfrei verschlüsselt:
dragon.c':
11b+272 e0 d4 29 4c ee c6 4d a7 67 2d 68 be f4 b3 14 7c ..)L..M.g-h....|
11b+288 84 07 11 73 a4 25 86 3c 4b bb 08 1b f7 de dd 3a ...s.%.<K......:
11b+304 db d7 c4 9e 22 3f a2 72 61 41 fa 0a ab da 0d 82 ...."?.raA......
11b+320 f2 d3 e7 15 ba 21 d4 e7 b2 0f a4 34 cf 78 69 e6 .....!.....4.xi.
11b+336 c7 aa 95 04 f4 b3 9d ee f7 c4 07 6d d5 b8 f1 df ...........m....
11b+352 24 a9 e7 a5 65 7d 8d 41 3f e4 76 b3 a5 ff a4 74 $...e}.A?.v....t
11b+368 b1 2a 47 7f 77 b3 e1 8e fe a1 5d 0d 4f 09 cf 09 .*G.w.....].O...
11b+384 46 58 44 1e f5 92 1a 2e b5 d5 9c c0 c0 c2 ef 75 FXD............u
11b+400 08 ee 38 b0 4c 58 d1 7e 96 08 26 7a 60 23 b6 a3 ..8.LX.~..&z`#..
11b+416 c7 a6 7f 18 54 d9 07 e9 2e 4d 8d 8b 58 00 0a 49 ....T....M..X..I
11b+432 55 8c 6e 8f 46 79 02 6d f1 3f dc 69 0a 99 0f b8 U.n.Fy.m.?.i....
11b+448 6f 5f 87 89 5a f7 c4 99 c5 fe a4 00 f4 a4 53 8f o_..Z.........S.
11b+464 8b ad ff 69 23 10 a7 ed 00 5b 14 1f f6 b5 99 ac ...i#....[......
11b+480 90 5f eb 72 27 31 96 eb ac 18 57 c2 2a 1a b9 b5 ._.r'1....W.*...
11b+496 89 a7 57 c9 e2 67 e3 f0 7f 6c 6d b1 37 dc 65 da ..W..g...lm.7.e.
12b+000 a1 33 96 5d 3b 7c 35 fb 4e 05 59 cb 45 08 f2 33 .3.];|5.N.Y.E..3
12b+016 82 9c a9 47 b8 dc 87 af 01 20 83 50 ab 1e 1b 1d ...G..... .P....
12b+032 11 22 bf 86 2c c1 47 10 97 1f 30 73 e7 c6 a5 7f ."..,.G...0s....
12b+048 9e ea 43 80 ef 83 19 1b b3 48 46 89 19 a4 53 43 ..C......HF...SC
12b+064 6c 8e bd b7 fa 3e 89 36 a0 a2 c3 89 65 ee cc c5 l....>.6....e...
12b+080 3a 81 f0 2d 87 dd c3 92 1e 94 7d ce 81 f3 ab 17 :..-......}.....
12b+096 b3 2f 04 3b 83 96 84 32 6d 2e 46 8a cb f9 ad 84 ./.;...2m.F.....
12b+112 94 60 33 b4 63 45 eb ce 02 19 50 02 93 b7 e4 80 .`3.cE....P.....
12b+128 a7 20 fe 3e 9f 34 ce e7 e7 b3 c7 9f 6a 0d 33 e3 . .>.4......j.3.
12b+144 28 f4 ec b7 53 82 0f bd f4 4a 3a bb fe a1 08 38 (...S....J:....8
12b+160 0c b4 30 ea 24 ef 54 cd e5 99 cf 79 67 45 7c 8e ..0.$.T....ygE|.
12b+176 d2 e0 a7 51 d2 fb b2 5b 76 b2 c2 5f ae 19 18 64 ...Q...[v.._...d
12b+192 c1 5c 24 02 44 1a 47 c2 52 9c 5f 47 d6 85 32 d9 .\$.D.G.R._G..2.
12b+208 87 a8 f8 0a 42 df 99 a5 5b b1 0d 09 1e 69 d6 02 ....B...[....i..
12b+224 73 3a a0 da ba 98 69 6b 14 03 37 07 73 ad 6a b5 s:....ik..7.s.j.
12b+240 39 77 3c f8 4d 6d 89 8b fd 30 ce 10 29 45 4c 1b 9w<.Mm...0..)EL.
12b+256 35 6d de e5 83 b0 b1 e4 32 3d d7 49 d5 bc e5 86 5m......2=.I....
12b+272 1d 00 0e 6b d6 58 c9 02 72 d0 e2 2a e0 3b 15 08 ...k.X..r..*.;..
12b+288 82 fe 53 44 31 49 a8 3d 43 11 12 bb f4 05 0d 01 ..SD1I.=C.......
12b+304 61 7e 40 21 ac a6 12 2f 4f ac db ca 54 f1 53 3f a~@!.../O...T.S?
12b+320 3f 21 f7 16 1e 34 ff f5 d8 6a 4b 63 2c 06 05 62 ?!...4...jKc,..b
--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm
Bonita Montero
Apr 10, 2022, 6:46:32 AM4/10/22
to
> Allerdings sind die Test-Ausgaben meiner Implementation
> nicht gleich mit den Referenz-Ausgaben.
Nimm besser ROT13, das kriegste hin.
> nicht gleich mit den Referenz-Ausgaben.
Enrik Berkhan
Apr 10, 2022, 9:53:05 AM4/10/22
to
Helmut Schellong <r...@schellong.biz> wrote:
> Der Algorithmus funktioniert.
> Allerdings sind die Test-Ausgaben meiner Implementation
> nicht gleich mit den Referenz-Ausgaben.
> Es ist mir auch in mehreren Tagen nicht gelungen, das erfolgreich zu ändern.
> Das ist wegen meiner Verwendungsart jedoch egal.
Von mir aus kann dir das gerne egal sein.
> Der Algorithmus funktioniert.
> Allerdings sind die Test-Ausgaben meiner Implementation
> nicht gleich mit den Referenz-Ausgaben.
> Es ist mir auch in mehreren Tagen nicht gelungen, das erfolgreich zu ändern.
> Das ist wegen meiner Verwendungsart jedoch egal.
Deine Implementierung der Schieberegister ist trotzdem falsch; damit
hast du auf jeden Fall einen völlig anderen Algorithmus implementiert.
Kannst dir ja den Referenz-Code angucken, wenn du es nicht glaubst.
Witzigerweise scheint der die Testvektoren auch nicht reproduzieren zu
können. Kann aber auch daran liegen, das ich ihn nicht korrekt verwende.
Gruß,
Enrik
Helmut Schellong
Apr 10, 2022, 2:56:40 PM4/10/22
to
Ich habe bereits eine größere Anzahl kryptographischer Algorithmen implementiert.
Alle erzeugen die Referenz-Ergebnisse, nur dragon nicht - bis jetzt.
Das kann auch an einer ungenügenden Beschreibung liegen.
Enrik Berkhan
Apr 10, 2022, 3:13:05 PM4/10/22
to
Enrik Berkhan <Enrik....@inka.de> wrote:
> Helmut Schellong <r...@schellong.biz> wrote:
>> Der Algorithmus funktioniert.
>> Allerdings sind die Test-Ausgaben meiner Implementation
>> nicht gleich mit den Referenz-Ausgaben.
>> Es ist mir auch in mehreren Tagen nicht gelungen, das erfolgreich zu ändern.
>> Das ist wegen meiner Verwendungsart jedoch egal.
>
> Von mir aus kann dir das gerne egal sein.
>
> Deine Implementierung der Schieberegister ist trotzdem falsch; damit
> hast du auf jeden Fall einen völlig anderen Algorithmus implementiert.
>
> Kannst dir ja den Referenz-Code angucken, wenn du es nicht glaubst.
Danach solltest du die Testvektoren noch korrekt von der Hex-Darstellung
> Helmut Schellong <r...@schellong.biz> wrote:
>> Der Algorithmus funktioniert.
>> Allerdings sind die Test-Ausgaben meiner Implementation
>> nicht gleich mit den Referenz-Ausgaben.
>> Es ist mir auch in mehreren Tagen nicht gelungen, das erfolgreich zu ändern.
>> Das ist wegen meiner Verwendungsart jedoch egal.
>
> Von mir aus kann dir das gerne egal sein.
>
> Deine Implementierung der Schieberegister ist trotzdem falsch; damit
> hast du auf jeden Fall einen völlig anderen Algorithmus implementiert.
>
> Kannst dir ja den Referenz-Code angucken, wenn du es nicht glaubst.
in die interne wandeln, evtl. funktioniert es dann schon.
> Witzigerweise scheint der die Testvektoren auch nicht reproduzieren zu
> können. Kann aber auch daran liegen, das ich ihn nicht korrekt verwende.
blockweise funktioniert.
Meine Testimplementierung, die weitgehend der Struktur im von dir
genannten Paper folgt, funktioniert auch. War noch ein Tippfehler drin.
Gruß,
Enrik
Helmut Schellong
Apr 10, 2022, 4:33:16 PM4/10/22
to
On 04/10/2022 15:38, Enrik Berkhan wrote:
> Helmut Schellong <r...@schellong.biz> wrote:
>> Der Algorithmus funktioniert.
>> Allerdings sind die Test-Ausgaben meiner Implementation
>> nicht gleich mit den Referenz-Ausgaben.
>> Es ist mir auch in mehreren Tagen nicht gelungen, das erfolgreich zu ändern.
>> Das ist wegen meiner Verwendungsart jedoch egal.
>
> Von mir aus kann dir das gerne egal sein.
>
> Deine Implementierung der Schieberegister ist trotzdem falsch; damit
> hast du auf jeden Fall einen völlig anderen Algorithmus implementiert.
>
> Kannst dir ja den Referenz-Code angucken, wenn du es nicht glaubst.
7. Wi = Wi−1 , for i = 7 down to 1 (shifting the state by one word)
> Helmut Schellong <r...@schellong.biz> wrote:
>> Der Algorithmus funktioniert.
>> Allerdings sind die Test-Ausgaben meiner Implementation
>> nicht gleich mit den Referenz-Ausgaben.
>> Es ist mir auch in mehreren Tagen nicht gelungen, das erfolgreich zu ändern.
>> Das ist wegen meiner Verwendungsart jedoch egal.
>
> Von mir aus kann dir das gerne egal sein.
>
> Deine Implementierung der Schieberegister ist trotzdem falsch; damit
> hast du auf jeden Fall einen völlig anderen Algorithmus implementiert.
>
> Kannst dir ja den Referenz-Code angucken, wenn du es nicht glaubst.
4. B0 = b', B1 = c'
5. Bi = Bi−2 , 2 ≤ i ≤ 31
for (q= 7; q>0; --q) W[q][0]= W[q-1][0], W[q][1]= W[q-1][1];
B[0]= b; B[1]= c;
for (i=31; i>1; --i) B[i]= B[i-2];
Referenz-Vorgabe und meine Implementation:
Ich sehe hier keine falsche Implementation.
Von einem "völlig anderen Algorithmus" zu reden, ist eine heftige Übertreibung.
Ein tatsächlich völlig anderer Algorithmus ist beispielsweise der Rabbit-Algorithmus.
Solche Algorithmen erzeugen aufgrund einer Änderung eines einzigen Bits des KEY oder IV
einen vollkommen anderen Keystream.
Das gilt auch für jede winzige Änderung am Algorithmus.
Der Keystream ist _völlig_ anders - nicht jedoch der Algorithmus.
Algorithmen dieser Art (Strom-Cipher) sind durch mehrere typische Stufen aufgebaut.
Jede Stufe kann eine unterschiedliche Methode verwenden, um ihre Aufgabe zu erfüllen.
Beispielsweise eine kombinierte Addition+Multiplikation statt einer Sbox-Konstruktion.
Wenn alle Stufen die gleiche Methode verwenden, kann nicht von einem
"völlig anderen Algorithmus" geredet werden.
> Witzigerweise scheint der die Testvektoren auch nicht reproduzieren zu
> können. Kann aber auch daran liegen, das ich ihn nicht korrekt verwende.
>
>
Ich habe eine zip (18908 Byte), die u.a. dragon-opt.c dragon-ref.c dragon-sboxes.c
ecrypt-sync.c vectors.txt (128) enthält.
Dann eine Dragon.cs, also Csharp.
Helmut Schellong
Apr 10, 2022, 4:40:39 PM4/10/22
to
On 04/10/2022 21:07, Enrik Berkhan wrote:
> Enrik Berkhan <Enrik....@inka.de> wrote:
>> Helmut Schellong <r...@schellong.biz> wrote:
>>> Der Algorithmus funktioniert.
>>> Allerdings sind die Test-Ausgaben meiner Implementation
>>> nicht gleich mit den Referenz-Ausgaben.
>>> Es ist mir auch in mehreren Tagen nicht gelungen, das erfolgreich zu ändern.
>>> Das ist wegen meiner Verwendungsart jedoch egal.
>>
>> Von mir aus kann dir das gerne egal sein.
>>
>> Deine Implementierung der Schieberegister ist trotzdem falsch; damit
>> hast du auf jeden Fall einen völlig anderen Algorithmus implementiert.
>>
>> Kannst dir ja den Referenz-Code angucken, wenn du es nicht glaubst.
>
> Danach solltest du die Testvektoren noch korrekt von der Hex-Darstellung
> in die interne wandeln, evtl. funktioniert es dann schon.
In meinem Code ist es sichtbar, daß ich das mache. "fe" = 254 ...
> Enrik Berkhan <Enrik....@inka.de> wrote:
>> Helmut Schellong <r...@schellong.biz> wrote:
>>> Der Algorithmus funktioniert.
>>> Allerdings sind die Test-Ausgaben meiner Implementation
>>> nicht gleich mit den Referenz-Ausgaben.
>>> Es ist mir auch in mehreren Tagen nicht gelungen, das erfolgreich zu ändern.
>>> Das ist wegen meiner Verwendungsart jedoch egal.
>>
>> Von mir aus kann dir das gerne egal sein.
>>
>> Deine Implementierung der Schieberegister ist trotzdem falsch; damit
>> hast du auf jeden Fall einen völlig anderen Algorithmus implementiert.
>>
>> Kannst dir ja den Referenz-Code angucken, wenn du es nicht glaubst.
>
> Danach solltest du die Testvektoren noch korrekt von der Hex-Darstellung
> in die interne wandeln, evtl. funktioniert es dann schon.
>> Witzigerweise scheint der die Testvektoren auch nicht reproduzieren zu
>> können. Kann aber auch daran liegen, das ich ihn nicht korrekt verwende.
>
> Die Funktion, die den key stream byteweise liefert, ist kaputt. Die
> blockweise funktioniert.
In der pdf habe ich Erklärungen zu so etwas nicht gesehen.
Enrik Berkhan
Apr 10, 2022, 5:53:04 PM4/10/22
to
Helmut Schellong <r...@schellong.biz> wrote:
> On 04/10/2022 15:38, Enrik Berkhan wrote:
>> Kannst dir ja den Referenz-Code angucken, wenn du es nicht glaubst.
>
> 7. Wi = Wi−1 , for i = 7 down to 1 (shifting the state by one word)
> 4. B0 = b', B1 = c'
> 5. Bi = Bi−2 , 2 ≤ i ≤ 31
>
> for (q= 7; q>0; --q) W[q][0]= W[q-1][0], W[q][1]= W[q-1][1];
> B[0]= b; B[1]= c;
> for (i=31; i>1; --i) B[i]= B[i-2];
>
> Referenz-Vorgabe und meine Implementation:
> Ich sehe hier keine falsche Implementation.
Du musst die neuen B[0] und B[1] nach dem Schieben der anderen
> On 04/10/2022 15:38, Enrik Berkhan wrote:
>> Kannst dir ja den Referenz-Code angucken, wenn du es nicht glaubst.
>
> 7. Wi = Wi−1 , for i = 7 down to 1 (shifting the state by one word)
> 4. B0 = b', B1 = c'
> 5. Bi = Bi−2 , 2 ≤ i ≤ 31
>
> for (q= 7; q>0; --q) W[q][0]= W[q-1][0], W[q][1]= W[q-1][1];
> B[0]= b; B[1]= c;
> for (i=31; i>1; --i) B[i]= B[i-2];
>
> Referenz-Vorgabe und meine Implementation:
> Ich sehe hier keine falsche Implementation.
B[]-Elemente zuweisen. Du weißt, was ein Schieberegister ist?
Dass die Beschreibung im Paper, die du oben zitierst, zweifelhaft bis
mangelhaft ist, hatten wir ja schon festgestellt. Und dass die
Beschreibung _kein_ C-Code ist hast du evlt. schon gemerkt.
> Von einem "völlig anderen Algorithmus" zu reden, ist eine heftige Übertreibung.
> Ein tatsächlich völlig anderer Algorithmus ist beispielsweise der Rabbit-Algorithmus.
>
> Solche Algorithmen erzeugen aufgrund einer Änderung eines einzigen Bits des KEY oder IV
> einen vollkommen anderen Keystream.
> Das gilt auch für jede winzige Änderung am Algorithmus.
> Der Keystream ist _völlig_ anders - nicht jedoch der Algorithmus.
verwendet. Klar, das ist "fast" das gleiche.
> Man müßte definieren, was der Referenzcode überhaupt ist.
> Ich habe eine zip (18908 Byte), die u.a. dragon-opt.c dragon-ref.c dragon-sboxes.c
> ecrypt-sync.c vectors.txt (128) enthält.
> Dann eine Dragon.cs, also Csharp.
findet, entspricht dragon-ref.c, WIMRE.
C-Code müsstest du doch lesen können. Oder kannst du ihn nur schreiben?
Was key/iv betrifft: guck dir doch einfach mal im Debugger an, was da im
Speicher landet bei Deiner Implementierung.
Gruß,
Enrik
Bonita Montero
Apr 11, 2022, 2:24:29 AM4/11/22
to
> Du spinnst.
> Ich habe bereits eine größere Anzahl kryptographischer Algorithmen
> implementiert.
> Alle erzeugen die Referenz-Ergebnisse, nur dragon nicht - bis jetzt.
> Das kann auch an einer ungenügenden Beschreibung liegen.
Ne, das liegt an einem unfähigen Entwickler.
> Ich habe bereits eine größere Anzahl kryptographischer Algorithmen
> implementiert.
> Alle erzeugen die Referenz-Ergebnisse, nur dragon nicht - bis jetzt.
> Das kann auch an einer ungenügenden Beschreibung liegen.
Helmut Schellong
Apr 11, 2022, 6:38:09 AM4/11/22
to
On 04/10/2022 23:32, Enrik Berkhan wrote:
> Helmut Schellong <r...@schellong.biz> wrote:
>> On 04/10/2022 15:38, Enrik Berkhan wrote:
>>> Kannst dir ja den Referenz-Code angucken, wenn du es nicht glaubst.
>>
>> 7. Wi = Wi−1 , for i = 7 down to 1 (shifting the state by one word)
>> 4. B0 = b', B1 = c'
>> 5. Bi = Bi−2 , 2 ≤ i ≤ 31
>>
>> for (q= 7; q>0; --q) W[q][0]= W[q-1][0], W[q][1]= W[q-1][1];
>> B[0]= b; B[1]= c;
>> for (i=31; i>1; --i) B[i]= B[i-2];
>>
>> Referenz-Vorgabe und meine Implementation:
>> Ich sehe hier keine falsche Implementation.
>
> Du musst die neuen B[0] und B[1] nach dem Schieben der anderen
> B[]-Elemente zuweisen. Du weißt, was ein Schieberegister ist?
Das ergibt nur Sinn, wenn die Zeilen Table 2:6,7 und Table 3:4,5 gegeneinander austauscht werden.
> Helmut Schellong <r...@schellong.biz> wrote:
>> On 04/10/2022 15:38, Enrik Berkhan wrote:
>>> Kannst dir ja den Referenz-Code angucken, wenn du es nicht glaubst.
>>
>> 7. Wi = Wi−1 , for i = 7 down to 1 (shifting the state by one word)
>> 4. B0 = b', B1 = c'
>> 5. Bi = Bi−2 , 2 ≤ i ≤ 31
>>
>> for (q= 7; q>0; --q) W[q][0]= W[q-1][0], W[q][1]= W[q-1][1];
>> B[0]= b; B[1]= c;
>> for (i=31; i>1; --i) B[i]= B[i-2];
>>
>> Referenz-Vorgabe und meine Implementation:
>> Ich sehe hier keine falsche Implementation.
>
> Du musst die neuen B[0] und B[1] nach dem Schieben der anderen
> B[]-Elemente zuweisen. Du weißt, was ein Schieberegister ist?
Da sind folglich krasse Fehler in der Referenz-Dokumentation.
> Dass die Beschreibung im Paper, die du oben zitierst, zweifelhaft bis
> mangelhaft ist, hatten wir ja schon festgestellt. Und dass die
> Beschreibung _kein_ C-Code ist hast du evlt. schon gemerkt.
Das habe ich in diese NG als "Vorläufer-Posting" (09.04.) kopiert.
Ich war zu dem Zeitpunkt schon auf die Schiebeschleifen eingegangen, die
ich als auffällig kennzeichnete.
>> Von einem "völlig anderen Algorithmus" zu reden, ist eine heftige Übertreibung.
>> Ein tatsächlich völlig anderer Algorithmus ist beispielsweise der Rabbit-Algorithmus.
>>
>> Solche Algorithmen erzeugen aufgrund einer Änderung eines einzigen Bits des KEY oder IV
>> einen vollkommen anderen Keystream.
>> Das gilt auch für jede winzige Änderung am Algorithmus.
>> Der Keystream ist _völlig_ anders - nicht jedoch der Algorithmus.
>
> Du wirfst Daten weg, die der korrekt implementierte Algorithmus
> verwendet. Klar, das ist "fast" das gleiche.
>
>> Man müßte definieren, was der Referenzcode überhaupt ist.
>
> Das hat der Ecrypt-Wettbewerb uns schon vor Jahren abgenommen.
>
>> Ich habe eine zip (18908 Byte), die u.a. dragon-opt.c dragon-ref.c dragon-sboxes.c
>> ecrypt-sync.c vectors.txt (128) enthält.
>> Dann eine Dragon.cs, also Csharp.
>
> Genau, das ist der Referenzcode. Die C#-Version, die man auf github
> findet, entspricht dragon-ref.c, WIMRE.
>
> C-Code müsstest du doch lesen können. Oder kannst du ihn nur schreiben?
> Was key/iv betrifft: guck dir doch einfach mal im Debugger an, was da im
> Speicher landet bei Deiner Implementierung.
Daß dies jedoch bekannt sein muß.
Auch die entsprechende Zeile in der Referenz-Doku hatte ich als auffällig/unklar notiert.
>
>
Ich hatte den Referenzcode bisher nur überflogen und wegen gänzlich anderer Konzepte
zu den Akten gelegt.
Ich kann ihn aber nun verwenden, um Diskrepanzen mit der Referenz-Dokumentation zu entdecken.
Ein Makro U8TO32_BIG formt die Bytes des Key fortlaufend in ein 32bit-BigEndian-Format um.
Interessant - diese Information ist in der Referenz-Doku nicht enthalten.
Ein Makro U8TO32_LITTLE ist ebenfalls definiert, aber in der Referenz nicht verwendet.
Ich habe im ersten Schritt die Referenz-Dokumentation direkt in C umgesetzt.
Das ist durchaus einzeln, Zeile für Zeile möglich.
Die verwendete Pseudo-Programmiersprache ist überwiegend aus der Mathematik bekannt.
Auffälligkeiten habe ich bisher nicht als eindeutige Fehler eingestuft, sondern teilweise
angenommen, daß die so sein sollen, wie sie sind.
Helmut Schellong
Apr 11, 2022, 6:44:52 AM4/11/22
to
|Dass die Beschreibung im Paper, die du oben zitierst, zweifelhaft bis
|mangelhaft ist, hatten wir ja schon festgestellt.
Du strafst Dich Lügen.
|mangelhaft ist, hatten wir ja schon festgestellt.
Langeweile?
Enrik Berkhan
Apr 11, 2022, 9:13:05 AM4/11/22
to
Helmut Schellong <r...@schellong.biz> wrote:
> Ich hatte den Referenzcode bisher nur überflogen und wegen gänzlich anderer Konzepte
> zu den Akten gelegt.
Ich finde dort nur andere Implementierungsdetails, jedoch keine
> Ich hatte den Referenzcode bisher nur überflogen und wegen gänzlich anderer Konzepte
> zu den Akten gelegt.
"gänzlich anderen Konzepte" im Vergleich zu Deinem Code. Ach doch,
eines: der Referenz Code ist strukturiert. Aber auch das ist nur
Formsache.
> Ich kann ihn aber nun verwenden, um Diskrepanzen mit der Referenz-Dokumentation zu entdecken.
Helmut Schellong
Apr 11, 2022, 10:42:23 AM4/11/22
to
On 04/11/2022 15:08, Enrik Berkhan wrote:
> Helmut Schellong <r...@schellong.biz> wrote:
>> Ich hatte den Referenzcode bisher nur überflogen und wegen gänzlich anderer Konzepte
>> zu den Akten gelegt.
>
> Ich finde dort nur andere Implementierungsdetails, jedoch keine
> "gänzlich anderen Konzepte" im Vergleich zu Deinem Code. Ach doch,
> eines: der Referenz Code ist strukturiert. Aber auch das ist nur
> Formsache.
>
Strukturierung wäre bei mir Unfug, weil ich eine festgelegte Verwendung
> Helmut Schellong <r...@schellong.biz> wrote:
>> Ich hatte den Referenzcode bisher nur überflogen und wegen gänzlich anderer Konzepte
>> zu den Akten gelegt.
>
> Ich finde dort nur andere Implementierungsdetails, jedoch keine
> "gänzlich anderen Konzepte" im Vergleich zu Deinem Code. Ach doch,
> eines: der Referenz Code ist strukturiert. Aber auch das ist nur
> Formsache.
>
als Kommando habe: dragon key iv infile outfile
Der Referenzcode ist etwa 5-fach größer als meiner, trotz etwa
gleichem binären Ergebnis.
Ich wüßte nicht, warum ich dermaßen extrem bloaten und makroisieren sollte.
Die Konzepte sind vollkommen anders.
Wenn Du das anders siehst, müssen wir das Wort 'Konzepte' definieren, hier angewandt.
W0 || ... || W7 = K || K ^ IV || ~(K ^ IV) || IV
1024 bit 256 256 256 256 bit
Die vorstehende Aufgabe wurde stark abweichend gelöst:
'W' besteht aus 32 x 32bit-Objekten. (Bei mir aus 8 x 128bit-Objekten)
Es werden in einer Funktion (keysetup) die Daten aus einem Key (uchar) in eine 32bit-Variable
umgewandelt, in BigEndian verändert und so in drei Positionen des Schieberegisters geschrieben.
Es wird nur 'K' behandelt, keine Verknüpfung vorgenommen - die vierte Position enthält kein 'K'.
In einer weiteren Funktion wird nur IV behandelt, in den letzten drei Positionen, und
ebenso direkt in das Schieberegister geschrieben (je 32 bit).
Dabei werden nun die noch fehlenden Verknüpfungen XOR und INV mit den entsprechenden
Positionen im Schieberegister nachgeholt.
In dieser Funktion (ivsetup) sind große weitere Teile des Algorithmus eingefügt.
Der Referenzcode schiebt das Schieberegister nicht, sondern unterhält ein Offset-Objekt,
das stets die aktuelle Position 0 im Schieberegister anzeigt.
Wie habe ich die Aufgabe gelöst?
Ich verknüpfe und kopiere die Inhalte K und IV in das Schieberegister W.
Wie in der Referenz-Doku angezeigt.
Das ist alles.
8 Zeilen statt mehrere 100!
Und ich finde dies wirklich konzeptionell _total_ anders als im Referenzcode!
Auch alle weiteren Algorithmus-Teile sind im Referenzcode total anders gelöst:
keystream_blocks(), process_blocks(), keystream_bytes(), process_bytes(), ...
Damit kann ich konzeptionell nichts anfangen!
Paßt gar nicht zu meinem Kommando-Konzept!
Enrik Berkhan
Apr 11, 2022, 1:33:06 PM4/11/22
to
Helmut Schellong <r...@schellong.biz> wrote:
> Strukturierung wäre bei mir Unfug, weil ich eine festgelegte Verwendung
Strukturierung fängt mit lesbarem Quelltext an. Deine Quelltexte lesen
> Strukturierung wäre bei mir Unfug, weil ich eine festgelegte Verwendung
sich immer, als müsstest du whitespace durch Amputation von Körperteilen
bezahlen oder so etwas in der Art.
> als Kommando habe: dragon key iv infile outfile
> Der Referenzcode ist etwa 5-fach größer als meiner, trotz etwa
> gleichem binären Ergebnis.
> Ich wüßte nicht, warum ich dermaßen extrem bloaten und makroisieren sollte.
> Die Konzepte sind vollkommen anders.
Verknüpfungsfunktion, die aus dessen Inhalt Werte ermittelt, um diese
am Eingang hineinzufüttern. Der Ausgang wird verworfen. Nicht so
ungewöhnlich im gegebenen Kontext.
Diese Konzepte werden für die Initialisierung und die
Schlüsselstromgenerierung mit leicht verschiedenen Parametern verwendet.
> Wenn Du das anders siehst, müssen wir das Wort 'Konzepte' definieren, hier angewandt.
> W0 || ... || W7 = K || K ^ IV || ~(K ^ IV) || IV
> 1024 bit 256 256 256 256 bit
>
> Die vorstehende Aufgabe wurde stark abweichend gelöst:
> 'W' besteht aus 32 x 32bit-Objekten. (Bei mir aus 8 x 128bit-Objekten)
> Es werden in einer Funktion (keysetup) die Daten aus einem Key (uchar) in eine 32bit-Variable
> umgewandelt, in BigEndian verändert und so in drei Positionen des Schieberegisters geschrieben.
> Es wird nur 'K' behandelt, keine Verknüpfung vorgenommen - die vierte Position enthält kein 'K'.
>
> In einer weiteren Funktion wird nur IV behandelt, in den letzten drei Positionen, und
> ebenso direkt in das Schieberegister geschrieben (je 32 bit).
> Dabei werden nun die noch fehlenden Verknüpfungen XOR und INV mit den entsprechenden
> Positionen im Schieberegister nachgeholt.
> In dieser Funktion (ivsetup) sind große weitere Teile des Algorithmus eingefügt.
der Aufgabenstellung des ECRYPT-Wettbewerbs. Das geforderte Interface
bedingt diese Aufteilung. Das steht auch in den Code-Kommentaren. (Ein
Code-Kommentar ist, wenn man im Quelltext z.B. bei einer Funktion
dazuschreibt, was sie so im groben tut und warum, etc.)
keysetup und ivsetup nacheinander ausgeführt führen zum gleichen
Ergebnis wie in der Spezifikation.
Implementierungsdetail.
Den Key, der im ECRYPT-Interface als bytefolge eingegeben wird, korrekt
in die interne Darstellung zu bekommen ist ebenfalls ein
Implementierungsdetail, wenn auch tatsächlich nicht in der Spezifikation
erwähnt. (Allerdings sind die Keys in der Spezifikation als 32bit Werte
angegeben.)
> Der Referenzcode schiebt das Schieberegister nicht, sondern unterhält ein Offset-Objekt,
> das stets die aktuelle Position 0 im Schieberegister anzeigt.
weil weniger kopiert werden muss. Dafür ist dann der Zugriff minimal
unhandlicher.
> Wie habe ich die Aufgabe gelöst?
Gruß,
Enrik
Enrik Berkhan
Apr 11, 2022, 2:33:05 PM4/11/22
to
Helmut Schellong <r...@schellong.biz> wrote:
> On 04/10/2022 21:07, Enrik Berkhan wrote:
>> Danach solltest du die Testvektoren noch korrekt von der Hex-Darstellung
>> in die interne wandeln, evtl. funktioniert es dann schon.
>
> In meinem Code ist es sichtbar, daß ich das mache. "fe" = 254 ...
Und so sieht das dann aus:
> On 04/10/2022 21:07, Enrik Berkhan wrote:
>> Danach solltest du die Testvektoren noch korrekt von der Hex-Darstellung
>> in die interne wandeln, evtl. funktioniert es dann schon.
>
> In meinem Code ist es sichtbar, daß ich das mache. "fe" = 254 ...
$ make -B
cc -g -O0 -DDRAGON_TEST=1 -c -o dragon.o dragon.c
cc dragon.o -o dragon
$ gdb dragon
[...]
Reading symbols from dragon...
(gdb) break 92
Breakpoint 1 at 0x178b: file dragon.c, line 98.
(gdb) run
Starting program: /home/enrik/Documents/src/dragon/schellong/dragon
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, dragon (C=5, A=0x5555555590a0 <argv>) at dragon.c:98
98 W[0][0]= K[0], W[0][1]= K[1];
(gdb) p/x K
$1 = {0x33332222, 0x77776666, 0xffffffffffffffaa, 0xffffffffffffffee}
Ist das der Inhalt, den du für einen key mit dem Wert
"0000111122223333444455556666777788889999AAAABBBBCCCCDDDDEEEEFFFF"
erwartest?
Gruß,
Enrik
Helmut Schellong
Apr 11, 2022, 3:00:18 PM4/11/22
to
On 04/11/2022 19:12, Enrik Berkhan wrote:
> Helmut Schellong <r...@schellong.biz> wrote:
>> Strukturierung wäre bei mir Unfug, weil ich eine festgelegte Verwendung
>
> Strukturierung fängt mit lesbarem Quelltext an. Deine Quelltexte lesen
> sich immer, als müsstest du whitespace durch Amputation von Körperteilen
> bezahlen oder so etwas in der Art.
>
>> als Kommando habe: dragon key iv infile outfile
>> Der Referenzcode ist etwa 5-fach größer als meiner, trotz etwa
>> gleichem binären Ergebnis.
>
> Trotzdem um Größenordnungen lesbarer und wartbarer.
Das ist allerdings irrelevant.
> Helmut Schellong <r...@schellong.biz> wrote:
>> Strukturierung wäre bei mir Unfug, weil ich eine festgelegte Verwendung
>
> Strukturierung fängt mit lesbarem Quelltext an. Deine Quelltexte lesen
> sich immer, als müsstest du whitespace durch Amputation von Körperteilen
> bezahlen oder so etwas in der Art.
>
>> als Kommando habe: dragon key iv infile outfile
>> Der Referenzcode ist etwa 5-fach größer als meiner, trotz etwa
>> gleichem binären Ergebnis.
>
> Trotzdem um Größenordnungen lesbarer und wartbarer.
Nur ich bearbeite und warte meinen Code, womit ich keine Probleme habe - im Gegenteil.
Und veröffentlichter Code von mir macht vielleicht 0,01% aus.
Es ist Privat-Code.
>> Ich wüßte nicht, warum ich dermaßen extrem bloaten und makroisieren sollte.
>
> Na darum, s. letzter Absatz.
Das wäre Quatsch, weil die sich seit 2005 nicht änderten und dies auch
in Zukunft nicht passieren wird.
>> Die Konzepte sind vollkommen anders.
>
> Die Kernkonzepte sind ein 1024bit langes Schieberegister und eine
> Verknüpfungsfunktion, die aus dessen Inhalt Werte ermittelt, um diese
> am Eingang hineinzufüttern. Der Ausgang wird verworfen. Nicht so
> ungewöhnlich im gegebenen Kontext.
>
> Diese Konzepte werden für die Initialisierung und die
> Schlüsselstromgenerierung mit leicht verschiedenen Parametern verwendet.
>
>> Wenn Du das anders siehst, müssen wir das Wort 'Konzepte' definieren, hier angewandt.
>> W0 || ... || W7 = K || K ^ IV || ~(K ^ IV) || IV
>> 1024 bit 256 256 256 256 bit
>>
>> Die vorstehende Aufgabe wurde stark abweichend gelöst:
>> 'W' besteht aus 32 x 32bit-Objekten. (Bei mir aus 8 x 128bit-Objekten)
>
> Implementierungsdetail.
>> Es werden in einer Funktion (keysetup) die Daten aus einem Key (uchar) in eine 32bit-Variable
>> umgewandelt, in BigEndian verändert und so in drei Positionen des Schieberegisters geschrieben.
>> Es wird nur 'K' behandelt, keine Verknüpfung vorgenommen - die vierte Position enthält kein 'K'.
>>
>> In einer weiteren Funktion wird nur IV behandelt, in den letzten drei Positionen, und
>> ebenso direkt in das Schieberegister geschrieben (je 32 bit).
>> Dabei werden nun die noch fehlenden Verknüpfungen XOR und INV mit den entsprechenden
>> Positionen im Schieberegister nachgeholt.
>> In dieser Funktion (ivsetup) sind große weitere Teile des Algorithmus eingefügt.
>
> Die Aufteilung auf keysetup und ivsetup resultiert im wesentlichen aus
> der Aufgabenstellung des ECRYPT-Wettbewerbs. Das geforderte Interface
> bedingt diese Aufteilung. Das steht auch in den Code-Kommentaren. (Ein
> Code-Kommentar ist, wenn man im Quelltext z.B. bei einer Funktion
> dazuschreibt, was sie so im groben tut und warum, etc.)
> keysetup und ivsetup nacheinander ausgeführt führen zum gleichen
> Ergebnis wie in der Spezifikation.
> Implementierungsdetail.
Sehe ich halt ganz anders.
Die zu lösende Aufgabe wurde mit gänzlich anderen Mitteln, Konzepten und
Ausformulierungen bewältigt.
Für Dich scheint 'Konzept' eine ganz andere Semantik zu haben, als für mich!
> Den Key, der im ECRYPT-Interface als bytefolge eingegeben wird, korrekt
> in die interne Darstellung zu bekommen ist ebenfalls ein
> Implementierungsdetail, wenn auch tatsächlich nicht in der Spezifikation
> erwähnt. (Allerdings sind die Keys in der Spezifikation als 32bit Werte
> angegeben.)
>
>> Der Referenzcode schiebt das Schieberegister nicht, sondern unterhält ein Offset-Objekt,
>> das stets die aktuelle Position 0 im Schieberegister anzeigt.
>
> Implementierungsdetail. Die Index-Lösung ist vermutlich effizienter,
> weil weniger kopiert werden muss. Dafür ist dann der Zugriff minimal
> unhandlicher.
>> Wie habe ich die Aufgabe gelöst?
>
> Bisher gar nicht, oder kommen inzwischen die korrekten Werte heraus?
>
>
Es geht hier um die Quellcode-Formulierung, nicht um Runtime-Resultate.
Helmut Schellong
Apr 11, 2022, 3:56:38 PM4/11/22
to
K[nb/2]|= b<<8*(nb%2); Rabbit
P[nb/8]|= (uint64_t)m<<8*(nb%8); Dragon
..........^^^^^^^^^^
Der cast fehlte. Bei Rabbit ist der nicht nötig, weil die int-Promotion reicht (32 bit).
Nun: 3333222211110000 7777666655554444 BBBBAAAA99998888 FFFFEEEEDDDDCCCC
Enrik Berkhan
Apr 11, 2022, 4:33:06 PM4/11/22
to
Helmut Schellong <r...@schellong.biz> wrote:
> On 04/11/2022 19:12, Enrik Berkhan wrote:
>> Bisher gar nicht, oder kommen inzwischen die korrekten Werte heraus?
>
> Darum geht es aber gar nicht bei dieser Konzeptfrage!
> Es geht hier um die Quellcode-Formulierung, nicht um Runtime-Resultate.
Hier sind die Fixes für Deine Quellcode-Formulierung. Bei ist der Test
> On 04/11/2022 19:12, Enrik Berkhan wrote:
>> Bisher gar nicht, oder kommen inzwischen die korrekten Werte heraus?
>
> Darum geht es aber gar nicht bei dieser Konzeptfrage!
> Es geht hier um die Quellcode-Formulierung, nicht um Runtime-Resultate.
damit - zumindest auf den ersten Blick - erfolgreich durchgelaufen:
commit 290bd21f98badbe535652fa27c7fcd7a7f49fe0c (HEAD -> main)
Author: Enrik Berkhan <Enrik....@inka.de>
Date: Mon Apr 11 22:23:34 2022 +0200
Fix key output byte order
diff --git a/dragon.c b/dragon.c
index 23be0d4..41a6673 100644
--- a/dragon.c
+++ b/dragon.c
@@ -123,7 +123,7 @@ static int dragon(int C, char *A[])
k= (uint64_t)a<<32 | e;
if (DRAGON_TEST>0) {
if (wr-->0) {
- for (i=0; i<8; ++i) printf("%02hhX", (byte)(k>>8*i));
+ for (i=0; i<8; ++i) printf("%02hhX", (byte)(k>>8*(7-i)));
printf(wr%4==0?"\n":" "); continue;
}
else return 0;
commit e06e44dd7535e5952d7eec6fba1e68a13b99f23d
Author: Enrik Berkhan <Enrik....@inka.de>
Date: Mon Apr 11 22:22:02 2022 +0200
Fix shifting during key stream generation
diff --git a/dragon.c b/dragon.c
index ba9b613..23be0d4 100644
--- a/dragon.c
+++ b/dragon.c
@@ -117,8 +117,8 @@ static int dragon(int C, char *A[])
while (1) { uint64_t k, buf[2*1024];
a= B[0]; b= B[9]; c= B[16]; d= B[19]; e= B[30]^M>>32; f= B[31]^M;
UPDATE_F();
- B[0]= b; B[1]= c;
for (i=31; i>1; --i) B[i]= B[i-2];
+ B[0]= b; B[1]= c;
M+= 1;
k= (uint64_t)a<<32 | e;
if (DRAGON_TEST>0) {
commit 0366613a12f590699d2686dcf4f5dfae33f4577f
Author: Enrik Berkhan <Enrik....@inka.de>
Date: Mon Apr 11 22:13:38 2022 +0200
Fix W -> B copy
diff --git a/dragon.c b/dragon.c
index e1b1ecd..ba9b613 100644
--- a/dragon.c
+++ b/dragon.c
@@ -112,7 +112,7 @@ static int dragon(int C, char *A[])
W[0][1]= ((uint64_t)c<<32|d) ^ W[5][1];
M= (uint64_t)e<<32 | f;
}
- for (i=0; i<32; i+=2) q= ((uint64_t*)W)[i/2], B[i]= q, B[i+1]= q>>32;
+ for (i=0; i<8; i+=1) B[4*i]= W[i][0]>>32, B[4*i+1]= W[i][0], B[4*i+2] = W[i][1]>>32, B[4*i+3] = W[i][1];
int nb=0, nk=0, wr=16;
while (1) { uint64_t k, buf[2*1024];
a= B[0]; b= B[9]; c= B[16]; d= B[19]; e= B[30]^M>>32; f= B[31]^M;
commit 5e4bb1243f29183ca8d8f3aaf3d3e626c0204d73
Author: Enrik Berkhan <Enrik....@inka.de>
Date: Mon Apr 11 22:12:17 2022 +0200
Fix shifting during initialization
diff --git a/dragon.c b/dragon.c
index c2df8b3..e1b1ecd 100644
--- a/dragon.c
+++ b/dragon.c
@@ -107,9 +107,9 @@ static int dragon(int C, char *A[])
q= W[0][1]^W[6][1]^W[7][1]; c= q>>32, d= q;
e= M>>32, f= M;
UPDATE_F();
- W[0][0]= ((uint64_t)c<<32|d) ^ W[4][0];
- W[0][1]= ((uint64_t)a<<32|b) ^ W[4][1];
for (q=7; q>0; --q) W[q][0]= W[q-1][0], W[q][1]= W[q-1][1];
+ W[0][0]= ((uint64_t)a<<32|b) ^ W[5][0];
+ W[0][1]= ((uint64_t)c<<32|d) ^ W[5][1];
M= (uint64_t)e<<32 | f;
}
for (i=0; i<32; i+=2) q= ((uint64_t*)W)[i/2], B[i]= q, B[i+1]= q>>32;
commit f3cf6ee3801b58c5f2858637b50065d760d206cd
Author: Enrik Berkhan <Enrik....@inka.de>
Date: Mon Apr 11 22:11:15 2022 +0200
Fix W -> a,b,c,d mapping
diff --git a/dragon.c b/dragon.c
index 6d1be57..c2df8b3 100644
--- a/dragon.c
+++ b/dragon.c
@@ -103,8 +103,8 @@ static int dragon(int C, char *A[])
W[7][0]= I[2], W[7][1]= I[3];
M= 0x447261676F6Eull;
for (i=0; i<16; ++i) {
- q= W[0][0]^W[6][0]^W[7][0]; c= q>>32, d= q;
- q= W[0][1]^W[6][1]^W[7][1]; a= q>>32, b= q;
+ q= W[0][0]^W[6][0]^W[7][0]; a= q>>32, b= q;
+ q= W[0][1]^W[6][1]^W[7][1]; c= q>>32, d= q;
e= M>>32, f= M;
UPDATE_F();
W[0][0]= ((uint64_t)c<<32|d) ^ W[4][0];
commit 83ae91be87e0e860afa638f5ba8bb39e5e5551c7
Author: Enrik Berkhan <Enrik....@inka.de>
Date: Mon Apr 11 22:09:39 2022 +0200
Fix UPDATE()
diff --git a/dragon.c b/dragon.c
index f4f3492..6d1be57 100644
--- a/dragon.c
+++ b/dragon.c
@@ -40,9 +40,7 @@ static void noret dragE(const char *es, int e)
a^= S2[b>>24&255] ^ S2[b>>16&255] ^ S2[b>>8&255] ^ S1[b&255]; \
c^= S2[d>>24&255] ^ S2[d>>16&255] ^ S1[d>>8&255] ^ S2[d&255]; \
e^= S2[f>>24&255] ^ S1[f>>16&255] ^ S2[f>>8&255] ^ S2[f&255]; \
- d+=a, f+=c, b+=e; c^=b, e^=d, a^=f; \
- d= d<<16|d>>16, f= f<<16|f>>16, b= b<<16|b>>16; \
- c= c<<16|c>>16, e= e<<16|e>>16, a= a<<16|a>>16;
+ d+=a, f+=c, b+=e; c^=b, e^=d, a^=f;
static uint32_t const S1[], S2[];
commit 0c209f698f2ef9168e15798711aa2d1df555b4b7
Author: Enrik Berkhan <Enrik....@inka.de>
Date: Mon Apr 11 21:35:38 2022 +0200
Fix key/iv byte order
diff --git a/dragon.c b/dragon.c
index 3763279..f4f3492 100644
--- a/dragon.c
+++ b/dragon.c
@@ -82,7 +82,7 @@ static int dragon(int C, char *A[])
for (nb=i=0; i<64; nb+=i&1,++i) {
h= Chex[ap[i]]-1;
if (!(i&1)) m =h, m<<=4;
- else m|=h, P[nb/8]|= (uint64_t)m<<8*(nb%8);
+ else m|=h, P[nb/8]|= (uint64_t)m<<8*((31-nb)%8);
}
break;
case 32: for (i=0; i<32; ++i) P[i/8]|= ap[i]<<8*(i%8);
commit 177b795c005c1b7d5bfabedcd80fe07e5684dc20
Author: Enrik Berkhan <Enrik....@inka.de>
Date: Mon Apr 11 20:55:17 2022 +0200
Fix key/iv initialization from hex string.
diff --git a/dragon.c b/dragon.c
index 4ed7133..3763279 100644
--- a/dragon.c
+++ b/dragon.c
@@ -71,7 +71,7 @@ static int dragon(int C, char *A[])
if (!pass&&DRAGON_TEST==0) return 0;
if (C!=5) dragE(args, 1);
for (i=0; i<4; ++i) K[i]=I[i]= 0;
- for (p=1; p<3; ++p) { char *ap, h, m; uint64_t *P; unsigned nb;
+ for (p=1; p<3; ++p) { char *ap, h; unsigned m; uint64_t *P; unsigned nb;
ap= A[p]; P= p==1 ? K : I;
for (h=1,i=0; i<256+1&&ap[i]; ++i) if (!Chex[ap[i]]) h=0;
switch (i) {
@@ -82,7 +82,7 @@ static int dragon(int C, char *A[])
for (nb=i=0; i<64; nb+=i&1,++i) {
h= Chex[ap[i]]-1;
if (!(i&1)) m =h, m<<=4;
- else m|=h, P[nb/8]|= m<<8*(nb%8);
+ else m|=h, P[nb/8]|= (uint64_t)m<<8*(nb%8);
}
break;
case 32: for (i=0; i<32; ++i) P[i/8]|= ap[i]<<8*(i%8);
Helmut Schellong
Apr 12, 2022, 5:15:16 AM4/12/22
to
On 04/11/2022 22:31, Enrik Berkhan wrote:
> Helmut Schellong <r...@schellong.biz> wrote:
>> On 04/11/2022 19:12, Enrik Berkhan wrote:
>>> Bisher gar nicht, oder kommen inzwischen die korrekten Werte heraus?
>>
>> Darum geht es aber gar nicht bei dieser Konzeptfrage!
>> Es geht hier um die Quellcode-Formulierung, nicht um Runtime-Resultate.
>
> Hier sind die Fixes für Deine Quellcode-Formulierung. Bei ist der Test
> damit - zumindest auf den ersten Blick - erfolgreich durchgelaufen:
>
> Danke für die Mühe.
> Helmut Schellong <r...@schellong.biz> wrote:
>> On 04/11/2022 19:12, Enrik Berkhan wrote:
>>> Bisher gar nicht, oder kommen inzwischen die korrekten Werte heraus?
>>
>> Darum geht es aber gar nicht bei dieser Konzeptfrage!
>> Es geht hier um die Quellcode-Formulierung, nicht um Runtime-Resultate.
>
> Hier sind die Fixes für Deine Quellcode-Formulierung. Bei ist der Test
> damit - zumindest auf den ersten Blick - erfolgreich durchgelaufen:
>
Allerdings hat mein Keystream keine Ähnlichkeit.
Referenz-Testvektoren:
----------------------
KEY:
00001111 22223333 44445555 66667777 88889999 AAAABBBB CCCCDDDD EEEEFFFF
IV:
00001111 22223333 44445555 66667777 88889999 AAAABBBB CCCCDDDD EEEEFFFF
KEYSTREAM:
BC020767 DC48DAE3 14778D8C 927E8B32 E086C6CD E593C008 600C9D47 A488F622
3A2B94D6 B853D644 27E93362 ABB8BA21 751CAAF7 BD316595 2A37FC1E A3F12FE2
5C133BA7 4C15CE4B 3542FDF8 93DAA751 F5710256 49795D54 31914EBA 0DE2C2A7
8013D29B 56D4A028 3EB6F312 7644ECFE 38B9CA11 1924FBC9 4A0A30F2 AFFF5FE0
Meine Ausgabe:
--------------
44F8C4A8CBB9D7A2 366EA3EC1BEE1ADC 113BEE0CCCC4C202 EFA8C45CB46B9ECF
E009F761D8AA0AC9 849791D9E06A089F C42B09D1C2872486 28E780EDD0459B5B
0B95FB96DE6B863C D654A3F7BACDB261 AC3131AFFAA438C7 C3932211132A29E3
023FCAFF7D2CE209 49CDA7C61D15B60F 0970E082F6F17FA5 7FB4EA2C1C5BCDDE
Mit "uchar m" und (31-nb).
"unsigned m" macht keinen Unterschied.
.................BC020767 DC48DAE3
Wenn es so wäre: E3DA48DC 670702BC, mit Verdrehungen, wäre es in Ordnung - is aber nicht.
Wenn Byte "BC" oben gar nicht enthalten ist, paßt es nicht.
Infos:
Meine Zeile:
for (i=0; i<32; i+=2) q= ((uint64_t*)W)[i/2], B[i]= q, B[i+1]= q>>32;
entspricht übrigens memcpy(B, W, sizeof(B));
Ich verwende stets -funsigned-char.
In meiner bish prüfe ich CHAR_MAX auf 256.
Dadurch kann ich 'char' verwenden (#define byte char).
Helmut Schellong
Apr 12, 2022, 6:52:51 AM4/12/22
to
On 04/11/2022 19:12, Enrik Berkhan wrote:
> Helmut Schellong <r...@schellong.biz> wrote:
>> Strukturierung wäre bei mir Unfug, weil ich eine festgelegte Verwendung
>
[...]
>> Strukturierung wäre bei mir Unfug, weil ich eine festgelegte Verwendung
>
> Den Key, der im ECRYPT-Interface als bytefolge eingegeben wird, korrekt
> in die interne Darstellung zu bekommen ist ebenfalls ein
> Implementierungsdetail, wenn auch tatsächlich nicht in der Spezifikation
> erwähnt. (Allerdings sind die Keys in der Spezifikation als 32bit Werte
> angegeben.)
>
>
Wo sind die Keys als 32bit-Werte angegeben?
> in die interne Darstellung zu bekommen ist ebenfalls ein
> Implementierungsdetail, wenn auch tatsächlich nicht in der Spezifikation
> erwähnt. (Allerdings sind die Keys in der Spezifikation als 32bit Werte
> angegeben.)
>
>
Ich sehe da nichts.
Da tauchen irgendwann die Objekte K und IV auf, und absolut gar nichts
wird darüber _beschrieben_.
Es wird eingangs definiert, daß key und iv je 128 oder je 256 Bit lang sind.
Im Rabbit u.a.:
The state and counter words are derived from the key K[127..0].
The key is divided into subkeys K0 = K[15..0], K1 = K[31..16], ... K7 = K[127..112].
The initial state is initialized as follows: ...
C1 = C1 ^ (IV[63..48] || IV[31..16])
Solche Definitionen findet man zu Dragon gar nicht.
Deshalb habe ich auch Rabbit auf Anhieb passend zu dessen Testvektoren implementieren können.
Dragon jedoch bisher nicht.
Enrik Berkhan
Apr 12, 2022, 7:13:05 AM4/12/22
to
Helmut Schellong <r...@schellong.biz> wrote:
> Danke für die Mühe.
> Allerdings hat mein Keystream keine Ähnlichkeit.
>
> [...]
> Danke für die Mühe.
> Allerdings hat mein Keystream keine Ähnlichkeit.
>
>
> Mit "uchar m" und (31-nb).
> "unsigned m" macht keinen Unterschied.
>
> .................BC020767 DC48DAE3
> Wenn es so wäre: E3DA48DC 670702BC, mit Verdrehungen, wäre es in Ordnung - is aber nicht.
> Wenn Byte "BC" oben gar nicht enthalten ist, paßt es nicht.
>
> Infos:
>
> Meine Zeile:
> for (i=0; i<32; i+=2) q= ((uint64_t*)W)[i/2], B[i]= q, B[i+1]= q>>32;
> entspricht übrigens memcpy(B, W, sizeof(B));
>
> Ich verwende stets -funsigned-char.
> In meiner bish prüfe ich CHAR_MAX auf 256.
> Dadurch kann ich 'char' verwenden (#define byte char).
Bei mir geht's, auch mit -m32, auch mit -funsigned-char. Allerdings habe
> Mit "uchar m" und (31-nb).
> "unsigned m" macht keinen Unterschied.
>
> .................BC020767 DC48DAE3
> Wenn es so wäre: E3DA48DC 670702BC, mit Verdrehungen, wäre es in Ordnung - is aber nicht.
> Wenn Byte "BC" oben gar nicht enthalten ist, paßt es nicht.
>
> Infos:
>
> Meine Zeile:
> for (i=0; i<32; i+=2) q= ((uint64_t*)W)[i/2], B[i]= q, B[i+1]= q>>32;
> entspricht übrigens memcpy(B, W, sizeof(B));
>
> Ich verwende stets -funsigned-char.
> In meiner bish prüfe ich CHAR_MAX auf 256.
> Dadurch kann ich 'char' verwenden (#define byte char).
ich dir ja nur meine Änderungen geschickt. Evtl. hast du ja noch andere
Änderungen im Ausgangscode gehabt. Ich hatte deine Originalquelle gestern
abend noch einmal frisch heruntergeladen, für einen "sauberen" Start.
Soll ich dir den Gesamtstand auf github pushen?
Gruß,
Enrik
Enrik Berkhan
Apr 12, 2022, 8:13:06 AM4/12/22
to
OK, nicht sehr explizit. Ich habe die Gruppierung so gelesen:
KEY:
00001111 22223333 44445555 66667777 88889999 AAAABBBB CCCCDDDD EEEEFFFF
IV:
00001111 22223333 44445555 66667777 88889999 AAAABBBB CCCCDDDD EEEEFFFF
KEYSTREAM:
BC020767 DC48DAE3 14778D8C 927E8B32 E086C6CD E593C008 600C9D47 A488F622
3A2B94D6 B853D644 27E93362 ABB8BA21 751CAAF7 BD316595 2A37FC1E A3F12FE2
5C133BA7 4C15CE4B 3542FDF8 93DAA751 F5710256 49795D54 31914EBA 0DE2C2A7
8013D29B 56D4A028 3EB6F312 7644ECFE 38B9CA11 1924FBC9 4A0A30F2 AFFF5FE0
Generell werden im Paper alle Zahlen von "links nach rechts" mit
aufsteigenden Indizes 0.. angegeben.
Wenn man den Key als 256bit-Wert (so ist er spezifiziert) in diesem
Kontext ("links nach rechts") liest, dann muss eben nach dem wie auch
immer gearteten Einlesen in einer gedachten 256bit-Variablen die Zahl
0x0000111122223333444455556666777788889999AAAABBBBCCCCDDDDEEEEFFFF
stehen.
Wenn man das als Byte-addressierten Speicherinhalt ab Adresse 0
betrachtet, dann ist es (wieder, "von links nach rechts", ab 0 bis ..),
so:
0 1 2 3 4 5 6 7 ...
00 00 11 11 22 22 33 33 ...
"big endian"
Gruß,
Enrik
KEY:
00001111 22223333 44445555 66667777 88889999 AAAABBBB CCCCDDDD EEEEFFFF
IV:
00001111 22223333 44445555 66667777 88889999 AAAABBBB CCCCDDDD EEEEFFFF
KEYSTREAM:
BC020767 DC48DAE3 14778D8C 927E8B32 E086C6CD E593C008 600C9D47 A488F622
3A2B94D6 B853D644 27E93362 ABB8BA21 751CAAF7 BD316595 2A37FC1E A3F12FE2
5C133BA7 4C15CE4B 3542FDF8 93DAA751 F5710256 49795D54 31914EBA 0DE2C2A7
8013D29B 56D4A028 3EB6F312 7644ECFE 38B9CA11 1924FBC9 4A0A30F2 AFFF5FE0
aufsteigenden Indizes 0.. angegeben.
Wenn man den Key als 256bit-Wert (so ist er spezifiziert) in diesem
Kontext ("links nach rechts") liest, dann muss eben nach dem wie auch
immer gearteten Einlesen in einer gedachten 256bit-Variablen die Zahl
0x0000111122223333444455556666777788889999AAAABBBBCCCCDDDDEEEEFFFF
stehen.
Wenn man das als Byte-addressierten Speicherinhalt ab Adresse 0
betrachtet, dann ist es (wieder, "von links nach rechts", ab 0 bis ..),
so:
0 1 2 3 4 5 6 7 ...
00 00 11 11 22 22 33 33 ...
"big endian"
Gruß,
Enrik
Helmut Schellong
Apr 12, 2022, 8:21:55 AM4/12/22
to
[...]
Dann der Reihe nach die diff-Ausgaben eingepflegt.
Wir müßten identische Quellen haben.
Inzwischen habe ich den Vergleich mit dem Referenz-Code abgeschlossen.
q= W[0][0]^W[6][0]^W[7][0]; a= q, b= q>>32;
q= W[0][1]^W[6][1]^W[7][1]; c= q, d= q>>32;
W[0][0]= (a|(uint64_t)b<<32) ^ W[5][0];
W[0][1]= (c|(uint64_t)d<<32) ^ W[5][1];
Reihenfolge a b c d an Referenz angepaßt.
Jedoch diese Anpassung müßte ja logisch zu Nichtübereinstimmung führen, da bei Dir
der alte Code Übereinstimmung erzielt.
Im Referenzcode ist auch das Schieberegister jeweils nach Schieben befüllt.
Nicht vorher, wie in der Referenz-Dokumentation.
> Soll ich dir den Gesamtstand auf github pushen?
>
>
Das wäre wohl besser, da identische Quellen gleiche Ausgaben haben müssen.
Ich habe bisher über 40 Änderungen gemacht - nie mit übereinstimmenden Vektoren.
> Bei mir geht's, auch mit -m32, auch mit -funsigned-char. Allerdings habe
> ich dir ja nur meine Änderungen geschickt. Evtl. hast du ja noch andere
> Änderungen im Ausgangscode gehabt. Ich hatte deine Originalquelle gestern
> abend noch einmal frisch heruntergeladen, für einen "sauberen" Start.
Ich habe _keine_ Änderungen gemacht bzw. diese auskommentiert.
> ich dir ja nur meine Änderungen geschickt. Evtl. hast du ja noch andere
> Änderungen im Ausgangscode gehabt. Ich hatte deine Originalquelle gestern
> abend noch einmal frisch heruntergeladen, für einen "sauberen" Start.
Dann der Reihe nach die diff-Ausgaben eingepflegt.
Wir müßten identische Quellen haben.
Inzwischen habe ich den Vergleich mit dem Referenz-Code abgeschlossen.
q= W[0][0]^W[6][0]^W[7][0]; a= q, b= q>>32;
q= W[0][1]^W[6][1]^W[7][1]; c= q, d= q>>32;
W[0][0]= (a|(uint64_t)b<<32) ^ W[5][0];
W[0][1]= (c|(uint64_t)d<<32) ^ W[5][1];
Reihenfolge a b c d an Referenz angepaßt.
Jedoch diese Anpassung müßte ja logisch zu Nichtübereinstimmung führen, da bei Dir
der alte Code Übereinstimmung erzielt.
Im Referenzcode ist auch das Schieberegister jeweils nach Schieben befüllt.
Nicht vorher, wie in der Referenz-Dokumentation.
> Soll ich dir den Gesamtstand auf github pushen?
>
>
Ich habe bisher über 40 Änderungen gemacht - nie mit übereinstimmenden Vektoren.
Helmut Schellong
Apr 12, 2022, 9:08:52 AM4/12/22
to
On 04/12/2022 13:54, Enrik Berkhan wrote:
> Helmut Schellong <r...@schellong.biz> wrote:
>> Wo sind die Keys als 32bit-Werte angegeben?
>
> OK, nicht sehr explizit. Ich habe die Gruppierung so gelesen:
>
> KEY:
> 00001111 22223333 44445555 66667777 88889999 AAAABBBB CCCCDDDD EEEEFFFF
[...]
> Helmut Schellong <r...@schellong.biz> wrote:
>> Wo sind die Keys als 32bit-Werte angegeben?
>
> OK, nicht sehr explizit. Ich habe die Gruppierung so gelesen:
>
> KEY:
> 00001111 22223333 44445555 66667777 88889999 AAAABBBB CCCCDDDD EEEEFFFF
>
> Generell werden im Paper alle Zahlen von "links nach rechts" mit
> aufsteigenden Indizes 0.. angegeben.
Die Wertigkeit von X[0] ist nirgendwo angegeben.
> Generell werden im Paper alle Zahlen von "links nach rechts" mit
> aufsteigenden Indizes 0.. angegeben.
Bei Rabbit durchaus.
> Wenn man den Key als 256bit-Wert (so ist er spezifiziert) in diesem
> Kontext ("links nach rechts") liest, dann muss eben nach dem wie auch
> immer gearteten Einlesen in einer gedachten 256bit-Variablen die Zahl
> 0x0000111122223333444455556666777788889999AAAABBBBCCCCDDDDEEEEFFFF
> stehen.
Es entsteht bei mir immer die Frage, ob eine Darstellung eben so (als Zahl)
angesehen werden soll.
Die Referenz-Doku schreibt von einer "length" in Bit von key und iv.
Nirgendwo wird number oder value hierzu geschrieben.
Genau deshalb habe ich den Key (in argv[]) immer als Zeichenkette angesehen.
Bei Rabbit muß er auch Byte für Byte in das Array K[] kopiert werden, von
unten nach oben gleichsinnig - und das funktioniert.
Das ist auch logisch, weil kein universell nutzbares Bit-Objekt mit 256 Bit
Länge/Breite vorhanden ist.
Selbst 'unsigned __int128' reicht da nicht, und ist nicht portabel.
Man ist gezwungen, Arrays zu verwenden.
> Wenn man das als Byte-addressierten Speicherinhalt ab Adresse 0
> betrachtet, dann ist es (wieder, "von links nach rechts", ab 0 bis ..),
> so:
>
> 0 1 2 3 4 5 6 7 ...
> 00 00 11 11 22 22 33 33 ...
>
> "big endian"
>
>
Hat aber nie zu Übereinstimmung geführt.
Wenn im Code beispielsweise 7 Stellen mit nicht definierter Wertigkeit (MSB,LSB)
sind, müssen im WorstCase 2^7-1 verschiedene Quellen durchprobiert werden.
Enrik Berkhan
Apr 12, 2022, 10:13:05 AM4/12/22
to
Helmut Schellong <r...@schellong.biz> wrote:
> On 04/12/2022 12:56, Enrik Berkhan wrote:
>
>> Soll ich dir den Gesamtstand auf github pushen?
>>
> Das wäre wohl besser, da identische Quellen gleiche Ausgaben haben müssen.
https://github.com/enrikb/spitfire
> On 04/12/2022 12:56, Enrik Berkhan wrote:
>
>> Soll ich dir den Gesamtstand auf github pushen?
>>
> Das wäre wohl besser, da identische Quellen gleiche Ausgaben haben müssen.
Bonita Montero
Apr 12, 2022, 10:37:58 AM4/12/22
to
Am 11.04.2022 um 12:44 schrieb Helmut Schellong:
> On 04/11/2022 08:24, Bonita Montero wrote:
>>> Du spinnst.
>>> Ich habe bereits eine größere Anzahl kryptographischer Algorithmen
>>> implementiert.
>>> Alle erzeugen die Referenz-Ergebnisse, nur dragon nicht - bis jetzt.
>>> Das kann auch an einer ungenügenden Beschreibung liegen.
>>
>> Ne, das liegt an einem unfähigen Entwickler.
>>
>
> Enrik Berkhan schrieb:
> |Dass die Beschreibung im Paper, die du oben zitierst, zweifelhaft bis
> |mangelhaft ist, hatten wir ja schon festgestellt.
> Du strafst Dich Lügen.
> Langeweile?
Dumme Ausrede. Es gibt Implemntationen die man vergleichen kann.
> On 04/11/2022 08:24, Bonita Montero wrote:
>>> Du spinnst.
>>> Ich habe bereits eine größere Anzahl kryptographischer Algorithmen
>>> implementiert.
>>> Alle erzeugen die Referenz-Ergebnisse, nur dragon nicht - bis jetzt.
>>> Das kann auch an einer ungenügenden Beschreibung liegen.
>>
>> Ne, das liegt an einem unfähigen Entwickler.
>>
>
> Enrik Berkhan schrieb:
> |Dass die Beschreibung im Paper, die du oben zitierst, zweifelhaft bis
> |mangelhaft ist, hatten wir ja schon festgestellt.
> Du strafst Dich Lügen.
> Langeweile?
Da braucht man nicht seinen halbgaren Code unter die Leute tun.
Helmut Schellong
Apr 12, 2022, 4:16:17 PM4/12/22
to
438] a.out
BC020767DC48DAE3 14778D8C927E8B32 E086C6CDE593C008 600C9D47A488F622
3A2B94D6B853D644 27E93362ABB8BA21 751CAAF7BD316595 2A37FC1EA3F12FE2
5C133BA74C15CE4B 3542FDF893DAA751 F571025649795D54 31914EBA0DE2C2A7
8013D29B56D4A028 3EB6F3127644ECFE 38B9CA111924FBC9 4A0A30F2AFFF5FE0
Korrekte Test-Vektoren!
443] diff dragon.c dragoneb.c
=======================================================================================================
74c74
< for (p=1; p<3; ++p) { char *ap, h, m; uint64_t *P; unsigned nb;
---
> for (p=1; p<3; ++p) { char *ap, h; unsigned m; uint64_t *P; unsigned nb;
88c88
< case 32: for (i=0; i<32; ++i) P[i/8]|= (uint64_t)ap[i]<<8*(i%8);
---
> case 32: for (i=0; i<32; ++i) P[i/8]|= ap[i]<<8*(i%8);
100d99
< //printf("%016lX %016lX %016lX %016lX\n", K[0],K[1],K[2],K[3]);
107,108d105
< //for (i=0; i<32; ++i) a=((uint32_t*)W)[i], //3210:0123
< // ((uint32_t*)W)[i]= a>>24|a>>8&0xFF00|a<<8&0xFF0000|a<<24;
115c112
< for (p=7; p>0; --p) W[p][0]= W[p-1][0], W[p][1]= W[p-1][1];
---
> for (q=7; q>0; --q) W[q][0]= W[q-1][0], W[q][1]= W[q-1][1];
120,121c117
< //for (i=0; i<32; i+=2) q= ((uint64_t*)W)[i/2], B[i]= q, B[i+1]= q>>32;
< for (i=0; i<8; i+=1) B[4*i]= W[i][0]>>32, B[4*i+1]= W[i][0], B[4*i+2]= W[i][1]>>32, B[4*i+3]= W[i][1];
---
> for (i=0; i<8; i+=1) B[4*i]= W[i][0]>>32, B[4*i+1]= W[i][0], B[4*i+2] = W[i][1]>>32, B[4*i+3] = W[i][1];
=======================================================================================================
Wie ich schrieb.
Da sind als Unterschiede nur Kommentare und Irrelevantes.
Meine allerletzten Änderungen (laut Referenzcode) hatte ich schon wieder entfernt.
444] Clang -DDRAGON_TEST=1 dragon.c
445] a.out
BC020767DC48DAE3 14778D8C927E8B32 E086C6CDE593C008 600C9D47A488F622
3A2B94D6B853D644 27E93362ABB8BA21 751CAAF7BD316595 2A37FC1EA3F12FE2
5C133BA74C15CE4B 3542FDF893DAA751 F571025649795D54 31914EBA0DE2C2A7
8013D29B56D4A028 3EB6F3127644ECFE 38B9CA111924FBC9 4A0A30F2AFFF5FE0
Korrekte Test-Vektoren!
Ich weiß nicht mehr, was genau ich kompilierte, so daß wieder falsche Vektoren resultierten.
Es muß ja etwas Unterschiedliches gewesen sein.
Vielleicht irgendwas ein-/auskommentiert, das unbeabsichtigt falsch war.
Es ist jedenfalls ein massiv von der Referenz-Dokumentation abweichender Code
nötig, um ein korrektes Ergebnis zu erzielen.
Besonders der Übergang von W nach B ist nicht gleichsinnig.
Ich kann diesen Dragon nun in meine bish als Kommando einflechten.
Alle Vorgänge müssen allerdings ausschließlich mit diesem bish-Kommando vorgenommen
werden, da es unklar ist, wie ein externer Dragon genau die Bytes von Dateien
in ihrer Reihenfolge bearbeitet.
Ebenso unklar ist die genaue Anreichung von key und iv auf char-Ebene, also was
da wie gedreht werden muß.
Du hast letzteres schon von argv[] her gedreht.
Enrik Berkhan
Apr 13, 2022, 1:53:05 AM4/13/22
to
Helmut Schellong <r...@schellong.biz> wrote:
> Korrekte Test-Vektoren!
Na also! Korrekte Implementierung bewiesen[1]! ;-)
> Es ist jedenfalls ein massiv von der Referenz-Dokumentation abweichender Code
> nötig, um ein korrektes Ergebnis zu erzielen.
Das würde ich anders ausdrücken, da in der Referenz-Dokumentation ja gar
kein Code (und erst Recht kein C-Code) enthalten ist. Es ist der Versuch
einer formalen Beschreibung, der deutliche Lücken enthält.
Das geht schon mit der F-Funktion los. Da werden in Table 1, 5., bereits
b', d' und f' gebildet, also b, d und f streng genommen nicht verändert.
In 6. werden dann aber wieder b, d, und f verwendet. Das müsste m.E. b',
d' und f' sein. In den Schritten vorher werden offensichtlich immer die
Namen ohne ' verwendet und die Inhalte auch nach jedem Schritt
aufgefrischt. Der Datenfluss in Fig. 1 stellt es in diesem Fall
allerdings korrekt dar.
Die Wortreihenfolge ist an vielen Stellen nicht sehr klar angegeben,
aber mit "big endian" liegt man an allen Stellen richtig, ...
> Besonders der Übergang von W nach B ist nicht gleichsinnig.
... auch hier. Aber ich gebe dir Recht, alles etwas schwammig.
Als "am ungenauesten" sehe ich die Darstellung der
Schieberegister-Operationen in Table 2 und Table 3, wo zuerst die Felder
mit neuen Werten besetzt werden und dann geschoben wird. Das kann man
allenfalls im Sinne einer Beschreibungssprache wie VHDL als korrekt
ansehen, wo die Signale ihre neuen Werte in einem Prozess erst zu einem
definierten Zeitpunkt "später" annehmen. Aber das müsste dann schon
etwas genauer spezifiziert sein. (Die oben genannten Widersprüche in
Table 1 bekommt man mit diesem Ansatz allerdings auch nicht aufgelöst.)
Die Spezifikation ist ohne die Referenzimplementierung absolut
unvollständig.
> Ich kann diesen Dragon nun in meine bish als Kommando einflechten.
> Alle Vorgänge müssen allerdings ausschließlich mit diesem bish-Kommando vorgenommen
> werden, da es unklar ist, wie ein externer Dragon genau die Bytes von Dateien
> in ihrer Reihenfolge bearbeitet.
Gibt es denn Implementierungen davon, außer den Referenzcode und die
davon abgeleitete C#-Version, die man auf github findet?
Ich glaube, die Einschränkung ist nicht relevant.
> Ebenso unklar ist die genaue Anreichung von key und iv auf char-Ebene, also was
> da wie gedreht werden muß.
Fun fact: die Autoren des Referenzcodes haben das selbst nicht
hinbekommen. Ich hatte am Anfang des Threads ja schonmal erwähnt, dass
die "optimierte" Variante dragon-opt.c auch nicht das erwartete Ergebnis
liefert. Dort interpretieren sie den Key und IV als Folge von "little
endian" 32bit Zahlen. Wenn man das korrigiert, kommt das Ergebnis zwar
"bytemäßig" korrekt heraus, aber ebenfalls wieder "little endian". Und
nein, diese beiden Operationen heben sich nicht auf ...
Gruß,
Enrik
[1] passende Definition von "Beweis" angenommen
> Korrekte Test-Vektoren!
Na also! Korrekte Implementierung bewiesen[1]! ;-)
> Es ist jedenfalls ein massiv von der Referenz-Dokumentation abweichender Code
> nötig, um ein korrektes Ergebnis zu erzielen.
kein Code (und erst Recht kein C-Code) enthalten ist. Es ist der Versuch
einer formalen Beschreibung, der deutliche Lücken enthält.
Das geht schon mit der F-Funktion los. Da werden in Table 1, 5., bereits
b', d' und f' gebildet, also b, d und f streng genommen nicht verändert.
In 6. werden dann aber wieder b, d, und f verwendet. Das müsste m.E. b',
d' und f' sein. In den Schritten vorher werden offensichtlich immer die
Namen ohne ' verwendet und die Inhalte auch nach jedem Schritt
aufgefrischt. Der Datenfluss in Fig. 1 stellt es in diesem Fall
allerdings korrekt dar.
Die Wortreihenfolge ist an vielen Stellen nicht sehr klar angegeben,
aber mit "big endian" liegt man an allen Stellen richtig, ...
> Besonders der Übergang von W nach B ist nicht gleichsinnig.
Als "am ungenauesten" sehe ich die Darstellung der
Schieberegister-Operationen in Table 2 und Table 3, wo zuerst die Felder
mit neuen Werten besetzt werden und dann geschoben wird. Das kann man
allenfalls im Sinne einer Beschreibungssprache wie VHDL als korrekt
ansehen, wo die Signale ihre neuen Werte in einem Prozess erst zu einem
definierten Zeitpunkt "später" annehmen. Aber das müsste dann schon
etwas genauer spezifiziert sein. (Die oben genannten Widersprüche in
Table 1 bekommt man mit diesem Ansatz allerdings auch nicht aufgelöst.)
Die Spezifikation ist ohne die Referenzimplementierung absolut
unvollständig.
> Ich kann diesen Dragon nun in meine bish als Kommando einflechten.
> Alle Vorgänge müssen allerdings ausschließlich mit diesem bish-Kommando vorgenommen
> werden, da es unklar ist, wie ein externer Dragon genau die Bytes von Dateien
> in ihrer Reihenfolge bearbeitet.
davon abgeleitete C#-Version, die man auf github findet?
Ich glaube, die Einschränkung ist nicht relevant.
> Ebenso unklar ist die genaue Anreichung von key und iv auf char-Ebene, also was
> da wie gedreht werden muß.
hinbekommen. Ich hatte am Anfang des Threads ja schonmal erwähnt, dass
die "optimierte" Variante dragon-opt.c auch nicht das erwartete Ergebnis
liefert. Dort interpretieren sie den Key und IV als Folge von "little
endian" 32bit Zahlen. Wenn man das korrigiert, kommt das Ergebnis zwar
"bytemäßig" korrekt heraus, aber ebenfalls wieder "little endian". Und
nein, diese beiden Operationen heben sich nicht auf ...
Gruß,
Enrik
[1] passende Definition von "Beweis" angenommen
Helmut Schellong
Apr 13, 2022, 5:46:56 AM4/13/22
to
On 04/13/2022 07:40, Enrik Berkhan wrote:
> Helmut Schellong <r...@schellong.biz> wrote:
>> Korrekte Test-Vektoren!
>
> Na also! Korrekte Implementierung bewiesen[1]! ;-)
>
[...]
> Helmut Schellong <r...@schellong.biz> wrote:
>> Korrekte Test-Vektoren!
>
> Na also! Korrekte Implementierung bewiesen[1]! ;-)
>
>
> Die Spezifikation ist ohne die Referenzimplementierung absolut
> unvollständig.
Den Referenz-Code habe ich lange Zeit links liegen gelassen...
> Die Spezifikation ist ohne die Referenzimplementierung absolut
> unvollständig.
Es funktioniert nun mit der Reihenfolge b a d c ab W[0] begonnen.
Im Referenzcode: a b c d
Woanders: d c b a
Ein heilloses Durcheinander.
[...]
>> Ebenso unklar ist die genaue Anreichung von key und iv auf char-Ebene, also was
>> da wie gedreht werden muß.
>
> Fun fact: die Autoren des Referenzcodes haben das selbst nicht
> hinbekommen. Ich hatte am Anfang des Threads ja schonmal erwähnt, dass
> die "optimierte" Variante dragon-opt.c auch nicht das erwartete Ergebnis
> liefert. Dort interpretieren sie den Key und IV als Folge von "little
> endian" 32bit Zahlen. Wenn man das korrigiert, kommt das Ergebnis zwar
> "bytemäßig" korrekt heraus, aber ebenfalls wieder "little endian". Und
> nein, diese beiden Operationen heben sich nicht auf ...
>
Was mich immer verwundert: Es muß doch die Testvektoren-Ausgabe von einer
>> da wie gedreht werden muß.
>
> Fun fact: die Autoren des Referenzcodes haben das selbst nicht
> hinbekommen. Ich hatte am Anfang des Threads ja schonmal erwähnt, dass
> die "optimierte" Variante dragon-opt.c auch nicht das erwartete Ergebnis
> liefert. Dort interpretieren sie den Key und IV als Folge von "little
> endian" 32bit Zahlen. Wenn man das korrigiert, kommt das Ergebnis zwar
> "bytemäßig" korrekt heraus, aber ebenfalls wieder "little endian". Und
> nein, diese beiden Operationen heben sich nicht auf ...
>
/Referenzimplementation/ generiert worden sein - so wie sie in der PDF
präsentiert wird.
Das muß doch zwangsläufig aus einem Guß sein...
>
> [1] passende Definition von "Beweis" angenommen
>
Das ist Quatsch:
Wir haben einen deterministischen Keystream von Bit 0 bis Bit 2^64-1.
Die Testausgabe hat 1024 Bit.
Wenn diese übereinstimmt, muß auch der Rest übereinstimmen, weil der
Algorithmus es nicht hergibt, daß die ersten 1024 Bit übereinstimmen, jedoch
danach fehlende Übereinstimmungen vorkommen können.
Das ist dem Algorithmus inhärent.
Es geht um den Beweis einer korrekten Implementation!
Beispiel:
Zuweisung von 'b' und 'c' nach dem Schieben statt vor dem Schieben
hat nur die ersten 4x64 Bit von 1024 gleich belassen (256).
Die restlichen 12x64 Bit der Ausgabe waren völlig anders!
Ich habe http://www.schellong.de/htm/dragon.c.html aktualisiert.
Ich kann Dir ein kostenlos erhaltenes Buch:
-------------------------------------------
Understanding Cryptography
A Textbook for Students and Practitioners
PDF, 382 Seiten, Springer-Verlag 2010
Prof. Dr.-Ing. Christof Paar
Chair for Embedded Security
Department of Electrical Engineering
and Information Sciences
Ruhr-Universität Bochum
44780 Bochum
Germany
cp...@crypto.rub.de
Dr.-Ing. Jan Pelzl
escrypt GmbH – Embedded Security
Zentrum für IT-Sicherheit
Lise-Meitner-Allee 4
44801 Bochum
Germany
jpe...@escrypt.com
-------------------------------------------
per Telekom-Cloud zukommen lassen (Zugriffscode: Enrik....@inka.de).
Enrik Berkhan
Apr 13, 2022, 1:13:06 PM4/13/22
to
Helmut Schellong <r...@schellong.biz> wrote:
> Was mich immer verwundert: Es muß doch die Testvektoren-Ausgabe von einer
> /Referenzimplementation/ generiert worden sein - so wie sie in der PDF
> präsentiert wird.
> Das muß doch zwangsläufig aus einem Guß sein...
Naja, die Programme, die die erzeugen etc., wurden wohl vom
> Was mich immer verwundert: Es muß doch die Testvektoren-Ausgabe von einer
> /Referenzimplementation/ generiert worden sein - so wie sie in der PDF
> präsentiert wird.
> Das muß doch zwangsläufig aus einem Guß sein...
eSTREAM-Projekt beigesteuert.
Ich hatte mir ein einfaches "main" geschrieben, dass eben den
Testschlüsselstrom ausgibt, ohne endianess-Verrenkungen:
#v+
#include <stdio.h>
#include <string.h>
#include "ecrypt-sync.h"
static const unsigned nblocks = 16;
static const u8 key[] =
{
0x00, 0x00, 0x11, 0x11, 0x22, 0x22, 0x33, 0x33, 0x44, 0x44, 0x55, 0x55, 0x66, 0x66, 0x77, 0x77,
0x88, 0x88, 0x99, 0x99, 0xaa, 0xaa, 0xbb, 0xbb, 0xcc, 0xcc, 0xdd, 0xdd, 0xee, 0xee, 0xff, 0xff
};
static const u8 iv[] =
{
0x00, 0x00, 0x11, 0x11, 0x22, 0x22, 0x33, 0x33, 0x44, 0x44, 0x55, 0x55, 0x66, 0x66, 0x77, 0x77,
0x88, 0x88, 0x99, 0x99, 0xaa, 0xaa, 0xbb, 0xbb, 0xcc, 0xcc, 0xdd, 0xdd, 0xee, 0xee, 0xff, 0xff
};
int main(void)
{
ECRYPT_init();
ECRYPT_ctx ctx;
memset(&ctx, 0, sizeof(ctx));
ECRYPT_keysetup(&ctx, key, 256, 256);
ECRYPT_ivsetup(&ctx, iv);
// dragon produces 64bit key stream blocks
u8 keyblocks[nblocks*2*4];
ECRYPT_keystream_blocks(&ctx, keyblocks, nblocks);
// output 32bit groups
for (size_t i = 0; i < nblocks*2; i++) {
for (size_t j = 0; j < 4; j++) {
printf("%02x", keyblocks[4*i + j]);
}
fputc(i%8==7? '\n':' ', stdout);
}
return 0;
}
#v-
(OMG, C-Code, werden wir am Ende noch on-topic sein?)
Hab das mal mit ins repo gepackt, inkl. den Ergänzungen und Fixes, die
ich zum erfolgreichen Testen brauchte.
Der Code in ref/dragon-ref.c hat aber tatsächlich ohne Änderungen das
richtige Ergebnis geliefert.
(ECRYPT_keystream_bytes ist aber immer noch defekt, das habe ich nicht
angefasst.)
> Ich kann Dir ein kostenlos erhaltenes Buch:
Gruß,
Enrik
Helmut Schellong
Apr 13, 2022, 2:30:29 PM4/13/22
to
On 04/13/2022 19:01, Enrik Berkhan wrote:
> Helmut Schellong <r...@schellong.biz> wrote:
>> Was mich immer verwundert: Es muß doch die Testvektoren-Ausgabe von einer
>> /Referenzimplementation/ generiert worden sein - so wie sie in der PDF
>> präsentiert wird.
>> Das muß doch zwangsläufig aus einem Guß sein...
>
> Naja, die Programme, die die erzeugen etc., wurden wohl vom
> eSTREAM-Projekt beigesteuert.
>
> Ich hatte mir ein einfaches "main" geschrieben, dass eben den
> Testschlüsselstrom ausgibt, ohne endianess-Verrenkungen:
>
> [...]
> Helmut Schellong <r...@schellong.biz> wrote:
>> Was mich immer verwundert: Es muß doch die Testvektoren-Ausgabe von einer
>> /Referenzimplementation/ generiert worden sein - so wie sie in der PDF
>> präsentiert wird.
>> Das muß doch zwangsläufig aus einem Guß sein...
>
> Naja, die Programme, die die erzeugen etc., wurden wohl vom
> eSTREAM-Projekt beigesteuert.
>
> Ich hatte mir ein einfaches "main" geschrieben, dass eben den
> Testschlüsselstrom ausgibt, ohne endianess-Verrenkungen:
>
>
> Hab das mal mit ins repo gepackt, inkl. den Ergänzungen und Fixes, die
> ich zum erfolgreichen Testen brauchte.
>
> Der Code in ref/dragon-ref.c hat aber tatsächlich ohne Änderungen das
> richtige Ergebnis geliefert.
>
> Genau so etwas meine ich.
> Hab das mal mit ins repo gepackt, inkl. den Ergänzungen und Fixes, die
> ich zum erfolgreichen Testen brauchte.
>
> Der Code in ref/dragon-ref.c hat aber tatsächlich ohne Änderungen das
> richtige Ergebnis geliefert.
>
Bei Rabbit ist algo-Beschreibung, Referenz-C-Code, Testvektoren in einer PDF (es gibt mehrere (3)).
Außerdem ist in der RFC neben genauer Beschreibung und Testvektoren ein Link auf ECRYPT,
wo wiederum alles auffindbar ist.
Bei Rabbit allerdings hatte ich allein gemäß RFC auf Anhieb Erfolg.
In der Dragon-PDF fehlt das meiste.
Man hätte dort (z.B. bei den Testvektoren) eindeutige explizite Hinweise
geben können, so daß man sich sicher fühlt.
Nachreichung:
All the keystream words and feedback words are dependent on all input words,
both at the bit level and word level. A single bit change in any of the six input
words results in completely different keystream and feedback words.
Helmut Schellong
Apr 18, 2022, 7:42:17 AM4/18/22
to
On 04/13/2022 20:30, Helmut Schellong wrote:
> On 04/13/2022 19:01, Enrik Berkhan wrote:
>> Helmut Schellong <r...@schellong.biz> wrote:
[...]
> On 04/13/2022 19:01, Enrik Berkhan wrote:
>> Helmut Schellong <r...@schellong.biz> wrote:
>> Der Code in ref/dragon-ref.c hat aber tatsächlich ohne Änderungen das
>> richtige Ergebnis geliefert.
>>
>> Genau so etwas meine ich.
> Bei Rabbit ist algo-Beschreibung, Referenz-C-Code, Testvektoren in einer PDF (es gibt mehrere (3)).
> Außerdem ist in der RFC neben genauer Beschreibung und Testvektoren ein Link auf ECRYPT,
> wo wiederum alles auffindbar ist.
> Bei Rabbit allerdings hatte ich allein gemäß RFC auf Anhieb Erfolg.
>
> In der Dragon-PDF fehlt das meiste.
> Man hätte dort (z.B. bei den Testvektoren) eindeutige explizite Hinweise
> geben können, so daß man sich sicher fühlt.
>
>
http://www.schellong.de/htm/dragon.c.html#beweis
>> richtige Ergebnis geliefert.
>>
>> Genau so etwas meine ich.
> Bei Rabbit ist algo-Beschreibung, Referenz-C-Code, Testvektoren in einer PDF (es gibt mehrere (3)).
> Außerdem ist in der RFC neben genauer Beschreibung und Testvektoren ein Link auf ECRYPT,
> wo wiederum alles auffindbar ist.
> Bei Rabbit allerdings hatte ich allein gemäß RFC auf Anhieb Erfolg.
>
> In der Dragon-PDF fehlt das meiste.
> Man hätte dort (z.B. bei den Testvektoren) eindeutige explizite Hinweise
> geben können, so daß man sich sicher fühlt.
>
>
Volker Bartheld
May 20, 2022, 5:28:34 AM5/20/22
to
[x'p/f'up, ist in de.sci.electronics OT.]
On Sat, 9 Apr 2022 02:40:51 +0200, Helmut Schellong wrote:
> http://www.schellong.de/htm/dragon.c.html
>
> Die Beschreibung ist deutlich weniger genau als die von Rabbit.
> Hinsichtlich Text und der Pseudo-Programmiersprache.
> Das hatte Folgen.
> https://www.ecrypt.eu.org/stream/p3ciphers/dragon/dragon_p3.pdf
>
> Der Algorithmus funktioniert.
> Allerdings sind die Test-Ausgaben meiner Implementation
> nicht gleich mit den Referenz-Ausgaben.
> Es ist mir auch in mehreren Tagen nicht gelungen, das erfolgreich zu ändern.
> Das ist wegen meiner Verwendungsart jedoch egal.
> Meine Testausgaben sind in den Zeilen 275..349.
>
> Die Testausgaben zeigen ein gutes random-Verhalten.
> Änderungen von einzelnen Key-Bits ändern den Keystream jeweils total.
> Die verschlüsselte Textdatei dragon.c ist vom Überblick her einwandfrei verschlüsselt:
>
> dragon.c':
> 11b+272 e0 d4 29 4c ee c6 4d a7 67 2d 68 be f4 b3 14 7c ..)L..M.g-h....|
> 11b+288 84 07 11 73 a4 25 86 3c 4b bb 08 1b f7 de dd 3a ...s.%.<K......:
> 11b+304 db d7 c4 9e 22 3f a2 72 61 41 fa 0a ab da 0d 82 ...."?.raA......
> 11b+320 f2 d3 e7 15 ba 21 d4 e7 b2 0f a4 34 cf 78 69 e6 .....!.....4.xi.
> 11b+336 c7 aa 95 04 f4 b3 9d ee f7 c4 07 6d d5 b8 f1 df ...........m....
> 11b+352 24 a9 e7 a5 65 7d 8d 41 3f e4 76 b3 a5 ff a4 74 $...e}.A?.v....t
> 11b+368 b1 2a 47 7f 77 b3 e1 8e fe a1 5d 0d 4f 09 cf 09 .*G.w.....].O...
> 11b+384 46 58 44 1e f5 92 1a 2e b5 d5 9c c0 c0 c2 ef 75 FXD............u
> 11b+400 08 ee 38 b0 4c 58 d1 7e 96 08 26 7a 60 23 b6 a3 ..8.LX.~..&z`#..
> 11b+416 c7 a6 7f 18 54 d9 07 e9 2e 4d 8d 8b 58 00 0a 49 ....T....M..X..I
> 11b+432 55 8c 6e 8f 46 79 02 6d f1 3f dc 69 0a 99 0f b8 U.n.Fy.m.?.i....
> 11b+448 6f 5f 87 89 5a f7 c4 99 c5 fe a4 00 f4 a4 53 8f o_..Z.........S.
> 11b+464 8b ad ff 69 23 10 a7 ed 00 5b 14 1f f6 b5 99 ac ...i#....[......
> 11b+480 90 5f eb 72 27 31 96 eb ac 18 57 c2 2a 1a b9 b5 ._.r'1....W.*...
> 11b+496 89 a7 57 c9 e2 67 e3 f0 7f 6c 6d b1 37 dc 65 da ..W..g...lm.7.e.
> 12b+000 a1 33 96 5d 3b 7c 35 fb 4e 05 59 cb 45 08 f2 33 .3.];|5.N.Y.E..3
> 12b+016 82 9c a9 47 b8 dc 87 af 01 20 83 50 ab 1e 1b 1d ...G..... .P....
> 12b+032 11 22 bf 86 2c c1 47 10 97 1f 30 73 e7 c6 a5 7f ."..,.G...0s....
> 12b+048 9e ea 43 80 ef 83 19 1b b3 48 46 89 19 a4 53 43 ..C......HF...SC
> 12b+064 6c 8e bd b7 fa 3e 89 36 a0 a2 c3 89 65 ee cc c5 l....>.6....e...
> 12b+080 3a 81 f0 2d 87 dd c3 92 1e 94 7d ce 81 f3 ab 17 :..-......}.....
> 12b+096 b3 2f 04 3b 83 96 84 32 6d 2e 46 8a cb f9 ad 84 ./.;...2m.F.....
> 12b+112 94 60 33 b4 63 45 eb ce 02 19 50 02 93 b7 e4 80 .`3.cE....P.....
> 12b+128 a7 20 fe 3e 9f 34 ce e7 e7 b3 c7 9f 6a 0d 33 e3 . .>.4......j.3.
> 12b+144 28 f4 ec b7 53 82 0f bd f4 4a 3a bb fe a1 08 38 (...S....J:....8
> 12b+160 0c b4 30 ea 24 ef 54 cd e5 99 cf 79 67 45 7c 8e ..0.$.T....ygE|.
> 12b+176 d2 e0 a7 51 d2 fb b2 5b 76 b2 c2 5f ae 19 18 64 ...Q...[v.._...d
> 12b+192 c1 5c 24 02 44 1a 47 c2 52 9c 5f 47 d6 85 32 d9 .\$.D.G.R._G..2.
> 12b+208 87 a8 f8 0a 42 df 99 a5 5b b1 0d 09 1e 69 d6 02 ....B...[....i..
> 12b+224 73 3a a0 da ba 98 69 6b 14 03 37 07 73 ad 6a b5 s:....ik..7.s.j.
> 12b+240 39 77 3c f8 4d 6d 89 8b fd 30 ce 10 29 45 4c 1b 9w<.Mm...0..)EL.
> 12b+256 35 6d de e5 83 b0 b1 e4 32 3d d7 49 d5 bc e5 86 5m......2=.I....
> 12b+272 1d 00 0e 6b d6 58 c9 02 72 d0 e2 2a e0 3b 15 08 ...k.X..r..*.;..
> 12b+288 82 fe 53 44 31 49 a8 3d 43 11 12 bb f4 05 0d 01 ..SD1I.=C.......
> 12b+304 61 7e 40 21 ac a6 12 2f 4f ac db ca 54 f1 53 3f a~@!.../O...T.S?
> 12b+320 3f 21 f7 16 1e 34 ff f5 d8 6a 4b 63 2c 06 05 62 ?!...4...jKc,..b
On Sat, 9 Apr 2022 02:40:51 +0200, Helmut Schellong wrote:
> http://www.schellong.de/htm/dragon.c.html
>
> Die Beschreibung ist deutlich weniger genau als die von Rabbit.
> Hinsichtlich Text und der Pseudo-Programmiersprache.
> Das hatte Folgen.
> https://www.ecrypt.eu.org/stream/p3ciphers/dragon/dragon_p3.pdf
>
> Der Algorithmus funktioniert.
> Allerdings sind die Test-Ausgaben meiner Implementation
> nicht gleich mit den Referenz-Ausgaben.
> Es ist mir auch in mehreren Tagen nicht gelungen, das erfolgreich zu ändern.
> Das ist wegen meiner Verwendungsart jedoch egal.
> Meine Testausgaben sind in den Zeilen 275..349.
>
> Die Testausgaben zeigen ein gutes random-Verhalten.
> Änderungen von einzelnen Key-Bits ändern den Keystream jeweils total.
> Die verschlüsselte Textdatei dragon.c ist vom Überblick her einwandfrei verschlüsselt:
>
> dragon.c':
> 11b+272 e0 d4 29 4c ee c6 4d a7 67 2d 68 be f4 b3 14 7c ..)L..M.g-h....|
> 11b+288 84 07 11 73 a4 25 86 3c 4b bb 08 1b f7 de dd 3a ...s.%.<K......:
> 11b+304 db d7 c4 9e 22 3f a2 72 61 41 fa 0a ab da 0d 82 ...."?.raA......
> 11b+320 f2 d3 e7 15 ba 21 d4 e7 b2 0f a4 34 cf 78 69 e6 .....!.....4.xi.
> 11b+336 c7 aa 95 04 f4 b3 9d ee f7 c4 07 6d d5 b8 f1 df ...........m....
> 11b+352 24 a9 e7 a5 65 7d 8d 41 3f e4 76 b3 a5 ff a4 74 $...e}.A?.v....t
> 11b+368 b1 2a 47 7f 77 b3 e1 8e fe a1 5d 0d 4f 09 cf 09 .*G.w.....].O...
> 11b+384 46 58 44 1e f5 92 1a 2e b5 d5 9c c0 c0 c2 ef 75 FXD............u
> 11b+400 08 ee 38 b0 4c 58 d1 7e 96 08 26 7a 60 23 b6 a3 ..8.LX.~..&z`#..
> 11b+416 c7 a6 7f 18 54 d9 07 e9 2e 4d 8d 8b 58 00 0a 49 ....T....M..X..I
> 11b+432 55 8c 6e 8f 46 79 02 6d f1 3f dc 69 0a 99 0f b8 U.n.Fy.m.?.i....
> 11b+448 6f 5f 87 89 5a f7 c4 99 c5 fe a4 00 f4 a4 53 8f o_..Z.........S.
> 11b+464 8b ad ff 69 23 10 a7 ed 00 5b 14 1f f6 b5 99 ac ...i#....[......
> 11b+480 90 5f eb 72 27 31 96 eb ac 18 57 c2 2a 1a b9 b5 ._.r'1....W.*...
> 11b+496 89 a7 57 c9 e2 67 e3 f0 7f 6c 6d b1 37 dc 65 da ..W..g...lm.7.e.
> 12b+000 a1 33 96 5d 3b 7c 35 fb 4e 05 59 cb 45 08 f2 33 .3.];|5.N.Y.E..3
> 12b+016 82 9c a9 47 b8 dc 87 af 01 20 83 50 ab 1e 1b 1d ...G..... .P....
> 12b+032 11 22 bf 86 2c c1 47 10 97 1f 30 73 e7 c6 a5 7f ."..,.G...0s....
> 12b+048 9e ea 43 80 ef 83 19 1b b3 48 46 89 19 a4 53 43 ..C......HF...SC
> 12b+064 6c 8e bd b7 fa 3e 89 36 a0 a2 c3 89 65 ee cc c5 l....>.6....e...
> 12b+080 3a 81 f0 2d 87 dd c3 92 1e 94 7d ce 81 f3 ab 17 :..-......}.....
> 12b+096 b3 2f 04 3b 83 96 84 32 6d 2e 46 8a cb f9 ad 84 ./.;...2m.F.....
> 12b+112 94 60 33 b4 63 45 eb ce 02 19 50 02 93 b7 e4 80 .`3.cE....P.....
> 12b+128 a7 20 fe 3e 9f 34 ce e7 e7 b3 c7 9f 6a 0d 33 e3 . .>.4......j.3.
> 12b+144 28 f4 ec b7 53 82 0f bd f4 4a 3a bb fe a1 08 38 (...S....J:....8
> 12b+160 0c b4 30 ea 24 ef 54 cd e5 99 cf 79 67 45 7c 8e ..0.$.T....ygE|.
> 12b+176 d2 e0 a7 51 d2 fb b2 5b 76 b2 c2 5f ae 19 18 64 ...Q...[v.._...d
> 12b+192 c1 5c 24 02 44 1a 47 c2 52 9c 5f 47 d6 85 32 d9 .\$.D.G.R._G..2.
> 12b+208 87 a8 f8 0a 42 df 99 a5 5b b1 0d 09 1e 69 d6 02 ....B...[....i..
> 12b+224 73 3a a0 da ba 98 69 6b 14 03 37 07 73 ad 6a b5 s:....ik..7.s.j.
> 12b+240 39 77 3c f8 4d 6d 89 8b fd 30 ce 10 29 45 4c 1b 9w<.Mm...0..)EL.
> 12b+256 35 6d de e5 83 b0 b1 e4 32 3d d7 49 d5 bc e5 86 5m......2=.I....
> 12b+272 1d 00 0e 6b d6 58 c9 02 72 d0 e2 2a e0 3b 15 08 ...k.X..r..*.;..
> 12b+288 82 fe 53 44 31 49 a8 3d 43 11 12 bb f4 05 0d 01 ..SD1I.=C.......
> 12b+304 61 7e 40 21 ac a6 12 2f 4f ac db ca 54 f1 53 3f a~@!.../O...T.S?
> 12b+320 3f 21 f7 16 1e 34 ff f5 d8 6a 4b 63 2c 06 05 62 ?!...4...jKc,..b
Helmut Schellong
May 20, 2022, 9:44:23 AM5/20/22
to
On 05/20/2022 11:28, Volker Bartheld wrote:
> [x'p/f'up, ist in de.sci.electronics OT.]
>
>
Ich schätze, es gibt hier eventuell mindestens das 50-fache an
> [x'p/f'up, ist in de.sci.electronics OT.]
>
>
anderem OFFtopic mit höherem OFFtopic-Grad - nämlich bis zu 100%.
Politik, Gesellschaft, Soziales, Verschwörungstheorien, Banales Geplapper, u.v.a.m.
Die Posting-Frequenz explodiert geradezu, je hochgradiger etwas OFFtopic ist.
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
0 new messages