Topic: Bitcoinbasics, vielleicht eine Moeglichkeit BTCs geziehlt zu generieren - page 5. (Read 8395 times)

hallo,
wau, jemand der zugibt fehler zu machen. ist hier recht selten.
wuerde mich interesieren, wie du auf deinen fehler gekommen bist, oder wer dich drauf aufmerksam gemacht hat. um das zu erkennen, muss man naemlich ahnung haben. also wenn du die moeglichkeit hast, wuerde ich mich freuen, wenn du mir bescheid gibst, wie es mit diesen werten aussieht.
wie du dir sicher vorstellen kannst, kann ich das mit meinem kasten nicht in meiner lebenszeit ueberpruefen, bin da halt auf groessere angewiesen...
und weil ich auch nicht perfekt bin, haben ich mit diesem hash in meiner formel auch eine fehler gefunden. habe mir allerdings wahrscheinlich einen a2n3 eingefangen und bin deshalb nicht sehr gut drauf. aber um hier wenigsten etwas zu antworten, werden ich wenigstens ein paar werte hier posten:
a63=&H0FF4A7D0
b63=B26595F0_
c63=&H093433ED
d63=2EB60A80
e63=&H0B990BFD
f63=DC21FBDA_
g63=9822F88B
h63=B0F71F99_
achja, wenn dein ausgangsstring laenger als 512 bit war, dann sind diese werte sicher nicht die von deinem string, sondern nur die, von einer moeglichen kollision. hoffe, dass du das verstanden hast. kollisionen treten naemlich spaetestens mit der laenge vom hash auf. nur wenn man weitersucht, kann man den orginalen finden, macht aber meistens nicht sehr viel sinn, weil nur auf den hash geprueft wird und damit die kollision zum orginal wird.


achja @Souri, hoffe das war nicht ironisch gemeint...

p.p
finde es witzig, dass der todestag von sha1 genau vor 3 tagen war:
https://www.heise.de/security/meldung/Todesstoss-Forscher-zerschmettern-SHA-1-3633589.html
http://winfuture.de/news,96388.html
versuche immer mindestens 2 verschiedene quellen anzugeben, damit es an glaubwuerdigkeit gewinnt.
sollten an sich 3 sein, aber soo wichtig fand ich das dann doch nicht, was ich zufaellig gefunden hatte...


und noch was unterhaltsames:
wenn das gerichtsurteil in kraft tritt, sind es recht genau 666 tage. laesst also kaum zweifel offen, wer da seine finger im spiel hat. gut, dass ich nicht aberglaeubisch bin

Ok, ich lag falsch - W63 ist in dem Fall wirklich 1860953359 (dezimal).

Wie schaut es bei diesem Hash aus (diesmal ohne Input)?

79fe8e376dcd447545a3275fd405ffba5ca75e7c77276466b7a6d2360cd7ecb2

Ein wirklich schöner Thread für meinen angekaterten Sonntag gestern.

also wenn du das so sicher schreiben kannst, kannst du mir auch sicher den deiner meinung nach richtigen wert mitteilen. aber im prinzip kannst du auch recht haben, weil durch die vorzeichenlos summe das ganze nicht mehr eindeutig ist. also werde ich die anderen auch noch ausrechnen und mal schauen, ob einer von denen dann uebereinstimmt.
waere auch schoen zu wissen, wie du drauf gekommen bist.
muss nicht unbedingt mit code sein.

habe etwas gesucht und versucht meine quellen zusammenzutragen, habe aber leider bei der definition von der beobachtbarkeit keine deutsche uebersetzung gefunden:
https://es.wikipedia.org/wiki/Grafos_observables#Verificación_de_Observabilidad
(spanisch)
https://de.wikipedia.org/wiki/Elliptische_Kurve
https://de.wikipedia.org/wiki/Modularitätssatz
https://de.wikipedia.org/wiki/Hidden_Markov_Model
https://de.wikipedia.org/wiki/Baum-Welch-Algorithmus

Naja, in Dezimal... Aber egal, der Wert ist falsch. W63 bei diesem Hash ist nicht 0x6EEBE50F oder 1860953359 (dec) Hier lag ich falsch, W63 ist tatsächlich 1860953359.

ok, habe den w63 wert von dem hash von oben ja hingeschrieben.
soll ich dir noch einen ausrechnen? oder glaubst du mir so, dass es rueckwaerts geht?

Wo dein Denkfehler liegt habe ich ja eh schon erläutert, der Code da macht auch das Richtige wahrscheinlich - du liegst einfach falsch mit deiner Annahme.

hallo,
also bis zum 05.04.2018 bin ich wahrscheinlich nicht eingekastelt, habe mir aber einen deftigen a2n3 eingefangen.

keine kommentare?

