Moin,
ich benutze FinPhone mit einem SDA und WMobile5.0
Das Einrichten der Bankingsoft hat gut gefunzt und die Synchronisierung mit der Bank klappt tadelos. Alle Konten werden exakt aufgeführt.
Gebe ich jedoch eine Überweisung ein und schicke die zur Bank bricht der Prozess mit der Fehlermeldung ab das die RDH Signatur 96 Bytes lang sein muß.

Was mach ich falsch?

Hallo,

um welche Bank handelt es sich denn? Welche Schlüsseldatei verwendest Du?

SDA und WM5, wie geht denn das?

Die Bank ist die Volksbank in Bielefeld und den Key habe ich mit der Runtime Libary DDBAC erstellt und ist eine *.rdh.

Die Version des OS habe ich wohl vertöxelt )

Danke für die Info. Leider habe ich dennoch keinen Plan, was daswirklich vor sich geht. Könntest Du mir noch ein "Extras > Online Protokoll" anfertigen und per E-Mail an support AT subsembly.com zuschicken. Vielleicht finde ich darin ja etwas.

Bielefeld gibt es doch gar nicht *g*

das scheint auf eine falsche HBCI-Version hin zu deuten, die Signaturlänge unterscheidet sich bei FINTS3.0 zu den HBCI Versionen 2.20-2.01. Versuche es einmal mit HBCI Version 2.xx (fest einstellen).
Gruß
Raimund

Moin,

also den Fehler mit auch genau dieser Meldung kennt man doch auch aus anderen Programmen. Da hört man dann immer: "... ein sporadischer Fehler unter Verwendung dieses HBCI-Kernels...Auftrag löschen neu erstellen..." dann geht´s auch meistens... Irgendwie "verschluckt" wohl der Kernel je nach belieben mal ein byte...hicks...

Keine Lösung...aber ein "qualifiziertes" Halb-so-schlimm

Bis dann

Od

"mit diesem HBCI-Kernel" ?

Bisher gibt es abgesehen von FinPhone und FinPocket keine Anwendung die meinen Kernel verwendet. Ich vermute das Problem mal eher beim Server.

Schon die Fehlermeldung "RDH Signatur 96 Bytes lang sein muß" (wie heißt sie eigentlich genau?) ist falsch:

HBCI erlaubt explizit die Verwendung von RSA Schlüsseln mit einer Länge von 708 bis 768 Bit (vgl. HBCI 2.2 VI.3.1.3.1), also ca. 88 bis 96 Bytes. Das Ergebnis der RSA-Operation kann nie länger als der Modulus sein. Hat der Modulus z.B. 760 Bit, dann hat auch das Ergebnis nur 760 Bit, oder weniger. Das RSA-Ergebnis ist effektiv der Rest aus der Teilung durch den Modulus und kann deshalb noch sehr viel kleiner und kürzer ausfallen. Nehmen wir aber an, das Ergebnis hat ebenfalls 760 Bit: Das wären dann 95 Byte. Der weitere Reduktionsschritt nach ISO 9796 macht das Ergebnis eher noch kürzer. D.h. das endgültige Signaturergebnis hat auch nur 95 Byte. Ein Padding durch vorangestellte Nullbytes ist an keiner Stelle der HBCI Spezifikation vorgeschrieben.

Ich befürchte allerdings, dass der GAD-Server ein Problem mit kurzen Signaturen hat, die nicht durch vorangestellte Nullen auf 96 Byte Länge erweitert wurden. Komisch, dass der Server eine spezielle Fehlermeldung liefert, statt dass die Entwickler den Bug einfach behoben hätten.

...neh mit diesem Kernel noch nicht...

Dazu muß ich gestehen, dass ich dieses Programm so noch nicht in der freien Wildbahn kennengelernt habe.

Die Feldermeldung kenne ich allerdings aus Programmen der SM-Reihe, bei Profi Cash / Home Cash und auch schon mal von der DDBAC...

Die Zitate "..." sind ja das was unsereiner zu hören bekommt... und das ist meisten durch entsprechende Scheuklappen/Sichtweisen vorgeprägt...

Aber es ist schon richtig, dass die ursprüngliche Ursache wohl eher bei der GAD liegt... Genossenschaftliches Amt für Datenverarbeitung...

Bis dann

Od

Yo, nun is das soweit und ich kann mich als Tölpel outen. Habe eine weitere Überweisung eingegeben und gesendet. Alles hat funktioniert und es gab keine Fehlermeldung. Das macht meine Verwirrung natürlich perfekt.
Trotzdem habe ich versucht das Online Protololl zu finden. Nur hab ich keine Extras gefunden.
Mir scheint das das alles doch schwieriger ist als ich dachte

Sorry, ich habe FinPocket mit FinPhone verwechselt. In FinPhone gibt es kein Extras Menü und auch kein Online Protokoll.