Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #319726

Re: dragon-cipher C-Quelle (vollständig)

Show all headers | View raw

On 04/09/2022 13:41, Enrik Berkhan wrote:
> Helmut Schellong <rip@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.



-- 
Mit freundlichen Grüßen
Helmut Schellong   var@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

Back to de.sci.electronics | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

dragon-cipher C-Quelle (vollständig) Helmut Schellong <rip@schellong.biz> - 2022-04-09 02:40 +0200
  Re: dragon-cipher C-Quelle (vollständig) Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-04-09 11:41 +0000
    Re: dragon-cipher C-Quelle (vollständig) Helmut Schellong <rip@schellong.biz> - 2022-04-09 15:55 +0200
      Re: dragon-cipher C-Quelle (vollständig) Helmut Schellong <rip@schellong.biz> - 2022-04-09 16:23 +0200

csiph-web