Jump to content
Melde dich an, um diesem Inhalt zu folgen  
Tyler_Durden

API mit Python

Empfohlene Beiträge

Geschrieben (bearbeitet)

Hallo liebe Coinler,

ich habe mich die letzten Tage mit der API beschäftigt.
Um mal ein Projekt zu haben, bei dem ich ein wenig meine (begrenzten) Programmierkenntnisse zu nutzen fand ich das sehr spannend. - Erstmal geht es mir also nur um ein Get des Orderbooks und rumspielen mit dem Datensatz.

Mit dem Basic-Satz ist schon mal alles gut soweit. Ich bekomme den Ask und Bid Satz als dict of lists und kann die Daten darin verarbeiten.

Mit dem v4 stoße ich aber auf einen 400-Error. Mir werden aber credits beim ausführen abgezogen und die Trading-API Notaus-Link Mail kommt auch.
Also bin ich nicht voll auf dem Holzweg, oder? :(

Das hier soll keine Disskussion darüb sein, ob Python das richtige Tool ist o.ä. (es sei denn, dass es Systemseitig einfach damit nicht geht) da es wie gesagt ein Projekt ist um mit der Programmiersprache zu arbeiten, also der Weg das Ziel ist.

Anbei einmal mein Code zum Zweck der Hilfestellung :)

import hashlib
import hmac
import requests
import time
import json


api_key     =   "MEIN API KEY"            # Entspricht dem eigenen API-Key
nonce       =   str(int(time.time()))     # Das für den aktuellen Request verwendete Nonce
api_secret  =   "MEIN API SECRET"         # Entspricht dem eigenen API-Secret
http_method =   'GET'
uri         =   'https://api.bitcoin.de/v4/orders'

get_parameter_url_encoded_query_string = "type=buy"

uri = uri+'?'+ get_parameter_url_encoded_query_string

hmac_data = http_method+'#'+uri+'#'+api_key+'#'+nonce+'#'+ get_parameter_url_encoded_query_string

h = hmac.new(bytes(api_secret, 'utf-8'), b'', hashlib.sha256)
h.update(bytes(hmac_data, 'utf-8'))

get_parameter = {'type': 'buy'}

head ={'X-API-KEY': api_key, 'X-API-NONCE': nonce, 'X-API-SIGNATURE': h.hexdigest()}

r = requests.get('https://api.bitcoin.de/v4/btceur/orderbook', params=get_parameter, headers=head)

Ich bin kein Programmierer, oder überhaupt IT-ler, daher musste ich bereits viel über API und HTTP-Requests lernen, das bedeutet aber auch, dass mein Fehler vielleicht total offensichtlich und dämlich ist, weil ich z.B. immer noch nicht 100% verstehe was der Header bei dem API-Call ist und lediglich versuche es anzuwenden.

Es ist mir z.B. auch ein Rätsel, warum ich die ganzen Infos zu dem Link mit in den hmac-code einfließen lasse, verstehe es aber momentan als zusätzlcihe Sicherheitseinrichtung.

bearbeitet von Tyler_Durden
Info zu Trading-API Notaus-Link

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Geschrieben (bearbeitet)

Hallo

>> warum ich die ganzen Infos zu dem Link mit in den hmac-code einfließen lasse

Du signierst damit deinen Call. Damit kann die Gegenstelle verifizieren, dass der von dir kommt (bzw. von jemandem, der deinen PRIVATEKEY hat, was nur du sein solltest).

>> hmac_data = http_method+'#'+uri+'#'+api_key+'#'+nonce+'#'+ get_parameter_url_encoded_query_string

Da fehlt doch im Falle von GET das "#d41d8cd98f00b204e9800998ecf8427e" als "md5 hash über die nicht vorhandenen POST parameter" (hier stellt sich tatsächlich die Frage nach der Sinnhaftigkeit...)

>> was der Header bei dem API-Call ist

Der HTTP Standard definiert das so. 1. Methode (GET, POST, PUT etc), 2. URL (die Zieladresse), 3. Header (Key-Value-Paare) und 4. Body (im Prinzip ein Bytearray, es gibt verschiedene Unterformate wie man einen Body mit welchem Inhalt verschicken kann.)

>> Mit dem v4 stoße ich aber auf einen 400-Error

