226 entries in 0.73s
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
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)
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
mod6: i never did get
sha1 of my tape to equal anyone elses that were posted tho
phf: b579b2c553ee2bd3aee8d17d96ae259abfad2ac5 (
sha1 of my solution for ascii's puzzle)
phf: src/digests/
sha1.lisp
davout: "how dja generate key paste URL?" "just
SHA1 the key" :D
a111: Logged on 2015-01-15 00:45 asciilifeform: (what rng? ring oscillator jitter, with
sha1 whitening.)
veen: is this new as of the
SHA1 nooze yesterday?
a111: Logged on 2016-08-18 00:38 asciilifeform: mod6: all pgptrons live and die by
sha1.
mats: i lost some coin betting against the
sha1 collision
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.
mod6: and
SHA1 checksums? wtf is this, the 90s?
pete_dushenski just received email with marketing photos from winnipeg architect with
sha1 checksum(!). not sha512 but still highly unexpected.
mod6: <+asciilifeform>
SHA1 manifest, of course. << lol. i do some shitshoveling at a place that still uses md5 and
sha1 at all times.
mircea_popescu: ya, sure. find me the man who wasn't using
sha1 in 2011.
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.
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
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 mrottenkolber: Naive question: what would be the implications of using
sha1 instead of sha512 in vdiff? (thinking about porting V to git hooks/aliases)