132 entries in 0.552s
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: 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: it dun have to be
mpfhf so much as i'd like a GOOD alt.
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 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
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 ?
☝︎ 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).
sina: if I make an
mpfhf daemon, then no
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):
ben_vulpes: !W (
mpfhf:
mpfhf #*10101010101010101010101010101010101010 8)
ben_vulpes: !W (
mpfhf:
mpfhf #*10101010101010101010101010101010101010 8)
ben_vulpes: !W (
mpfhf:
mpfhf #*10101010101010101010101010101010101010 8)
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: candi_lustt: (
mpfhf:
mpfhf #*11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 256)
mircea_popescu: candi_lustt: (
mpfhf:
mpfhf #*1111111111111111111111111111111111111111111111111111111111111111 128)
mircea_popescu: candi_lustt: (
mpfhf:
mpfhf #*1111111111111111111111111111111111111111111111111111111111111111 64)
mircea_popescu: candi_lustt: (
mpfhf:
mpfhf #*11111111111111111111111111111111 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: candi_lustt: (
mpfhf:
mpfhf #*11111111111111111111111111111111 16)
mircea_popescu: candi_lustt: (
mpfhf:
mpfhf #*11111111111111111111111111111111 32)
mircea_popescu: candi_lustt: (
mpfhf:
mpfhf #*11111111111111111111111111111111 64)
mircea_popescu: you mean to tell me the idempotent value for
mpfhf is actually ff ?