Was kommt denn als Body zurück? Da ich nicht regelmäßig mit Python arbeite kann ich auf die schnelle nicht beurteilen, ob die h.* aufrufe korrekt sind.

Grüße casiopaya

bearbeitet von casiopaya

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Dazu folgende Tips

1. Wenn Du das API Spiel spielen willst, lern programmieren. 

2. Wenn Du ne API haben willst, es gibt sehr viele auf Rest Server bei Github. Und das in fast allen Sprachen. Die sind in der Regel ausgetestet und Dokumentiert, da muss man nicht viel machen.

3. Fang bei 1 wieder an.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 31 Minuten schrieb Männergruppe Monk:

Dazu folgende Tips

1. Wenn Du das API Spiel spielen willst, lern programmieren. 

2. Wenn Du ne API haben willst, es gibt sehr viele auf Rest Server bei Github. Und das in fast allen Sprachen. Die sind in der Regel ausgetestet und Dokumentiert, da muss man nicht viel machen.

3. Fang bei 1 wieder an.

0 .Ich frage mich bei Foren manchmal warum Antworten so sinnfrei und inhalts- und hilfefrei sein müssen.
Bestimmt hast du es voll drauf und die Fragen sind für dich vielleicht total doof. Das will ich dir gar nicht absprechen. Aber auch du bist nicht als Programmier und Bitcoin Pro vom Baum gefallen.
Deine von mir subjektiv empfundene Abfällige Art ist demotivierend, unnötig und unangebracht.

1. Wie gesagt: Es soll ein Lern-Projekt sein, um mich mit Programmieren zu beschäftigen (und es damit besser zu lernen). Ob es das sinnvollste Projekt dafür ist sei man so dahingestellt, aber es ist nun mal das, was ich mir ausgesucht habe. Wenn ich scheitere war ich selbst schuld.

2. Bei github gibt es eine API-python skript extra für bitcoin.de, die aber auf Version 2 oder so basiert und inaktiv ausssieht. Ausserdem geht es ir nicht darum etwas fertiges zu haben, sondern etwas zu erschaffen. Aus Gründen s. 1.

3. klar, Sarkasmus ist super lustig, aber lies mal 0. und schau dir mal die Antwort von casiopaya an, wie eine hilfrecihe Antwort aussehen kann.
Bei deinem Post hättest du vor dem Abschicken lieber mal das Tab geschlossen. Dein Post war nämlich nicht nur keine Hilfe sondern war destruktiv.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor einer Stunde schrieb casiopaya:

Hey,

vielen Dank für die ausführliche und hilfreiche Antowort.

>>Du signierst damit deinen Call. Damit kann die Gegenstelle verifizieren, dass der von dir kommt (bzw. von jemandem, der deinen PRIVATEKEY hat, was nur du sein solltest).

Was ich explizit meinte war, dass ich noch einmal die uri samtt Parametern in dem hash codiere.
Für mich sieht es doppelt aus. Ich kann es mir also nur so erklären, dass jedee X-API-SIGNATURE auf die Art der Anfrage codiert ist. Ich also mit einem abgefangenen X-API-SIGNATURE für meineOrderbookabfrage nicht auch einen Kauf einstellen kann (wobei ich dachte das würde durch den immer ansteigenen nonce schön unmöglich werden).
Aber da fehlt mir glaube ich zu viel Wissen zu Kryptografie und IT-Sicherheit.

 

>>Da fehlt doch im Falle von GET das "#d41d8cd98f00b204e9800998ecf8427e" als "md5 hash über die nicht vorhandenen POST parameter" (hier stellt sich tatsächlich die Frage nach der Sinnhaftigkeit...)

Da hast du vollkommen recht. Durch mein frustriertes rumgeschiebe und ausprobieren habe ich die Anfrage total zerschossen.
So sah er vorher aus:


import hashlib
import hmac
import requests
import time
import json


api_key     =   "KEY"                 	# Entspricht dem eigenen API-Key
nonce       =   str(int(time.time()))   # Das für den aktuellen Request verwendete Nonce
api_secret  =   "SECRET"         		# Entspricht dem eigenen API-Secret
http_method =   'GET'
uri         =   'https://api.bitcoin.de/v4/orders'

get_parameter_url_encoded_query_string = "type=buy"

uri = uri+'?'+ get_parameter_url_encoded_query_string

post_parameter_url_encoded_query_string = "d41d8cd98f00b204e9800998ecf8427e"

