tmsr - Search: sha1

226 entries in 0.53s

asciilifeform: 2) http://therealbitcoin.org/ml/btc-dev/attachments/20160128/asciilifeform_shiva_part_1_of_2.vpatch?sha1=8d22942ffc97296845fad81c3a78acfdf54af23a

ben_vulpes: Jacmet: another thing worth pointing out are that sha1 and md5 are obsolete

ben_vulpes: my sha1 and md5 match those in k's .sign

asciilifeform: i.e. different sha512 but same sha1/md5 ?

mod6: SHA1 & MD5 are broken are they not?

mod6: the md5 & sha1 match the sign file

mod6: heh, these guys built this huge thing, but their sign files only have SHA1 & MD5, even the most recent 2016.02

mod6: anyway, i guess i don't mind, i can add a part where we check the SHA1 & MD5 of the buildroot artifact and then continue to verify that .sign file.

phf: ben_vulpes: they are like md5 and sha1

punkman: like this http://therealbitcoin.org/ml/btc-dev/attachments/20160128/asciilifeform_shiva_part_2_of_2.vpatch?sha1=abc9c21e3c86e7a540b20e49a6ebc86017758e48

assbot: Logged on 04-02-2016 12:02:26; polarbeard: http://log.bitcoin-assets.com/?date=03-02-2016#1395785 << thanks, I've fixed it now, I had no idea it used sha1 by default...

polarbeard: http://log.bitcoin-assets.com/?date=03-02-2016#1395785 << thanks, I've fixed it now, I had no idea it used sha1 by default... ☝︎☟︎

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 ☟︎

jurov: sha1 because i wanted to track files by contents and sha1 was at hand

ascii_butugychag: jurov: also why do we have sha1 in the mix

jurov: not really, sigs were supposed to carry SHA1 of the patch they apply to

jurov: so won't you take exception with branches in lxr named vpatchname_YYYMMMDD or vpatchname_SHA1 ?

mircea_popescu: mod6 http://therealbitcoin.org/ml/btc-dev/attachments/20160128/v.pl?sha1=6c20a367bb0788fb6343754f1bd3034a3544c277 << would be this right ?

jurov: deedbot-: http://therealbitcoin.org/ml/btc-dev/attachments/20160201/201601.txt.asc?sha1=295f2ea0b44fc825f052392229d3dc61cf9a2744

mod6: ah, that's right. busybox pacakge spit out both md5 and sha1

mod6: busybox-1.23.2.tar.bz2: OK (sha1: 7f37193cb249f27630e0b2a2c6c9bbb7b1d24c16)

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

asciilifeform: and did the schmuck really go with dsa + sha1 ??!!!

pete_dushenski: "winbloze CONSIDERS deprecating sha1". so it's on the table. just so you know.

assbot: Logged on 03-11-2015 16:33:06; *: adlai has exceeded his daily allotment of manual sha1 preimage mining

adlai has exceeded his daily allotment of manual sha1 preimage mining ☟︎

mircea_popescu: incidentally sha1

ascii_field: l0l explicitly pushes sha1?!!

asciilifeform: it'll be more of a thing once we get the sha1 out of the loop though.

assbot: Logged on 12-10-2015 21:59:05; pete_dushenski: davout: "According to Schneier it costed ~$3mn in 2012 to find an arbitrary SHA1 collision." << cost

asciilifeform: the fp is a sha1

punkman: I don't see any mention of sha1 in the rfc regarding subkey sigs etc

asciilifeform: both are hardcoded to use sha1.

assbot: Logged on 12-10-2015 22:51:13; punkman: btw if you don't want the signatures on your subkeys being sha1, I think --cert-digest-algo is the option that needs changing

punkman: btw if you don't want the signatures on your subkeys being sha1, I think --cert-digest-algo is the option that needs changing ☟︎

pete_dushenski: davout: "According to Schneier it costed ~$3mn in 2012 to find an arbitrary SHA1 collision." << cost ☟︎

asciilifeform: nor is anything else about the current implementation (what is signed is IN ALL CASES a sha1 of the key-to-be-signed) sane.

assbot: Logged on 09-10-2015 01:56:06; asciilifeform: my original observation, though, stands - the time to stop thinking of pgp 64bit fp as 'the man' is not when arbitrarily colliding sha1 costs a penny! it is now.

asciilifeform: the other thing is, to the extent that the integrity of the wot as we now have it is predicated on sha1 not costing a penny to break, some of the sweat that went in to forming the wot may end up having to be re-sweated

asciilifeform: my original observation, though, stands - the time to stop thinking of pgp 64bit fp as 'the man' is not when arbitrarily colliding sha1 costs a penny! it is now. ☟︎

