132 entries in 0.58s

a111: Logged on 2017-11-13 17:47 ben_vulpes: and in ancients, dusted off mpfhf benchmarker, finished the bit-banging of inputs, fired off a run late last week that is *still hashing*

a111: Logged on 2017-11-13 17:47 ben_vulpes: and in ancients, dusted off mpfhf benchmarker, finished the bit-banging of inputs, fired off a run late last week that is *still hashing*

ben_vulpes: and in ancients, dusted off mpfhf benchmarker, finished the bit-banging of inputs, fired off a run late last week that is *still hashing* ☟︎☟︎

ben_vulpes: i'd rather get back to profiling mpfhf than marketing a cabinet

mircea_popescu: (this being something i suspect mpfhf fambly MAY be amenable to proving, but i've yet to get anywhere)

mimisbrunnr: Logged on 2017-09-02 16:41 mircea_popescu: one major point is that other than mpfhf which has been well implemented thanks to peterl, sina and ben_vulpes (and to some degree researched -- speaking of which, still cooking ben_vulpes ?), there's keccak which HASNT yet been implemented much ; and we really could use a fixed-block hash function that's any good.

a111: Logged on 2017-09-02 16:44 mircea_popescu: one major point is that other than mpfhf which has been well implemented thanks to peterl, sina and ben_vulpes (and to some degree researched -- speaking of which, still cooking ben_vulpes ?), there's keccak which HASNT yet been implemented much ; and we really could use a fixed-block hash function that's any good.

mircea_popescu: one major point is that other than mpfhf which has been well implemented thanks to peterl, sina and ben_vulpes (and to some degree researched -- speaking of which, still cooking ben_vulpes ?), there's keccak which HASNT yet been implemented much ; and we really could use a fixed-block hash function that's any good. ☟︎

mircea_popescu: and by no means mpfhf only settable. keccak will work also.

mircea_popescu: and besides, with a settable hash like mpfhf you can use different size hashes all the time.

PeterL: So, if anybody was going to try the reverse mpfhf I posted yesterday, it does not work

mircea_popescu: anyway. other than the above "can constantify mpfhf ?" question, also open is the matter of alternative padding. currently all we have is oaep.

a111: Logged on 2017-08-15 22:52 mircea_popescu: constant-time MPFHF is now an open question for teh interested.

mircea_popescu: the ONE way to constant-mpfhf is to calculate ALL the tree of possibilities, 2^message length items EVERY TIME

mircea_popescu: mpfhf varies.

mircea_popescu: it dun have to be mpfhf so much as i'd like a GOOD alt.

mircea_popescu: now to the graver matter of mpfhf. http://trilema.com/2017/tmsr-rsa-spec-extremely-early-draft/#comment-122645

mircea_popescu: o hey peterl got teh mpfhf reverser done.

PeterL: http://p.bvulpes.com/pastes/ZI0Qx/?raw=true << reverse mpfhf hash function, given R, S, and length of message

mircea_popescu: oh, and the mpfhf!

a111: Logged on 2017-08-09 15:58 mircea_popescu: anyway, let it be said that there's nothing wrong with oaep as far as we know, but for the sake of argument a mpfhf based padding scheme would conceivably work like this : 1. given message m, of length l, generate r = random bits, of length l' up to l but not less than 256 bits. 2. compose m' = r + m + c (in that order), where c is l - l` (and its bitness is always same as the bitness of len(m')-256). 3. compose Pm = R + S +

mircea_popescu: reversing mpfhf is required for the padding scheme originally described, whereby you simply mpfhf the plaintext message and then encrypt the S + R, see http://btcbase.org/log/2017-08-09#1695856 ☝︎