hmac_data = http_method+'#'+uri+'#'+api_key+'#'+nonce+'#'+ post_parameter_url_encoded_query_string

h = hmac.new(bytes(api_secret, 'utf-8'), b'', hashlib.sha256)
h.update(bytes(hmac_data, 'utf-8'))
print (h.hexdigest())

get_parameter = {'type': 'buy'}

head ={'X-API-KEY': api_key, 'X-API-NONCE': nonce, 'X-API-SIGNATURE': h.hexdigest()}

r = requests.get('https://api.bitcoin.de/v4/btceur/orderbook', params=get_parameter, headers=head)

print (r.status_code)

Was kommt denn als Body zurück? Da ich nicht regelmäßig mit Python arbeite kann ich auf die schnelle nicht beurteilen, ob die h.* aufrufe korrekt sind.

Die Farge nach dem Body habe ich mir nie gestellt, ich dachte ich bekomem nur die 400 als Statuscode zurück.
Das war also ein super Ansatz:


{"errors":[{"message":"Invalid signature","code":5}],"credits":43}

Ich kann es also auf die X-API-SIGNATURE eingrenzen, das war ja bereits mein Verdacht. Aber schön, dass es stimmte :D
Ich werde morgen einmal schauen, ob ein PHP skript mit dem


HMAC('sha256', hmac_data, api_secret)

bei einem Test das gleiche auswirft wie python mit dem hashlib.sha256.

 

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

>> für meineOrderbookabfrage nicht auch einen Kauf einstellen kann

Im Prinzip ist das der Grund ja. die Sigantur ist für jede Nachricht eine eigene. Du sendest <NACHRICHT><SIGNATUR>. Die Nachricht ist unverschlüsselt (mal von TLS bei Header+Body abgesehen...), die Signatur "verschlüsselt" deine Nachricht noch einmal mit dem PRIVATE key und macht einen kurzen Hash daraus. Der Gegenüber kann mit dem zugehörigen PUBLIC key anhand von <SIGNATUR> verifizieren, dass <NACHRICHT> korrekt und nicht abgeändert ist. Das ganze basiert darauf, dass nur du den PRIVATE key hast. Selbes Prinzip gibts bei Signierten Emails oder PDFs mit qualifizierten Signaturen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 9 Stunden schrieb Tyler_Durden:

0 .Ich frage mich bei Foren manchmal warum Antworten so sinnfrei und inhalts- und hilfefrei sein müssen.
Bestimmt hast du es voll drauf und die Fragen sind für dich vielleicht total doof. Das will ich dir gar nicht absprechen. Aber auch du bist nicht als Programmier und Bitcoin Pro vom Baum gefallen.
Deine von mir subjektiv empfundene Abfällige Art ist demotivierend, unnötig und unangebracht.

1. Wie gesagt: Es soll ein Lern-Projekt sein, um mich mit Programmieren zu beschäftigen (und es damit besser zu lernen). Ob es das sinnvollste Projekt dafür ist sei man so dahingestellt, aber es ist nun mal das, was ich mir ausgesucht habe. Wenn ich scheitere war ich selbst schuld.

2. Bei github gibt es eine API-python skript extra für bitcoin.de, die aber auf Version 2 oder so basiert und inaktiv ausssieht. Ausserdem geht es ir nicht darum etwas fertiges zu haben, sondern etwas zu erschaffen. Aus Gründen s. 1.

3. klar, Sarkasmus ist super lustig, aber lies mal 0. und schau dir mal die Antwort von casiopaya an, wie eine hilfrecihe Antwort aussehen kann.
Bei deinem Post hättest du vor dem Abschicken lieber mal das Tab geschlossen. Dein Post war nämlich nicht nur keine Hilfe sondern war destruktiv.

Du musst einfach mal weiterdenken, bevor Du kindlich wirst.

Wozu hast Du die API oder was ist der Sinn, eine solche zu haben ? Selbst wenn Du die hin bekommst, wie sieht der nächste Schritt aus, genau, das verlangt Programmieren.

Wenn ich die Wahl habe, nehme ich eine funktionierende API von Github zum Broker und fokussiere mich auf die Dinge, die danach kommen.

Ansonsten sollte man evtl. mit was Einfacherem anfangen als eine Rest Ankopplung an einen Broker. Zum Beispiel erstmal Programmieren lernen, dann die Basics der Sprache lernen.

 