assbot: how close is OpenPGP tied to SHA1 ... ( http://bit.ly/1jeUdnW )

asciilifeform: it does not contain the modulus he signs with. only bottom 64b of the sha1 of....

asciilifeform: which is hardcoded to sha1..

asciilifeform: mircea_popescu: cost of a sha1 collision is less than a year of schmuck pay at this point.

assbot: REWARD offered for hash collisions for SHA1, SHA256, RIPEMD160 and other ... ( http://bit.ly/1Pk0VFC )

assbot: Logged on 24-09-2015 14:12:48; asciilifeform: http://log.bitcoin-assets.com/?date=24-09-2015#1284625 << aha. but ever notice that it's sha1, and can't be changed to anything else? and, likewise, self-sigs are hardcoded to use sha1? it is pestilentially pervasive in the rfc, and Must Die

assbot: Logged on 25-09-2015 01:45:37; asciilifeform: http://log.bitcoin-assets.com/?date=25-09-2015#1285102 << presently they are quite unlike! hash type for general-purpose message signing is ~selectable~ from the handful of traditional algos; hash for signature ~of keys~ is hardwired to sha1 !

assbot: Logged on 25-09-2015 00:28:18; mircea_popescu: http://log.bitcoin-assets.com/?date=24-09-2015#1284796 << i suspek that's what they were trying to do with the sha1.

asciilifeform: http://log.bitcoin-assets.com/?date=25-09-2015#1285102 << presently they are quite unlike! hash type for general-purpose message signing is ~selectable~ from the handful of traditional algos; hash for signature ~of keys~ is hardwired to sha1 ! ☝︎☟︎

mircea_popescu: http://log.bitcoin-assets.com/?date=24-09-2015#1284796 << i suspek that's what they were trying to do with the sha1. ☝︎☟︎

asciilifeform: http://log.bitcoin-assets.com/?date=24-09-2015#1284625 << aha. but ever notice that it's sha1, and can't be changed to anything else? and, likewise, self-sigs are hardcoded to use sha1? it is pestilentially pervasive in the rfc, and Must Die ☝︎☟︎☟︎

mod6: If that's what you mean. So in this case, SHA1 instead of SHA256, unless that's not what you were referring to.

mod6: <+hanbot> re ml: where are sha256sums for, eg, http://therealbitcoin.org/ml/btc-dev/2015-February/000040.html (patch)? << Hi, in the case of that patch email, the SHA1 sum is embedded in the file name. For example: asciilifeform_dnsseed_snipsnip_192f7bc7c14c1d31c7b417c9cd77be51c4d255f2.patch -- if you were to download this patch, you could then run `sha1sum asciilifeform_dnsseed_snipsnip_192f7bc7c14c1d31c7b417c9cd77be51c4d255f2.patch` and it sh

ben_vulpes: sha1 matches the value in the providers sig tho

trinque: tls 1.0, sha1 sigs, lol

trinque: dat sha1

mod6: there alredy was one there. i can add a new one, but then ofc your sha1 wont match. no worries, will try.

jurov: ah that. so, thinking about ECL, one basically needs to put together 2x80 identical circuits for two rouds of SHA1, and pipeline them, no?

asciilifeform: sha1

assbot: Logged on 05-05-2015 01:25:57; asciilifeform: <danielpbarron> there's yer answer: it's sha1 << why do we have sha1 anywhere

mod6: it's fine, I just didn't realize that in the filename, the turdolator uses SHA1

asciilifeform: <danielpbarron> there's yer answer: it's sha1 << why do we have sha1 anywhere ☟︎

mod6: ah sha1, see, derp derperton

danielpbarron: there's yer answer: it's sha1; not sha256

jurov: i don't get it. "by content addressable" i understand somthing like putting sha1 sum in the URL

jurov: trinque, it uses SHA1 as ID

jurov: that's sha1 hash

BingoBoingo: funkenstein_: Edit your GPG conf file to switch from SHA1 to a better message digest

assbot: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As of AD 347694 I am funkenst - Pastebin.com ... ( http://bit.ly/18NN0Wj )

mircea_popescu: <asciilifeform> (what rng? ring oscillator jitter, with sha1 whitening.) <<< better than many

asciilifeform: (what rng? ring oscillator jitter, with sha1 whitening.) ☟︎

assbot: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This is deeds.bitcoin-a - Pastebin.com

punkman: re: sha1 and gpg settings, this is useful https://github.com/coruus/cooperpair/blob/master/saneprefs/gpg.conf

mircea_popescu: asciilifeform yeah, and suppose you see a message from me using sha1 when you know i use sha512.

asciilifeform: since my key flag bits permit sha1, he can still, say, sign into gribble as me.

asciilifeform: problem is, let's say the devil has sha1 collision finder, and decides to apply to my case

pete_dushenski wonders why mod6 and asciilifeform signed the tithe3 with SHA1...

assbot: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Title: BITCOIN DECLARATION OF - Pastebin.com

assbot: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Report 7. November 2nd, 2014 - Pastebin.com

assbot: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 BitBet (S.BBET) October 2014 S - Pastebin.com

assbot: 4 results for 'from:mircea_popescu sha1' : http://search.bitcoin-assets.com/?q=from%3Amircea_popescu+sha1

thestringpuller: !s from:mircea_popescu sha1

assbot: Logged on 16-10-2014 14:00:51; 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

assbot: 30 results for 'sha1' : http://search.bitcoin-assets.com/?q=sha1

mircea_popescu: !s sha1

Apocalyptic: just noticed that all deeds processed by deadbot are SHA1-hashed so far

bounce: sha1 is on the way out (don't use for new stuff) but not dead yet (can keep using what you have)

Apocalyptic: by the way are SHA1 gpg-signed messages considered read ? I read somewhere one might rather use sha256 or higher, don't know if there's any merit to that claim

jurov: 15033115709f0eb55674ebf5e79208bfb05a5745 bitcoin-0.5.3-linux.tar.gz << sha1 of the turd form there

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 ☟︎☟︎

assbot: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Beginning Balances: ATC: 2042 - Pastebin.com

assbot: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Testing - -----BEGIN - Pastebin.com