schade, dass ich diese info nicht vorher hatte, aber nach dieser nomenklatur ist H nicht h.
und es ist nicht meine fehler, sondern wenn dann von dem, der den code geschrieben hat.
diese inizialwerte werden nur geaendert, wenn die eingabe groesser als 512 bit ist. also nicht im 62. durchlauf.
habe zwar die doc von deinem link nur ueberflogen, aber nirgends gefunden, dass das letzte w der eingabe die bit-laenge der eingabe enthalten muss.
da dieser code die mehrzahl an beispielen richtig ausrechnet, habe ich mich auf ihn gestuetzt.
ist aber im prinzip recht unwichtig, weil das vorgehen auf das was und nicht auf das wie angewendet wird.
funktioniert also auch mit anderen ahnlichen codes.
wuerde sogar sagen, nicht nur mit allen sha, sondern auch mit anderen aehnlichen einwegfunktionen.
will mich aber nicht zu sehr verzetteln.
jetzt schauen wir erst mal, was in der gerichtsverhandlung rauskommt.
ausserdem glaube ich nicht, dass dieser thread das vertrauen viel beeinflussen kann. bleibt also alles beim alten.

Ok, da liegt also dein Fehler: Die "H(0)...H(7)" Werte die du da zu a-h dazurechnen musst, sind NICHT die Initialwerte, sondern die Werte aus Runde 62.

Die haben diesen Wert nur ganz zu Beginn der Berechnung:
"For SHA-256, the initial hash value, H(0), consists of the following eight 32-bit words, in hex.  These words were obtained by taking the first 32 bits of the fractional parts of the square roots of the first eight prime numbers."

(https://tools.ietf.org/html/rfc6234#section-6.1)

In meiner Schreibweise sind das also H(0)[0] bis H(0)[7], nicht H(62)[0] bis H(62)[7], die du eigentlich brauchst.
Siehst du auch in deinem Codeschnipsel, HASH(0) bis HASH(7) werden ständig (insgesamt 64 Mal) mit neuen Werten überschrieben.

hast recht, am schluss ist es kein xor, sondern ein plus ohne vorzeichen und die 32 bit habe ich auch verkehrt abgezaehlt, aber abgesehen von diesen leichtsinnsfehlern, die lehrer gerne machen, um zu schauen, ob ihre studenten auch noch aufpassen und weil ichs nicht lassen kann (hab ja sonst nix zu tun) hier der entsprechende codeteil:

  ' Initial hash values
    HASH(0) = &H6A09E667
    HASH(1) = &HBB67AE85
    HASH(2) = &H3C6EF372
    HASH(3) = &HA54FF53A
    HASH(4) = &H510E527F
    HASH(5) = &H9B05688C
    HASH(6) = &H1F83D9AB
    HASH(7) = &H5BE0CD19

...

        HASH(0) = AddUnsigned(a, HASH(0))
        HASH(1) = AddUnsigned(b, HASH(1))
        HASH(2) = AddUnsigned(c, HASH(2))
        HASH(3) = AddUnsigned(d, HASH(3))
        HASH(4) = AddUnsigned(e, HASH(4))
        HASH(5) = AddUnsigned(f, HASH(5))
        HASH(6) = AddUnsigned(g, HASH(6))
        HASH(7) = AddUnsigned(h, HASH(7))
    Next
    
    ' Output the 256 bit digest
    SHA256 = LCase(Right("00000000" & Hex(HASH(0)), 8 ) & _
        Right("00000000" & Hex(HASH(1)), 8 ) & _
        Right("00000000" & Hex(HASH(2)), 8 ) & _
        Right("00000000" & Hex(HASH(3)), 8 ) & _
        Right("00000000" & Hex(HASH(4)), 8 ) & _
        Right("00000000" & Hex(HASH(5)), 8 ) & _
        Right("00000000" & Hex(HASH(6)), 8 ) & _
        Right("00000000" & Hex(HASH(7)), 8 ))
End Function

*_______________________________________________________________________________

diese funktion ergibt den hash von "1234":
03ac674216f3e15c761ee1a5e255f067953623c8b388b4459e13f978d7c846f4

sieht fuer mich recht gleich aus wie der oben, ist aber nicht kopiert. und weil ich schon dabei war:

a63 - h63 dec:
 1,535,914,711     967,831,091     1,023,802,157     1,420,154,975     411,257,785     2,123,374,541     2,078,767,579     1,801,166,163

w63 dec:
 1,860,953,359

also hatte nur keine lust es auf hex umzuwandeln, aber deiner version muss ich leider widersprechen, zumindest wenn man die nomenklatur von wiki nimmt. wie dein source aussieht haste ja auch nicht dargelegt.

aber wie sie mir auch schon gesagt haben, wahrscheinlich ist es ja nur die uhrzeit. manche arbeiten halt nachts besser und manche nicht.

*) ist open source, also muesste es gnu-lizens sein. nur, dass es alle wissen, ist nicht von mir.
sowas kann nicht auf meinem mist gewachsen sein, weil ich die doc dazu ueberhaupt nie gefunden habe.
aber vielleicht habe ich ja nur nicht richtig gesucht...