Es gibt hier eine TradingBot Post, der ist zum üben gedacht, das solltest Du Dir evtl. ansehen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 11 Stunden schrieb casiopaya:

Hallo

>> warum ich die ganzen Infos zu dem Link mit in den hmac-code einfließen lasse

Du signierst damit deinen Call. Damit kann die Gegenstelle verifizieren, dass der von dir kommt (bzw. von jemandem, der deinen PRIVATEKEY hat, was nur du sein solltest).

>> hmac_data = http_method+'#'+uri+'#'+api_key+'#'+nonce+'#'+ get_parameter_url_encoded_query_string

Da fehlt doch im Falle von GET das "#d41d8cd98f00b204e9800998ecf8427e" als "md5 hash über die nicht vorhandenen POST parameter" (hier stellt sich tatsächlich die Frage nach der Sinnhaftigkeit...)

>> was der Header bei dem API-Call ist

Der HTTP Standard definiert das so. 1. Methode (GET, POST, PUT etc), 2. URL (die Zieladresse), 3. Header (Key-Value-Paare) und 4. Body (im Prinzip ein Bytearray, es gibt verschiedene Unterformate wie man einen Body mit welchem Inhalt verschicken kann.)

>> Mit dem v4 stoße ich aber auf einen 400-Error

Was kommt denn als Body zurück? Da ich nicht regelmäßig mit Python arbeite kann ich auf die schnelle nicht beurteilen, ob die h.* aufrufe korrekt sind.

Grüße casiopaya

Ich habe jetzt mal geschaut ob mein python-code bei der hmca-Methode das selbe Ergebnis ausgibt wie ein Onlinetool für SHA265 (für random Testdaten). Das ist der Fall.

Im Aufbau meiner hmac_data Variable sehe ich aber keinen Fehler im Vergleich zur Doku.
Vom Error 5 her verstehe ich es aber so, dass lediglich die Signatur das Problem ist?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 11 Stunden schrieb Tyler_Durden:

Vom Error 5 her verstehe ich es aber so, dass lediglich die Signatur das Problem ist?

Einen anderen Anhaltspunkt gibt es erstmal nicht. Eventuell kannst du dir doch mal den Code von github runterladen, den ans Laufen bringen und dann vergleichen, was dein code und der github code an Signatur produziert. Leider hat bitcoin.de keine Beispiele gelistet anhand deren man die eigene Implementierung verifizieren könnte, das hätte ich anfangs auch gebraucht.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 10 Stunden schrieb casiopaya:

den ans Laufen bringen und dann vergleichen, was dein code und der github code an Signatur produziert.

Signaturen sind in der Regel nicht deterministisch, daher kann man sie nicht vergleichen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 2 Stunden schrieb MixMax:

Signaturen sind in der Regel nicht deterministisch, daher kann man sie nicht vergleichen.

Auch wenn die Signatur für eine erhöhte Sicherheit (alleine schon wegen des immer anderen nonce) immer anders sein wird, habe ich zumindest ausprobieren können, ob der Text "Dies ist ein Text" mit dem Secret Key 12345 das selbe Ergebnis ausgibt.

Dies war der Fall.

vor 13 Stunden schrieb casiopaya:

Eventuell kannst du dir doch mal den Code von github runterladen, den ans Laufen bringen und dann vergleichen, was dein code und der github code an Signatur produziert.

Leider sieht es so aus, als sei im Fall von dem Github-Modul die Signatur noch nicht Teil der API-Interaktion. Daher ist das nicht mögich.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Geschrieben (bearbeitet)
vor 2 Stunden schrieb Tyler_Durden:

Auch wenn die Signatur für eine erhöhte Sicherheit (alleine schon wegen des immer anderen nonce) immer anders sein wird, habe ich zumindest ausprobieren können, ob der Text "Dies ist ein Text" mit dem Secret Key 12345 das selbe Ergebnis ausgibt.

Dies war der Fall.

Ja klar, denn der zu signierende Text darf ja eh nicht geändert werden. Das ist ja der Sinn dahinter.
Die Signatur hinter dem Text, wird (bei nicht deterministischen Signaturen) aber immer anders sein.
Ich würde allerdings eh empfehlen, deterministische Signaturen zu verwenden. Sie sind nicht nur sicherer, sondern können dann auch leicht gegengeprüft werden.
BitcoinCore nutzt auch deterministische Signaturen.