mircea_popescu: reversing MPFHF is not required for the above quoted version, as the fhf is used there as a hash function not as a padder. (and alf's objection is valid, not a very good option, a settable size output sponge would be much better).

PeterL: and wouldn't you also need to know S if you are going to reverse the MPFHF from a given R?

a111: Logged on 2017-08-09 22:09 mircea_popescu: to encrypt : take plaintext message M, no longer than 250 bytes, and zero-pad it to 250 bytes. take pile of random bits R 250 bytes long. calculate X = M xor R. calculate Y = R xor MPFHF(X) set for R.len = 250 bytes. RSA the 500 byte pile of X || Y. done. to decrypt : de-RSA the 500 byte pile. cut it in two halves. calculate R = Y xor X. calculate M as X xor R. done.

mircea_popescu: asciilifeform i guess when he comes back from the mpfhf reverser ima make him do a keccak impl that ACTUALLY does the any-output thing. afaik they're all 32/64byte

mircea_popescu: to encrypt : take plaintext message M, no longer than 250 bytes, and zero-pad it to 250 bytes. take pile of random bits R 250 bytes long. calculate X = M xor R. calculate Y = R xor MPFHF(X) set for R.len = 250 bytes. RSA the 500 byte pile of X || Y. done. to decrypt : de-RSA the 500 byte pile. cut it in two halves. calculate R = Y xor X. calculate M as X xor R. done. ☟︎

PeterL: I will have a look at making a reversing function for the mpfhf

mircea_popescu: PeterL so if you feel like writing a mpfhf reverser... afaik nobody has to date.

mircea_popescu: c (in that order), where R and S are produced by mpfhf(m') with R len set to c (bitness same as bitness of len(Pm). Pm will be the padded message sent to RSA. The recipient will have to undo mpfhf with known R and S to obtain m.

mircea_popescu: anyway, let it be said that there's nothing wrong with oaep as far as we know, but for the sake of argument a mpfhf based padding scheme would conceivably work like this : 1. given message m, of length l, generate r = random bits, of length l' up to l but not less than 256 bits. 2. compose m' = r + m + c (in that order), where c is l - l` (and its bitness is always same as the bitness of len(m')-256). 3. compose Pm = R + S + ☟︎

mircea_popescu: because hash and hash' are used to stretch/reduce the bitlength of their parameters, something like mpfhf (which permits arbitrary sized outputs/inputs) could work well ; but is also slow.

PeterL: it does not run mpfhf on packets, that was just a way to hash to get a name for keys

asciilifeform: also running mpfhf on incoming packets is lulzy

mircea_popescu: how long was mpfhf, fifty lines ?

mircea_popescu: anyway : ready way to blow this out of water. human can compute mpfhf by hand ; not reversable.

mircea_popescu: the best and handiest way to illustrate this folly is, "imagine if your vlc tried to mpfhf every film you played"

mircea_popescu: http://btcbase.org/log/2017-07-09#1680947 << actually this is interesting, and i mean from a metaperspective. consider, randomly defined cult, they come up with some crankwagen, whatever it may be, say the mpfhf or the correct way rto diet or to cure cancer or w/e. at which point ranking member promises to come out with proof it's shit, and the result is ? ☝︎

mircea_popescu: you think mpfhf was in php ?

sina: same for mpfhf

PeterL: http://wotpaste.cascadianhacker.com/pastes/S4MzV/?raw=true << mpfhf in python , I was thinking about http://btcbase.org/log/2017-07-05#1679471 and flipping a single bit instead of going through the whole array ☝︎

phf: but i'm trying to reproduce "single threaded mpfhf-golang can provide a 32-bit mpfhf hash of GPLv2 in ~7m" on my machine

mircea_popescu: http://btcbase.org/log/2017-07-04#1679092 << my current thinking is, the only way to resolve this within a lifetime is to see if a mpfhf cycle could be constructed. if it can, solved, if it provably can't then it is time&space finite, even as a statistical ceiling argument. ☝︎

mircea_popescu: this is computationally worse than mpfhf though. imagine, nextprime(todays log).

