79 entries in 0.861s
diana_coman: ... that; for illustration, here's the
output from vtree and antecedents on eucrypt_oaep_fix_checks.vpatch (ran in the same test dir that can be had from
here); antecedents gives the correct path genesis->ch6->ch7->ch9->ch10->oaep_fix_checks, but in vtree's output it's very hard to tell that ch10 is meant as child of ch9 rather than ...
mp_en_viaje: well then your problem has just been mostly resolved. you have to read up on padding, ideally start with shoup's restatement of
oaep diana_coman: mircea_popescu: it has indeed everything needed as far as I know and certainly rsa, keccak,
oaep, the whole package.
mircea_popescu: diana_coman, afaik it actually has evreything needed, including rsa, hash function,
oaep even ? just no pss implemented ?
a111: Logged on 2018-11-14 20:20 diana_coman: my understanding was that nobody actually LIKES
oaep all that much but it's (again! another one of those!) the thing we have (as opposed to the thing we might wish for)
diana_coman: my understanding was that nobody actually LIKES
oaep all that much but it's (again! another one of those!) the thing we have (as opposed to the thing we might wish for)
☟︎ diana_coman: meanwhile the
oaep got sorted better as part of smg comms really (i.e. only ada calling c, no back and forth dance and that gets rid of a LOT of confusion)
mircea_popescu: anyway, back to it : "blockcipher takes 10 bits of P and no more ; spits out 16 bits of E exactly" a) needs entropy and b) probably reduces to rsa-with-
oaep.
mircea_popescu: i wont cry if every once in 256 cases you do an extra
oaep that 50-50 might've not been needed.
diana_coman:
http://btcbase.org/log/2018-10-26#1866643 - to detail this: technically speaking one CAN test top bit until it's 0 for the
oaep block (hence for *sure* < modulus) but I don't think it's great mainly because: 1. this fixes one more bit 2. it's really a way bigger hammer than needed - it can start with 1 and be smaller than modulus so potentially increases the number of repeat-
oaep without any good reason 3. it's not even particularly clean,
☝︎ diana_coman: that's the headache:
oaep in ada, comparison in C, if not right,
oaep in ada again, if right then rsa in C
diana_coman: but the comparison is iffy since either a. call c-wrapper and so do conversion from ada's
oaep array of octets to C's MPI shit
diana_coman: yes, this is for the
OAEP part - current algo repeats the
oaep padding until the result is < modulus of given key (since otherwise it can't rsa afterwards)
diana_coman: will probably cut it in 2 parts two, namely the wrappers first and then the whole big .vpatch bringing in everything needed (mpi, keccak,
oaep-but-this-time-from-ada-only)
diana_coman: in other news from the smg comms front: the rsa pack/unpack turned a bit nastier than the nice serpent because (of course!) of the C element; basically the rsa operations are in C (mpi mess) while the
oaep is in Ada and the current eucrypt wrapper is fine but doing the ugly dance of C to Ada *and back*; my solution to this is to decree that there will be only ONE direction of calls namely from Ada to C (because Ada is the main, desired par
mircea_popescu: diana_coman 2944 bit rsa keys, meaning 1384 bit usable message space in the rsa packet ? with
oaep and everything ?
mircea_popescu: diana_coman, this is too fluid to fix in a comment, and i'd rather have it here than in #eulora. so : let's call eucrypt.serpent X and eucrypt.RSA-
OAEP R. now, 1. client wants to log in, R(hello) -> S[erver].
ave1: diana_comon, Yes, I read the test and the code and your text (also played with the test a little). So I was a little suprised that rsa_oaep_encrypt used mpi code. I will write an alternative.
diana_coman: to answer your question directly though: 1. it certainly could - rsa_oaep_encrypt is just a wrapper so it's meant more as an example of using all the stuff together rather than a standard: I'd expect that there would be other/different wrappers, made to suit specific uses
ave1: diana_coman: could the input parameter of rsa_oaep_encrypt be a character array? it is now an MPI this will discard any leading zero's of a message an exclude binary stream/file encryption. (same goes for decrypt)
diana_coman: ave1, I tried compiling eucrypt & components using your runtime: need support for Interfaces.C (used by keccak/
oaep) and Ada.Unchecked_Conversion (used by Serpent)
diana_coman: phf, the oaep_fix_checks seems to be missing and that's possibly also creating trouble otherwise since you're running the code without the fix
mircea_popescu: in other news : as work on eucrypt is winding down -- the whole item is just about complete, needs serpent and we've decided to add an
oaep-rsa wrapper (mostly as a pretext to do some ada-c interop testing), so roughly speaking by end of month it should actually be done -- we're moving on to shaping up the eulora client-server comms model. this will mostly be a design discussion, will take place in #eulora, prolly take up som
diana_coman: padding, bitstream, sponge,
oaep to follow; currently still in the works
mircea_popescu: entirely true that if one builds a hash which can be provenly as strong as rsa, then thathash powered
oaep would be the natural padding for rsa
a111: Logged on 2017-09-16 02:57 PeterL: by the way, I stuffed the keccak ada stuff (and, speaking of
OAEP, here is one of those too) into
https://github.com/PeterMLambert/keccak since I don't have my own server up yet
PeterL: With RSA-
OAEP, one can encrypt messages whose bit-length is up to just a few hundred bits less than the number of bits in the RSA modulus, yielding a ciphertext whose size is the same as that of the RSA modulus. << It sounds like he is using a smaller amount of random bits than we are?
mircea_popescu: (tl;dr : here's proof
oaep is insecure ; original "proofs" wrong ; rsa-
oaep is not insecure by accident, due to rsa properteis ; here's
oaep+ fixed by me to actually 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-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: 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:
oaep works like this : given hash and hash' hash functions, calculate X as hash(m00) xor G(r) and Y = r xor hash'(X).
Framedragger: that's fair. ok. i assume you don't think much of
OAEP (i see it mentioned in the logz but only just)