bearbeitet von MixMax

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

casiopaya schrieb (auch, wenn hier Tyler_Durden angezeigt wird):

On 6/16/2020 at 11:48 PM, Tyler_Durden said:

Da hast du vollkommen recht. Durch mein frustriertes rumgeschiebe und ausprobieren habe ich die Anfrage total zerschossen.
So sah er vorher aus:


import hashlib
import hmac
import requests
import time
import json


api_key     =   "KEY"                 	# Entspricht dem eigenen API-Key
nonce       =   str(int(time.time()))   # Das für den aktuellen Request verwendete Nonce
api_secret  =   "SECRET"         		# Entspricht dem eigenen API-Secret
http_method =   'GET'
uri         =   'https://api.bitcoin.de/v4/orders'

get_parameter_url_encoded_query_string = "type=buy"

uri = uri+'?'+ get_parameter_url_encoded_query_string

post_parameter_url_encoded_query_string = "d41d8cd98f00b204e9800998ecf8427e"

hmac_data = http_method+'#'+uri+'#'+api_key+'#'+nonce+'#'+ post_parameter_url_encoded_query_string

h = hmac.new(bytes(api_secret, 'utf-8'), b'', hashlib.sha256)
h.update(bytes(hmac_data, 'utf-8'))
print (h.hexdigest())

get_parameter = {'type': 'buy'}

head ={'X-API-KEY': api_key, 'X-API-NONCE': nonce, 'X-API-SIGNATURE': h.hexdigest()}

r = requests.get('https://api.bitcoin.de/v4/btceur/orderbook', params=get_parameter, headers=head)

print (r.status_code)

Hier ist zumindest der Fehler drin, dass du den MD5-Wert eines Leerstrings (d41d8cd98f00b204e9800998ecf8427e) nutzt, obwohl du den MD5 über deinen URL-Parameter "type=buy" (44af1bc3841a162a58d6618329ac6c01) hättest errechnen müssen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

>> Hier ist zumindest der Fehler drin, dass du den MD5-Wert eines Leerstrings (d41d8cd98f00b204e9800998ecf8427e) nutzt, obwohl du den MD5 über deinen URL-Parameter "type=buy" (44af1bc3841a162a58d6618329ac6c01) hättest errechnen müssen.

Die Doku sagt im Prinzip folgendes: Der MD5 Hash wird nur über die POST parameter gemacht. Im Falle von GET gibt es die nicht, TROTZDEM muss man dann den MD5 Hash "über die POST Parameter machen", was bedeutet, über den leeren String. Deshalb ist der hash die obere Konstante. Über die Sinnhaftigkeit darf da wie gesagt durchaus diskutiert werden. Ich kann mir nur vorstellen, dass bitcoin.de das aus PErformancegründen macht, sozusagen um keine Fälle unterscheiden zu müssen.

 

>> Signaturen sind in der Regel nicht deterministisch, daher kann man sie nicht vergleichen.

Mein Vorschlag klappt natürlich nur bei deterministischen Verfahren, aber sämtliche von bitcoin.de in diesem Prozess genutzen Hashverfahren sind dies. Ehrlich gesagt sind mir nichtdeterministische Signaturen neu, aber man lernt ja nie aus.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
1 hour ago, casiopaya said:

Die Doku sagt im Prinzip folgendes: Der MD5 Hash wird nur über die POST parameter gemacht. Im Falle von GET gibt es die nicht, TROTZDEM muss man dann den MD5 Hash "über die POST Parameter machen", was bedeutet, über den leeren String.

Oops, Punkt für dich.

Das hatte ich oben übersehen, obwohl ihr das schon mal erwähnt hattet.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
11 hours ago, MixMax said:

Signaturen sind in der Regel nicht deterministisch

Kann man das so sagen? Der Zweck einer Signatur ist doch, deterministisch zu sein, damit man die Korrektheit des damit signierten Textes überprüfen kann.

Zur Sicherheit habe ich noch gegoogled und habe tatsächlich "Probabilistic Signature Scheme" gefunden. Scheint mir aber eher ein Sonderfall zu sein und keine "übliche" digitale Signatur.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Geschrieben (bearbeitet)
vor 1 Stunde schrieb PeWi:

