log☇︎
226 entries in 0.789s
feedbot: http://qntra.net/2020/01/sha1-collisions-get-cheaper/ << Qntra -- SHA1 Collisions Get Cheaper
ossabot: Logged on 2019-10-22 06:39:48 diana_coman: http://logs.ossasepia.com/log/trilema/2019-10-22#1947561 - I can see that; my thinking was not towards using sha1 but more towards permitting other-than-serpent mainly because 1. serpent is still snake-oil and only adopted-for-lack-of-better option afaik b. maybe tmsr makes its own hash function next year or something (ha!)
bvt: http://logs.ossasepia.com/log/trilema/2019-10-22#1947572 << allowing arbitrary hash functions would create more bloat -- either i'd have to use some generic crypto abstractions, or hack up the build system and unconditionally enable all the accepted crypto algos at build time to use them directly. it's only chacha and sha1 that are located among e.g. memcpy in lib/ and available uncoditionally. the rest
bvt: http://logs.ossasepia.com/log/trilema/2019-10-22#1947551 << well yes, sha1 is making FG bottleneck much worse.
ossabot: Logged on 2019-10-22 02:29:31 mp_en_viaje: http://bvt-trace.net/2019/10/fg-fed-linux-rng/ << the most important q here is, are we going to mandate serpent ? or are we going to permit legacy sha1/chacha ?
ossabot: Logged on 2019-10-22 02:29:31 mp_en_viaje: http://bvt-trace.net/2019/10/fg-fed-linux-rng/ << the most important q here is, are we going to mandate serpent ? or are we going to permit legacy sha1/chacha ?
ossabot: Logged on 2019-10-22 06:24:44 mp_en_viaje: diana_coman, a) to avoid the sha1-powered contraction ; b) to reject, discontinue and clearly mark as untenable pantsuit heritage ; c) to disrupt any possible legacy of usgistani shenanigans in the output ; d) to give meaning to the notion of computer identity ("a computer's key is the hash of the sig it uses to serpent its rng code") and e) for simplicity (one mechanism instead of two as now)
diana_coman: http://logs.ossasepia.com/log/trilema/2019-10-22#1947561 - I can see that; my thinking was not towards using sha1 but more towards permitting other-than-serpent mainly because 1. serpent is still snake-oil and only adopted-for-lack-of-better option afaik b. maybe tmsr makes its own hash function next year or something (ha!)
mp_en_viaje: diana_coman, a) to avoid the sha1-powered contraction ; b) to reject, discontinue and clearly mark as untenable pantsuit heritage ; c) to disrupt any possible legacy of usgistani shenanigans in the output ; d) to give meaning to the notion of computer identity ("a computer's key is the hash of the sig it uses to serpent its rng code") and e) for simplicity (one mechanism instead of two as now)
mp_en_viaje: http://bvt-trace.net/2019/10/fg-fed-linux-rng/ << the most important q here is, are we going to mandate serpent ? or are we going to permit legacy sha1/chacha ?
a111: Logged on 2017-10-02 00:49 asciilifeform: the funniest bit is that anybody who spends a few $10k to find sha1 collision, can take it one step further and make a valid subkey for asciilifeform's, or mircea_popescu's, etc. key
a111: Logged on 2018-09-29 23:17 trinque: asciilifeform: what do you have for curl 'http://therealbitcoin.org/ml/btc-dev/attachments/20180923/mod6_excise_hash_truncation.vpatch?sha1=9abdb060135507152b9a5c7c3b8b98966266c5bd'
trinque: asciilifeform: what do you have for curl 'http://therealbitcoin.org/ml/btc-dev/attachments/20180923/mod6_excise_hash_truncation.vpatch?sha1=9abdb060135507152b9a5c7c3b8b98966266c5bd' ☟︎
asciilifeform: other potentially-interesting stabs in the dark include nextprime(sha1/2(dictionarypassword)) and the like.
asciilifeform: pointerolade, spinlock, sha1, you name it , it's got it...
asciilifeform: ... and sha1 hash setting means that anybody with a few thou usd can impersonate b41e209ccc264812 .
asciilifeform: without dsa, elgamal, sha1.
asciilifeform: holyfuq, dsa + elgamal + sha1
lobbes: Added sha1 checksum values for the .zips to show in archive search results >> http://lobbesblog.com/queryarchive/view.php?searchterm=example&sortby=
mod6: i never did get sha1 of my tape to equal anyone elses that were posted tho
asciilifeform: nao asciilifeform wonders if there's an irc net that requires you to, say, collide a sha1, before you can log in
phf: b579b2c553ee2bd3aee8d17d96ae259abfad2ac5 (sha1 of my solution for ascii's puzzle)
asciilifeform: and, bonus, sha1 flag for sigs
phf: src/digests/sha1.lisp
davout: "how dja generate key paste URL?" "just SHA1 the key" :D
asciilifeform: 20-50k usd gets you another 17215D118B7239507FAFED98B98228A001ABFFC7-sha1 but diff modulus.
asciilifeform: observe the mendacious idiocy of koch's signature code, where if sha1 hash collision is found , can forge sigs ~regardless of what sig algo hashing was set to~
asciilifeform: all stuck with sha1 4evah
asciilifeform: rfc specified sha1.
asciilifeform: davout: it's a sha1
asciilifeform: the funniest bit is that anybody who spends a few $10k to find sha1 collision, can take it one step further and make a valid subkey for asciilifeform's, or mircea_popescu's, etc. key ☟︎
asciilifeform: ( 'breaking into wallets' apparently consists of searching for sha1 puzzles )
a111: Logged on 2015-01-15 00:45 asciilifeform: (what rng? ring oscillator jitter, with sha1 whitening.)
asciilifeform: (say, when we look for sha1 collisions in pgpland)
asciilifeform: '@aeliasen @gnupg for fingerprints collisions are not interesting. There is no known preimage attack for SHA1. Keep calm and use OpenPGP.' << lel
asciilifeform: 'Thursday's watershed attack on the widely used SHA1 hashing function has claimed its first casualty: the version control system used by the WebKit browser engine, which became completely corrupted after someone uploaded two proof-of-concept PDF files that have identical message digests.'
asciilifeform: in other lulz: https://arstechnica.com/security/2017/02/watershed-sha1-collision-just-broke-the-webkit-repository-others-may-follow
deedbot: http://qntra.net/2017/02/fire-in-the-security-theater-cloudflare-leaks-as-sha1-broken/ << Qntra - Fire In The Security Theater: Cloudflare Leaks As SHA1 Broken
veen: is this new as of the SHA1 nooze yesterday?
asciilifeform: became a serious itch for asciilifeform when he watched a sha1 collision get crapped out on demand, for minor project, at butugychag 1+ yr ago
a111: Logged on 2016-08-18 00:38 asciilifeform: mod6: all pgptrons live and die by sha1.
asciilifeform: the sha1 people posted the algo. shouldn't take too much work to turn it into a, e.g., gpg fp clobberer.
mats: i lost some coin betting against the sha1 collision
a111: 181 results for "sha1", http://btcbase.org/log-search?q=sha1
asciilifeform: !#s sha1
jurov: !!deed http://therealbitcoin.org/ml/btc-dev/attachments/20170201/attachment.txt?sha1=41c6fd5bc887251867bff5577e5af04c66ce8a7d
jurov: deedbot: http://therealbitcoin.org/ml/btc-dev/attachments/20170201/attachment.txt?sha1=41c6fd5bc887251867bff5577e5af04c66ce8a7d
a111: Logged on 2017-01-09 09:32 ben_vulpes: heh which reminds me: http://therealbitcoin.org/ml/btc-dev/attachments/20170101/attachment.txt?sha1=054f90b71ea58b51b3dd37774b495d5f7e85afee << zero income foundation carries on the zero asset legacy :P
ben_vulpes: heh which reminds me: http://therealbitcoin.org/ml/btc-dev/attachments/20170101/attachment.txt?sha1=054f90b71ea58b51b3dd37774b495d5f7e85afee << zero income foundation carries on the zero asset legacy :P ☟︎
jurov: !!deed http://therealbitcoin.org/ml/btc-dev/attachments/20170101/attachment.txt?sha1=054f90b71ea58b51b3dd37774b495d5f7e85afee
asciilifeform: (pss-verify :sha1 (subseq msg start end) s)) ....
asciilifeform: phf: but! why in satan's name does it hardcode sha1 for rsa verify
asciilifeform: or, alternatively, a much easier sha1 collision, in which case i only fool ~all extant gpg clients~ but not a d00d with magnifying glass actually multiplying out the rsa
jurov: !!deed http://therealbitcoin.org/ml/btc-dev/attachments/20161201/attachment.txt?sha1=3ebec7e118a9f69ad2fe87574a11430a955fae9e
jurov: deedbot: http://therealbitcoin.org/ml/btc-dev/attachments/20161201/attachment.txt?sha1=3ebec7e118a9f69ad2fe87574a11430a955fae9e
mircea_popescu: !!deed http://therealbitcoin.org/ml/btc-dev/attachments/20161031/attachment.txt?sha1=1d162614ad096063e9abb5746b6deab291037beb
mircea_popescu: !!deed http://therealbitcoin.org/ml/btc-dev/attachments/20161101/attachment.txt?sha1=9791c267cc8e30958838c77653f6342a09244fb5
mircea_popescu: in other "holy shit open source" news : to run a linux repo, you must provide... md5hashes for the stuff, because... apt-get wants it. fancy that. and by default you get that and sha1. because it's fucking 1995 and there's a thousand fly eyes!
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
PeterL: is there a way to make pgp use something other than sha1 for clearsigning?
shinohai: The silkworms in this area are only capable of sha1, I need better worms.
asciilifeform: encouraging the use of sha1.
asciilifeform: and so all you need to forge a signature is a sha1 collision.
asciilifeform: mod6: all pgptrons live and die by sha1. ☟︎
mod6: and SHA1 checksums? wtf is this, the 90s?
asciilifeform: (recall how sha1 ended up perma-fixed in pgp.)
asciilifeform: (sha1 thereof, rather.)
asciilifeform: (yes you can swap out sha1 for 512 in own sigs, but what if i want to sign ACTUAL datum, not hash?)
asciilifeform: well, the way it is done in gpg (rsa sig of sha1) is indeed retarded
pete_dushenski just received email with marketing photos from winnipeg architect with sha1 checksum(!). not sha512 but still highly unexpected.
trinque: $deed http://therealbitcoin.org/ml/btc-dev/attachments/20160702/attachment.txt?sha1=bb9dab320ed2b6c070546085d4e673871180a6e9
jurov: deedbot: http://therealbitcoin.org/ml/btc-dev/attachments/20160702/attachment.txt?sha1=bb9dab320ed2b6c070546085d4e673871180a6e9
asciilifeform: with ANY of the sha1 from the total set of signatures publicly known for key K
asciilifeform: mircea_popescu: all it'd take is a sha1 collision
jurov: deedbot: http://therealbitcoin.org/ml/btc-dev/attachments/20160601/attachment.txt?sha1=af8606ade95cc571a9b29f0570d3c783a29c0ffe
mod6: <+asciilifeform> SHA1 manifest, of course. << lol. i do some shitshoveling at a place that still uses md5 and sha1 at all times.
asciilifeform: SHA1 manifest, of course.
asciilifeform: with its hardbaked sha1 etc.
mircea_popescu: sha1.
jurov: deedbot-: http://therealbitcoin.org/ml/btc-dev/attachments/20160401/attachment.txt?sha1=c2d703eeb8d0553a3e66e2a981b99efe2f94b155
mircea_popescu: ya, sure. find me the man who wasn't using sha1 in 2011.
pete_dushenski: SHA1 ?!
asciilifeform: (sha1 collision)
mrottenkolber: oh its late, it uses sha1 obviously but not on plain files >.>
mrottenkolber: Which is probably less cryptographically “secure” as sha1 (wild guess)
mrottenkolber: So I learned today that git does't use sha1 as I thought, but its own git-hash-object
mircea_popescu: mrottenkolber> Naive question: what would be the implications of using sha1 instead of sha512 in vdiff? << roughly speaking you'd be going back in time, we're by and large in the process of moving to sha-3
mrottenkolber: But e.g. in my head, if you spend 70k to compute a sha1 collision, it won't look like C code probably ;-)
mrottenkolber: I am only mentioning the sha1 option because I don't understand crypto well enough to be able to rationalize the effort of producing a file, with the same sha1sum, with an exploit while the patch still applies.
asciilifeform: phf: thing is that i have no intention of ignoring the sha1 issue. sha1 is ~broken~.
phf: asciilifeform: well, you can verify data without verifying git. i've done it, and the thing definitely produces a semblance of "blockchain", i.e. later commits hashes previous commits' hashes, so you can if you ignore the sha1 issue, take a git branch and confirm its uniqueness from the final hash
asciilifeform: phf: not only are git hashes sha1, but git itself is a gigantic bag of ?????.
phf: mrottenkolber: if that's your only goal, you don't need v for that. git already does it for you by having a linearly hashed commit chain. right now you have a reasonable way of verifying the git chain from the top hash, but you can't make any crypto claims about it, since the hashes are sha1
asciilifeform: and yes, you are free to replace the hash with sha1 or md5 or crc32 or whatever, just like you are free to buy a toyota and drive it off a cliff
asciilifeform: mrottenkolber: sha1 is obsolete
mrottenkolber: Naive question: what would be the implications of using sha1 instead of sha512 in vdiff? (thinking about porting V to git hooks/aliases)
asciilifeform: (summary: article elementarily demonstrates that a hash of the sha1 type could be designed with trapdoor. and then argues nonsensically that we 'know' there could have been none such.)
jurov: deedbot-: http://therealbitcoin.org/ml/btc-dev/attachments/20160301/attachment.txt?sha1=675d9675e9151a4adf860e168aada54d33925369
asciilifeform: 4) http://therealbitcoin.org/ml/btc-dev/attachments/20160131/asciilifeform_shiva_fix_flag_bug.vpatch?sha1=8e9f57bf90fc32f4c3bdd88adfb449edd3b93e3c
asciilifeform: 3 ) http://therealbitcoin.org/ml/btc-dev/attachments/20160128/asciilifeform_shiva_part_2_of_2.vpatch?sha1=abc9c21e3c86e7a540b20e49a6ebc86017758e48