a111: Logged on 2017-07-02 07:58 ben_vulpes: https://github.com/sinner-/mpfhf-python/blob/master/LICENSE << hey sina ever read http://trilema.com/2015/a-new-software-licensing-paradigm/#selection-75.0-83.128 ?

sina: ben_vulpes: now enabled "python mpfhf.py <message> <bits> <time|notime>" (https://github.com/sinner-/mpfhf-python/commit/a8c37e51e3a893785519052f939c222c2178168a) and "mpfhf-golang -message <message> -bits <bits> -time <y|n>" (https://github.com/sinner-/mpfhf-golang/commit/674a502a93c63de8dacbb07e5eb9a62eb5dbee58)

ben_vulpes: https://github.com/sinner-/mpfhf-python/blob/master/LICENSE << hey sina ever read http://trilema.com/2015/a-new-software-licensing-paradigm/#selection-75.0-83.128 ? ☟︎

sina: if I make an mpfhf daemon, then no

mircea_popescu: rsa is > mpfhf

mircea_popescu: o boy. what size would a mpfhf capable item occupy ?

mircea_popescu: that is a fine example. or, you know, calculate the mpfhf over the gutenberg collection.

mircea_popescu: if no more changes, shit left to do re mpfhf : a) do some proper profiling work, with timings etc. could make a great blog article. b) try and break it, like any hash. could make a bnunch of great blog articles (tried this, so and so, didn't work -- can do this 500 times).

sina: mircea_popescu: next q was where live, for me pls github.com/sinner-/mpfhf-python and github.com/sinner-mpfhf-golang

sina: in mpfhf-python: for i in range(0, count):

sina: I'm trying to remember that thing you said when I was asking about the php mpfhf

sina: funsies was being able to bang out a golang mpfhf because I had already kicked the tyres on the lang

sina: you need to set a GOPATH variable, e.g export GOPATH=~/Development/go and then clone the repo to $GOPATH/src/github.com/sinner-/mpfhf-golang

ben_vulpes: > ./mpfhf.go:52: syntax error: unexpected EOF, expecting expression

mircea_popescu: it's really not so different from yest when you and ben_vulpes were working on the mpfhf.

deedbot: mircea_popescu updated rating of sina from 1 to 2 << MPFHF canonical implementation.

mircea_popescu: !!rate sina 2 MPFHF canonical implementation.

mircea_popescu: candi_lustt: (mpfhf:mpfhf #*11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 256)

mircea_popescu: candi_lustt: (mpfhf:mpfhf #*1111111111111111111111111111111111111111111111111111111111111111 128)

mircea_popescu: candi_lustt: (mpfhf:mpfhf #*1111111111111111111111111111111111111111111111111111111111111111 64)

sina: lol...the 2048 bit hash for GPLv2 was taking a really long time so I killed it to add some print statements. Checked "wc -c LICENSE", it reports ~18,000 chars. I re-ran mpfhf with 32 bits, thinking it'd finish at M_pos ~18,000

mircea_popescu: though in principle the mpfhf is a function fambly -- anyone can make any sort of thing he wants

mircea_popescu: try <mircea_popescu> candi_lustt: (mpfhf:mpfhf #*11111111111111111111111111111111 64)

sina: candi_lustt: (mpfhf:mpfhf #*1001101101000010000011010111101001110001111010111110011100000110000111100111110011100001 32)

sina: candi_lustt: (mpfhf:mpfhf #*1001101101000010000011010111101001110001111010111110011100000110000111100111110011100001 64)

sina: candi_lustt: (mpfhf:mpfhf #*1001101101000010000011010111101001110001111010111110011100000110000111100111110011100001 32)

sina: candi_lustt: (mpfhf:mpfhf #*1001101101000010000011010111101001110001111010111110011100000110000111100111110011100001 64)

mircea_popescu: you mean to tell me the idempotent value for mpfhf is actually ff ?