Kann man das so sagen? Der Zweck einer Signatur ist doch, deterministisch zu sein, damit man die Korrektheit des damit signierten Textes überprüfen kann.

Zur Sicherheit habe ich noch gegoogled und habe tatsächlich "Probabilistic Signature Scheme" gefunden. Scheint mir aber eher ein Sonderfall zu sein und keine "übliche" digitale Signatur.

Der gängige Lehrweg für eine Signatur ist:

r = k*G  ,  s = (h+r*p)/k

Die Zufallszahl k ist dabei nicht Deterministisch, und damit r und s auch nicht.

Ein Sonderfall bzw. die Erweiterung ist dann k durch eine Verknüpfung mit einer statischen Zahl:  "(Determinier-Wort) || Dokument || p"  zu erhalten, um das Sicherheitsrisiko k als Zufallszahl zu eliminieren. Mit dem "Determinier-Wort" erhält man dann zusätlich noch eine sublime Markierung.

bearbeitet von MixMax

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
12 hours ago, MixMax said:

Der gängige Lehrweg für eine Signatur ist:

r = k*G  ,  s = (h+r*p)/k

Die Zufallszahl k ist dabei nicht Deterministisch, und damit r und s auch nicht.

Oops, auf dem Niveau werden wir nicht zusammenkommen. Bedenke bitte, dass ich Laie bin.

Deswegen nochmal die Frage (und bitte verständlich erklären):

Wie kann eine Signatur - also eine im "üblichen" Sinne, die beweisen soll, das etwas korrekt und unmanipuliert ist - ein Zufallselement enthalten und damit nicht deterministisch sein?
Wie kann man dann anhand dieser Signatur die Korrektheit prüfen?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 16 Minuten schrieb PeWi:

Oops, auf dem Niveau werden wir nicht zusammenkommen. Bedenke bitte, dass ich Laie bin.

Deswegen nochmal die Frage (und bitte verständlich erklären):

Wie kann eine Signatur - also eine im "üblichen" Sinne, die beweisen soll, das etwas korrekt und unmanipuliert ist - ein Zufallselement enthalten und damit nicht deterministisch sein?
Wie kann man dann anhand dieser Signatur die Korrektheit prüfen?

Es tut mir leid! Die zu Grunde liegenden Mathematik ist komplex. Dafür kann ich nichts. Ich weis jetzt auch nicht, wie ich die Verifikation (die noch komlexer) ist, ohne die Mathematischen Zusammenhänge erklären kann.

Ist wirklich nicht böse gemeint!

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Geschrieben (bearbeitet)

Vielleicht ein Beispiel:

Alle Zahlen die durch z.B. 13 teilbar sind, wären richtige Signaturen.  Dann kann man auch unendliche viele richtige Signaturen erzeugen

bearbeitet von MixMax

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
25 minutes ago, MixMax said:

Alle Zahlen die durch z.B. 13 teilbar sind, wären richtige Signaturen.  Dann kann man auch unendliche viele richtige Signaturen erzeugen

Ok, das ist doch schon mal eine verständliche Erklärung.

Trotzdem nochmal die Frage: Wozu braucht die Erzeugung einer Signatur Zufallselemente?

Er würde doch theoretisch die Kombination aus einem assymetrischen Verschlüsselungsverfahren und einer Hashfunktion reichen?
Text hashen und mit dem Private Key verschlüsseln. Dann kann jeder andere das mit dem Public Key kontrollieren.

In Wikipedia steht, dass das aber nur bei einer "naiven und unsicheren Variante von RSA" so gehandhabt wurde. Warum?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Geschrieben (bearbeitet)
vor 1 Stunde schrieb PeWi:

Trotzdem nochmal die Frage: Wozu braucht die Erzeugung einer Signatur Zufallselemente?

Braucht sie nicht zwingend, deswegen gibt es ja Deterministische Signaturen.
Wie ich schon schrieb, war die ursprüngliche Entwicklung der Signatur auf ECDSA Basis halt so aufgebaut. Warum auch immer.
Weil es nun im Verlauf Sicherheitsbedenken und einen aufsehenerregenden
Skandal bei der Playstation gab, (Die Zufallszahl k wurde mehrfach verwendet)
wurden deterministische Signaturen immer beliebter. Von dem Playstation-Hack habe selbst ich profitiert, ohne die Hintergründe damals schon gekannt zu haben. 🙂

