If you are going to use the service/SID method then there is little point in passing encrypted data.

The scheme isn't portable, so you can make the process much more simple and lightweight by just asking for the data you require. The local (login) part of the connection will provide the security credentials and the service will simply return the data asked for.

You would use is like:
code:
$sPassword=$oSecureLink.getPassword("ADOMAIN\SecureUser")
Use S: \\SERVER\SHARE /user:ADOMAIN\SecureUser /password:$sPassword
or even:
code:
Execute($oSecureLink.getFile("Secret.kix"))
The data repositry is of course not visible to anything except the server service.

For simple password encryption I'd favour using the MD5 hash of the calling script as the salt or seed. The hash will ensure that the script has not been tampered with, so no-one can hack the script or create their own to decrypt the password.

You would use it like this:
1) Create a script called login.kix
code:
use s: \\server\share /password:$oSecure.decrypt("$sPassword")
2) Generate the encrypted password using the script as the seed/salt:
code:
passwordgen login.kix mypassword
This outputs "HIhdohs78721lksdf1nc0as765"

3) Execute the script:
kix32 login.kix $sPassword=HIhdohs78721lksdf1nc0as765

The decrypt routine will read in the script file to generate the hash to use in the decryption routine. If someone changes a single character of the script file the hash will change and the password returned will be garbage.

The only tricky bit is securely identifying the script file so that you can read it in the decrypt routine.

The major benefit is that you don't require the server or even access to the domain - you can run the script anywhere including stand-alone so long as you have access to the decrypt object. That means you can access local password protected objects like ODBC databases or whatever.