log☇︎
254 entries in 0.51s
mp_en_viaje: just because sha256 is theoretically AN INFINITY OF TIMES easier to break than sha512 does not in fact mean you can break either as you stand today.
stjohn_piano_2: to quote myself "To attack a hidden-key address, an adversary would need to discover weaknesses in: ECDSA, SHA256, RIPEMD-160. These weaknesses would also have to be compatible. To attack a known-key address, an adversary would only need to discover a weakness in ECDSA."
stjohn_piano_2: http://btcbase.org/log/2019-05-16#1914041 << well, i don't yet know how to do ecdsa, ripemd160, sha256 on paper. ☝︎
mod6: aha, ok. in the past, i've alwasys built the sha256 stuff for my own purposes. let's see if i can get the keccak stuff build.
mod6: so... is the goal here to build the sha256 stuff, or the keccak stuff?
a111: Logged on 2018-06-11 15:46 asciilifeform: one interesting observation, is that the update mechanism lets you flash in arbitrary crapola into 'rw' section ( it simply won't jump to it if it doesn't pass rsa(sha256(payload)) ) . so theoretically could put a nop sled there, ending with jump into the magic half of unlock routine. and then expose the thing to beta/gamma, and perhaps in a few months it will Do The Right Thing
a111: Logged on 2018-06-11 15:46 asciilifeform: one interesting observation, is that the update mechanism lets you flash in arbitrary crapola into 'rw' section ( it simply won't jump to it if it doesn't pass rsa(sha256(payload)) ) . so theoretically could put a nop sled there, ending with jump into the magic half of unlock routine. and then expose the thing to beta/gamma, and perhaps in a few months it will Do The Right Thing
a111: Logged on 2018-06-11 15:46 asciilifeform: one interesting observation, is that the update mechanism lets you flash in arbitrary crapola into 'rw' section ( it simply won't jump to it if it doesn't pass rsa(sha256(payload)) ) . so theoretically could put a nop sled there, ending with jump into the magic half of unlock routine. and then expose the thing to beta/gamma, and perhaps in a few months it will Do The Right Thing
asciilifeform: one interesting observation, is that the update mechanism lets you flash in arbitrary crapola into 'rw' section ( it simply won't jump to it if it doesn't pass rsa(sha256(payload)) ) . so theoretically could put a nop sled there, ending with jump into the magic half of unlock routine. and then expose the thing to beta/gamma, and perhaps in a few months it will Do The Right Thing ☟︎☟︎☟︎
zx2c4: sha256 isnt an encryption function. also beware this construction, especially the second one where the string comes last -- length extension is a problem with sha2
zx2c4: > For a functional example consider node A, whose "encryption" mechanism consists of sha256(string+"hurr"), and node B, whose encryption mechanism consists of sha256("durr"+string.).
mircea_popescu: admitting the merkle-damgard construction (what ripemd is built out of, see http://homes.esat.kuleuven.be/~bosselae/ripemd160.html ) does not have a backdoor, and that sha256 doesn't have a backdoor, you are looking at something like 256 bits of entropy involved.
mircea_popescu: the proper formula is : address = ripemd160(sha256(secret)). to go from an address to its corresponding private key (which is what "bruteforce" requires in this context) you'd have to reverse a ripemd160 and a sha256 op.
asciilifeform wonders occasionally re the ultimate pressure limit of the reactor. e.g. a sha256 collision is not cheap, but not infinitely expensive either.
asciilifeform: aha, that very same. same work of heathenry as sha256.
asciilifeform: or if one insists : 1 sha256 collision on tx set, and btc similarly.
a111: Logged on 2017-11-23 18:37 whaack: asciilifeform: that fixed the problem, now hash_streams.adb:25:22: "Binary_Message_Digest" not declared in "SHA256"
whaack: asciilifeform: that fixed the problem, now hash_streams.adb:25:22: "Binary_Message_Digest" not declared in "SHA256" ☟︎
phf: src/digests/sha256.lisp
asciilifeform: phf: iirc the sha256 in 'ironclad' is simply a c wrapper around turdssl
asciilifeform: whaack: if you have the time, why not write a sha256 from scratch in cl. it's a needed, unfortunately, piece. and afaik there isn't a proper one published.
asciilifeform: hey if yer gonna take 'presently impossibly difficult' to mean same thing as 'uncomputable', then sha256 is goodenuff
a111: Logged on 2017-08-28 23:39 kanzure: you could safely argue it would look like a plot of the sha256 function against a graph, but i would also be surprised to hear that
kanzure: you could safely argue it would look like a plot of the sha256 function against a graph, but i would also be surprised to hear that ☟︎
andreicon: i mean sha256 and ripemd160 were already available, just hacked into doing something else
sina: !sha256 <set of document URLs>
ben_vulpes: heh, perfectly cranky republican gentleman's sport of code review: nobody will tell you what bugs they found, but they might give you a sha256 description of one
asciilifeform: (replace sha256 hashes with indices on disk, for instance; record 'sequence number' in tx only if differs from default; ditto locktime)
asciilifeform: sha256 gives you... 256 neh
asciilifeform: mircea_popescu: all you need is an x, y, x!=y, where sha256(sha256(x))==sha256(sha256(y)), and x is a valid tx
asciilifeform: the sha256 is balancing for us.
mircea_popescu: ripemd160(sha256()) + sha256(sha256) checksum ? wtf is this bullshit.
asciilifeform: http://btcbase.org/log/2017-02-23#1617193 >> golden lulzies, 'Note that the value of your SHA256, RIPEMD160, RIPEMD160(SHA256()) or SHA256^2 bounty may be diminished by the act of collecting it.' ☝︎
shinohai: "We have prepared $100 million USD to kill the small fork of CoreCoin, no matter what POW algorithm, sha256 or scrypt or X11 or any other GPU algorithm. Show me your money" http://archive.is/gHLrS
Framedragger: (well, the scheme as proposed does use a particular hashing func (sha256), so that part is contestable i suppose.)
phf: (i remember there being a standalone sha256 (?) version for sbcl, but i can't find it now. everything crypto that's coming up re lisp is ironclad.)
phf: actually i'm wrong again, crypt takes special $id$salt$encrypted format, where id is 1/2/5/6 for md5/blowfish/sha256/sha512. on the box where i looked that up all the passwords are $1$
adlai: mircea_popescu: dude there is tons of 'cut stone' here. i don't expect you to visit the non-WoT p2sh.info, but i'll tl;dr for you: there are currently just over 1.8 million btc secured by the goodwill of miners, and a nested ripemd160(sha256(x)) collision
a111: Logged on 2014-10-16 14:00 mircea_popescu: btw, cazalla bingoboingo and everyone else in the same situation : if the blob gpg spits out when you sign contains a SHA1 you are using the older, and perhaps not all that secure digest algo. you should move on to sha512 either with --digest-algo SHA512 or else edit gpg.conf to insert personal-digest-preferences SHA512 SHA384 SHA256
mircea_popescu: did sha256 have an extension attack or am i confusing it
asciilifeform: kmalkki: how did you determine the fact about the sha256 at boot ?
asciilifeform: (in actual practice, i would probably use sha512 or keccak; sha256 was for pedagogic example only)
asciilifeform: https://github.com/froydnj/ironclad/blob/master/src/digests/sha256.lisp << phf is right re current one
phf: hmm, it's all ironclad's sha256. doing it with a dummy #(0 ...) digest drops it to 4.6mb
phf: i suspect that the text marshaling that shell script does (as far as overhead over "pure c") is insubstantial compared to otherwise demanding and ~~cpu level sha256
phf: http://paste.lisp.org/display/327488 lamport parachute PoC in common lisp (it has soft dependency on ironclad for sha256, but otherwise follows the design in that own function can be substituted)
asciilifeform: ( http://phuctor.nosuchlabs.com/gpgkey/6BFB175C42F58F1ABF33255B7DD755C4DE78E5294765EDDBBED2F4B8FDE6B3CF , for the record. and no, they don't let luser adjust key size, it is always 2048, nor the hash - it is always sha256, nor any other knobs save for the username )
Apocalyptic: and i'm comparing to a single iteration of sha256()... so less moving parts
Apocalyptic: asciilifeform: the figure is for sha256(sha256())
Apocalyptic: from the satcoin pape: "The implementation of the above program generates a large CNF formula with about 250'000 variables and 850'000 clauses." I wonder how much lower these numbers would be for a single iteration of sha256
BingoBoingo: shinohai: better, but SHA512 instead of SHA256
ben_vulpes: phf: while i have your attention, do you have any idea how the various SHA256_Init, _Transform functions get into main.cpp?
trinque: this one sha256's the bundle (all messages of that hour separated by single \n), uses that as privkey
punkman: there's a new 8char brainwallet challenge, apparently nobody solved the last one https://keybase.io/warp/warp_1.0.8_SHA256_5111a723fe008dbf628237023e6f2de72c7953f8bb4265d5c16fc9fd79384b7a.html
trinque: yeah, just a matter of taking the deed bundle txt, performing sha256 and using that as the privkey, generating a pubkey and address from that
BingoBoingo: <asciilifeform> what's a ~honest~ mine cost ? << during the Altcoin srs bsns days rented hash with varying relability from https://www.miningrigrentals.com/rigs/sha256
punkman: did we break sha256 yet
Carli-: asciilifeform: i think it is something like this, not sure: SHA256(Seed + 1), Sha256 (seed +2) etc...
felipelalli: brainwallet uses sha256, it is a disaster
assbot: Logged on 03-02-2016 18:52:30; phf: so there's two sig's that are not sha512. genesis.vpatch.trinque.sig is sha256 and polarbeard_add_getpeerinfo_rpc.vpatch.polarbeard.sig is sha1
phf: so there's two sig's that are not sha512. genesis.vpatch.trinque.sig is sha256 and polarbeard_add_getpeerinfo_rpc.vpatch.polarbeard.sig is sha1 ☟︎
ascii_butugychag: interestingly, i fully expected, from 2010 on, folks to gnaw on the leather straps of sha256
ascii_butugychag: what was build on the opened eyes of sha256 hash asic ?
punkman: mutating the merkle root just needs some sha256 hashing though
mircea_popescu: the only reason asics exist is because sha256 you can do by hand on paper.
ben_vulpes: ;;later tell trinque i may be exceptionally retarded today, but is there a reason why shit/Manifest.sha256 doesn't contain a hash for buildroot?
jurov 's bitcoind segfaults in sha256_block_data_order, after properly and completely wiping out stack... now trying gdb's record&replay for first time
mod6: SHA256 (blah.txt) = 827aa4d3ea7c8b7177abe0e2d1d87f45857755df32956fbc54e7a1c10981e6b4
mod6: sha256 blah.txt
buZz: lol cpumining sha256 :)
mod6: in that v_steps.pl file, you'll see the sha256 hashes are kept in a here-doc so they can be repeatedly tested.
adlai wonders whether qntra would be a better venue than deeds for summaries; it has the advantage of requiring review and implying approval, rather than merely inviting sha256 and best-effort backup
mircea_popescu: if i had to bruteforce sha256 to come up with the signature for "trilema.com" i probably wouldn't bother.
adlai: not really. all the blockchain gets is ripemd160(sha256(that))
mircea_popescu: im going to proceed on the grounds that i match that sha256 but srsly...
asciilifeform: (sha256)
mod6: some may notice another interesting thing about the buildroot package hashes (from the above dpaste): many of them differe on algo type. MD5/SHA1/SHA256/SHA512
punkman: trinque: the urls should be in the database, it was base58-encoded sha256 hashes
mircea_popescu: "oh how could you pick sha256!!1"
punkman: davout: sha256 of bundle is the secret exponent
davout: punkman: yeah sure, but what's usually referred to by SHA256 is SHA2 with a 256 bit length
assbot: Logged on 12-10-2015 22:01:06; pete_dushenski: davout: also sha2 != sha256
davout: http://log.bitcoin-assets.com/?date=12-10-2015#1297252 <<< sha256 implements sha2 ☝︎
pete_dushenski: davout: also sha2 != sha256 ☟︎
punkman: "Note that the value of your SHA256, RIPEMD160, RIPEMD160(SHA256()) or SHA256^2 bounty may be diminished by the act of collecting it." heh
assbot: REWARD offered for hash collisions for SHA1, SHA256, RIPEMD160 and other ... ( http://bit.ly/1Pk0VFC )
trinque: er that's sha256 of bundle as the private key
trinque: eats pubkeys or clearsigned messages, farts bundles and transactions to the address derived from the sha256 of bundle as pubkey
trinque: mircea_popescu: it is sha256 of the bundle's deed joined by \n - which is used as a private key - from which the pubkey and address are produced
mod6: SHA256 (rel2-pre-vpatches.tar.gz) = efee5d6f7a442748fb0326f0eb01ad69dc585e896ebadcaa6699af09b495618c
mod6: SHA256 (rel1-vpatches.tar.gz) = 98f234a7ce0210efcd0e841818479a8d7495bb1ef50b90280453d252efccdbb3
mod6: SHA256 (rel2.vpatch) = b951c4a56a362e8f936b65531298a2dad9cb456e3b15118f26ca9f61e5b9a97f
mod6: SHA256 (rel1.vpatch) = 717171ffffce57b7008968a4d8eb2a627f8fe45e4ed8eb15634fd1c1ddf868c5
mod6: now my sha256 manifests match from the original to the one-shot whole orchestra
asciilifeform: the original manifest used sha256
mod6: <+mircea_popescu> yeah, mod you have teh honor. << thanks. I've confirmed that what I get from genesis.vpatch out of thin air is the same manifest as `bitcoin-0.5.3-no-crud.sha256.manifest`.
assbot: Logged on 20-08-2015 02:20:07; hanbot: <mod6> asciilifeform: your step "2)", do you mean to indicate reference [1] instead of "also [3]" which is the email to chicken? << i must be dense, where's "bitcoin-0.5.3-no-crud.sha256.manifest"? i don't see it in 1), i don't see it in 3).
hanbot: <mod6> asciilifeform: your step "2)", do you mean to indicate reference [1] instead of "also [3]" which is the email to chicken? << i must be dense, where's "bitcoin-0.5.3-no-crud.sha256.manifest"? i don't see it in 1), i don't see it in 3). ☟︎
mod6: If that's what you mean. So in this case, SHA1 instead of SHA256, unless that's not what you were referring to.
trinque: the deed transactions spend to an address generated using the sha256 of the bundle as the private key