vor 1 Stunde schrieb PeWi:

Er würde doch theoretisch die Kombination aus einem assymetrischen Verschlüsselungsverfahren und einer Hashfunktion reichen?
Text hashen und mit dem Private Key verschlüsseln. Dann kann jeder andere das mit dem Public Key kontrollieren.

Nein. ECDSA Signatur-Algorithmus ist keine Verschlüsselung, enthält keine Verschlüsselungskomponenten und kann auch nicht dafür
verwendet werden, das ist was völlig anders. Auch, wenn diese Märchen weit verbreitet ist.

Wenn man mit dem Public key entschlüsseln könnte, dann wäre der "Geheime Text ja offengelegt". Mit dem Public Key können nur Signaturen
überprüft werden aber keine Verschlüsselten Texte. RSA, AES oder Twofish sind Verschlüsselungen. ECDSA sind Signatur Algorithmen. Zwei völlig verschiedene Dinge!

Warum sollte man versuchen RSA oder eine andere Verschlüsselung zum Signieren irgendwie umzubauen, wenn es doch ECDSA gibt, was sehr gut
funktioniert und genau dafür entwickelt wurde? Klar, kann man machen, muss man aber nicht. Einfacher oder Sicherer wäre es jedenfalls nicht, auch andere Vorteile erkenne ich derzeit nicht.

vor 1 Stunde schrieb PeWi:

In Wikipedia steht, dass das aber nur bei einer "naiven und unsicheren Variante von RSA" so gehandhabt wurde. Warum?

Ok, du sprichst jetzt von RSA, was zur Signierung in bestimmten Fällen verwendet werden kann.

Was dort bei RSA unter Signieren angesprochen wird, ist eine Variante der Signatur die bei Bitcoin so nicht zum Einsatz kommt.
Zitat aus diesem Wikipedia Artikel:

Zitat

Um eine Nachricht m{\displaystyle m}m zu signieren, wird vom Sender auf die Nachricht die RSA-Funktion mit dem eigenen privaten Schlüssel d{\displaystyle d}d angewendet. Zum Prüfen wendet der Empfänger auf die Signatur mdmod N{\displaystyle m^{d}{\bmod {\ }}N}m^{d}{\bmod {\ }}N mit Hilfe des öffentlichen Schlüssels des Senders e{\displaystyle e}e die Umkehrfunktion an und vergleicht diese mit der zusätzlich übermittelten unverschlüsselten Nachricht m{\displaystyle m}m

Es müsste bei diesem Verfahren also zusätzlich die unverschlüsselte Nachricht übermittelt werden.  Daran kann man schon erkennen, das es ein völlig anderer Ansatz ist, als ECDSA wie es im Bitcon Protokoll zum Einsatz kommt.

bearbeitet von MixMax

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
4 minutes ago, MixMax said:

Nein! ECDSA Signaturen sind keine Verschlüsselung, das ist was völlig anders. Auch wenn diese Märchen weit verbreitet ist.

Vielleicht haben wir auch die ganze Zeit aneinander vorbei geredet?

Ich meinte nie Signaturen, wie sie bei BTC oder ähnlichem verwendet werden, sondern sowas wie im Kontext dieses Threads.

Z.B.
-  du hast einen URL-Get- oder -Post-Aufruf und bildest einen Hash über URL, Parameter und PirvKey - das ist deine Signatur
- du signierst mit PGP eine Mail
- ...
 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
vor 3 Stunden schrieb PeWi:

Vielleicht haben wir auch die ganze Zeit aneinander vorbei geredet?

Ja ein bisschen, ich hab das dann im Verlauf auch gemerkt. Da wir in einem Bitcoin Forum sind, dachte ich anfangs du redest nur über die Signaturen in Bitcion Transaktionen.

Natürlich gibt es auch andere Vervahren zur Signatur und auch andere Anwendungen.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Melde dich an, um diesem Inhalt zu folgen  

×
×
  • Neu erstellen...

Wichtige Information

Wir speichern Cookies auf Ihrem Gerät, um diese Seite besser zu machen. Sie können Ihre Cookie-Einstellungen anpassen, ansonsten gehen wir davon aus, dass Sie damit einverstanden sind. In unseren Datenschutzerklärungen finden sie weitere Informationen.