Das ist schon mal falsch. Das was du da beschreibst, sind H(63)[0] bis H(63)[7]:

tut mir leid, aber mein open source macht das zum schluss. vielleicht habe ich ja gerade ein programm erwischt, dass rein zufaellig den gleichen hash ausrechten, wenn es genau das zum schluss macht.
ist aber etwas unwahrscheinlich.
in wiki ist das naemlich nicht beschrieben, aber wiki weiss ja nicht unbedingt alles.
wenn der letzte schritt nicht diese verknuepfung waere, dann waere es ja noch einfachen:
dann wuerden naemlich die variaben direkt dran stehen.
gut, dann werde ich sie a64 bis h64 nennen und somit waere a64 gleich &h03ac67, b64 gleich &h4216f3 usw.
also viel rechnen braucht man dann ja nicht...

Wenn SHA256 so funktionieren würde, ja. Tut es aber nicht, da ist kein XOR am Schluss. Daher nochmal: Welche Werte errechnest du bei diesem Beispiel?

wau, jetzt hat es jemand verstanden. also um einen echten lernerfolg zu haben, kann ich dir den tip geben, dass immer 32 bit abschnitte (also 03ac67. 4216f3,...) mit den inizialhashwerten im letzten schritt ge-xor-d werden. nein, nicht mit den k-werten.
also jetzt muesstest du selber diese werte rausfinden koennen.

aber weil ich nicht so bin, werde ich vielleicht mir die muehe am 22.02 machen und die loesung verraten, damit du vergleichen kannst, ob wir vom gleichen geschrieben haben.
warum der 22.? weil, wie geschrieben, da meine gerichtsverhandlung ist. also wenn ich nicht eingebuchtet bin, dann kann ich mir auch die muehe machen

Na dann mal ein echtes Beispiel:

Hier ist der SHA256 Wert vom Inputstring "1234": 03ac674216f3e15c761ee1a5e255f067953623c8b388b4459e13f978d7c846f4

Was sind die jeweiligen a63 ... h63 Werte davon?

also gut, nochmal in anderen worten:
auf dem hashwert, sagen wir mal 666, rechne ich die variablen a, b, c, d, e, f, g und h fuer den letzten schritt zurueck. also a63, ... h63
dann mache ich die verknuepfungen, wie es auf der wikiseite steht, nur dass ich einfach den w63 ausklammere, also die gleichung nach w63 aufloese.

die restlichen w-werte sind nicht rueckrechenbar, weil es ja eine einwegfunktion sein sollte.
kann sie zwar statistisch "erahnen", wenn ich den w63-wert habe, ist aber nicht sehr genau.

also nehme ich nur den w63-wert als kriterium und schon habe ich eine vorauswahl fuer mein brute force.

so und wenn es jetzt nicht klar geworden ist, dann gebe ich auf. dann sind meine komunikationsfaehigkeiten zu unausreichend. das versteht naemlich sogar meine 10 jahrige tochter.

danke fuer diese aufklaerung.
scheinst doch mehr zu wissen, als ich dir zugerechnet haette. ich weiss, immer meine falschen schluesse. klar, dass die vielseitigkeit einbussen in der geschwindigkeit gibt, aber mehr als faktor zehn glaube ich wiederum auch nicht. aber natuerlich kann ich damit ja auch wieder falsch liegen.

Dann schreib halt mehr hin? Wie berechnest du die restlichen Werte z.B.?

Nochmal: W63 hängt vom gesamten Input ab und die weiteren Werte auf die du dich da beziehst, stammen auch aus früheren Runden der Hashfunktion und sind nicht einfach so irgendwelche Konstanten.

Du glaubst immer noch zuviel, informierst Dich immer noch zu wenig und ziehst auf dieser Basis immer noch zu viele (falsche) Schlussfolgerungen. 

Es liegt nicht am Fabrikationsdadtum, sondern am Aufbau. Der FPGA besteht aus Pools von SRAM Zellen, die von Logikfunktionen umgeben sind. Diese Pools sind miteinander mit endlich vielen Leitungen Verbunden, um umfangreichere Funktionen abbilden zu können. Alleine aus den entsprechenden Blockschaltbildern wird klar, warum ein solches Gebilde niemals die Grenzfrequez einer einfachen dedizierten Logik im ASIC erreichen kann, einen höheren Stromverbrauch zur Folge hat und wesentlich mehr Platz verbraucht.