World: r3wp

fix=make it working - we will see - not just with automatic distinguishing 
what password scheme should be used .... good doc, Volker! I searched 
Google yesterday, but did not find the one describing the protocol 
...

then look how Doc parses this header, maybe you can hexdump it and 
test with old and new password?

The new authentication is performed in following manner:

  SERVER:  public_seed=create_random_string()
           send(public_seed)

  CLIENT:  recv(public_seed)
           hash_stage1=sha1("password")
           hash_stage2=sha1(hash_stage1)
           reply=xor(hash_stage1, sha1(public_seed,hash_stage2)

           // this three steps are done in scramble() 

           send(reply)

     
  SERVER:  recv(reply)
           hash_stage1=xor(reply, sha1(public_seed,hash_stage2))
           candidate_hash2=sha1(hash_stage1)
           check(candidate_hash2==hash_stage2)

           // this three steps are done in check_scramble()

he does nice job, he puts it into words ...

just went away for lunch :-)

CLIENT:  recv(public_seed) //must be that salt-thing
 zapadapadu password

send(reply) //must be the scrambled password, makes no sense otherwise.

Doc probably wanted his script to work independently of Pro and Command. 
(or, that method wasn't implemented at that time).

I think so. I guess they used no sha1 and rebol had nothing inbuild. 
now checksum/secure matches perfect.

hmm, sadly, there is probably bug in protocol read-out directly. 
I thought that salt (seed) is those 8 bytes only. It is so, only 
if old password scheme is used, otherwise another 12 bytes follow. 
But Doc keeps only 8 bytes in crypt-seed word no matter what protocol 
password version is used ...

The host sends an initial greeting
 in docu,
do-handshake:
 in Docs code.

you see the first entries match.

I know - I proceeded further - it calls decode ....

No, you must extend the parse-rule.

but look at do-handshake parser ... it does not parse for the rest, 
it seems to stop at the capabilities ...

agreed :-)

there are 16 bytes to ignore (latin1 etc.)

that a 16 skip

to ignore or not :-)

I may as well extend the protocol, but it may come later :-)

and then the other 12 for salt. copy salt2 12 skip

I need language info :-) hmm, but that can be obtained later ....

thehn joinboth salts. with some luck that works.

do those two salts to be joined?

it will not work probably, no?

should. together 20 bytes, can not be accidental (i hope..)

also the example says "Rest of Salt"

do you think Doc's hash-v10 and crypt-v10 are equivalent to chekcsum/secure 
sha1?

let's hope so ... going to extend the parse now ...

i have no idea. i see lots of cryptic binary stuff, no idea whatit 
does.

imo Doc found some C code and translated it to rebol back then, when 
checksum/secure was not available? dunno ....

ehm, ehm .... :-)

Maybe its something custom? They mention no name, while they refer 
to sha1 in the new version.

I just put some probe [name int and value] into decode function to 
know capabilities, but:

decode-integer: 41516
long-password 0
found-rows 0
long-flag 4
connect-with-db 8
no-schema 0
compress 32
odbc 0
locl-files 0
ignore-space 0
change-user 512
interactive 0
ssl 0
ignore-sigpipe 0
transactions 8196

how is that long-password, sent to me by server initial handshake 
sequence is 0?

that somehow does not make sense to me ...

me too. hmm. long-flags is set.

yes, curious what it means ...

do you have a long password in the db?

that example has also only long-flag

yes ....

long_password is in the clients response.

The client now sends a request

although - I just try to connect to /mysql table ... but passwd is 
user dependant, and as a root, I can see, it is long already :-)

we get a little score for the first round? :)

what do you mean? :-)

well, I think now the first task is to extend parse rule ...

the demo has a lot of 0 before the real password. maybe that helps 
adjusting.

hmm, read the handshake section in doc you posted - it gest pretty 
complicated :-) server sends 4.11, which means new password, client 
sends new password, but then server finds out, old password is stored 
in his user database for you, so it sends another one-byte reply 
for you to send password once again :-)

Eeks. Forbid short passwords now..

ok ...