254 entries in 0.589s
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."
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
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: 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.
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
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
mircea_popescu: ripemd160(
sha256()) +
sha256(
sha256) checksum ? wtf is this bullshit.
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
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)
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
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
Carli-: asciilifeform: i think it is something like this, not sure:
SHA256(Seed + 1),
Sha256 (seed +2) etc...
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 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
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...
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
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 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
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
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