I am trying to encrypt the following password my^Password using below:
.\encrypt.bat input=j!p^RVKvt3LaHw37 "password=<my_salt>" "algorithm=PBEWITHSHA256AND256BITAES-CBC-BC" providerClassName=org.bouncycastle.jce.provider.BouncyCastleProvider
When I decrypt the encrypted string, The exponent sign ^ is gone. I've also noticed this issue with some other symbols.
.\decrypt.bat 'input=<encrypted-string>' "password=<my_salt>" "algorithm=PBEWITHSHA256AND256BITAES-CBC-BC" providerClassName=org.bouncycastle.jce.provider.BouncyCastleProvider
Output:
myPassword
Can anyone help fix this issue? I've scorched the internet but could not find any solution.
It turns out that windows powershell has a bug where it can’t properly encode a password with special characters. I performed the exact same commands on command prompt and it worked like a charm.
Related
I am attempting to send a file from IFS to an outq on our AS/400 system. Whenever I do, I get exactly what I send, as well as a line of "#" symbols of varying lengths appended to the end.
Here's the command I'm using:
qsh cmd('cat -c /path/test.txt | Rfile -wbQ -c "ovrprtf file(qprint)
outq(*LIBL/ABCD) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)"
qprint')
The contents of test.txt is just Hello World!
The output I get when I send the command is
Hello World!####################################################################
I have not found any posts online about a similar problem, and have tried changing values and looking for additional switches to get it to work. Nothing I'm doing seems to fix the issue.
Is there a command or switch that I am missing, or is something I have in there already causing this?
EDIT:
I found this documentation which is the first time I've seen this issue mentioned, but it's not very helpful:
“Messages for a Take Action command might consist of a long string of "at" symbols (#) in a pop-up message. (The Reflex automation Take Action command, which is configured in situations, does not have this problem.) A resolution for this problem is under construction. This problem might be resolved by the time of the product release. If you see this problem, contact IBM Software Support.”
The only differences are: 1) this is not a pop-up message, it's printed. 2) I don't believe we use Tivoli Monitoring, although I could be wrong.
Assuming we do use Tivoli Monitoring, what would the solution be? There's no additional documentation past that, and I am not a system administrator, so I can't really make the call to IBM Software Support myself. And assuming we DON'T use it, what else could cause this issue?
I get different results, yet similar. I created a test.txt with Windows Explorer, put in Hello, world!, saved it and tried the script. I got gibberish for the 'Hello, world!' and then the line of # symbols.
My system is 7.3 TR5, CCSID 37 (US English) and my IFS file is CCSID 1252 (Windows English). Results did not change if I used a stream file of CCSID 819 (US ASCII).
I didn't have any luck modifying Rfile switches.
I found that removing devtype(*userascii) produced printed output in plain English without the # symbols. Do you really need *USERASCII? I would think that would be more for a pre-formatted 'print-ready' file like Postscript or the like.
EDIT: some more things to try
I don't understand why *USERASCII is adding those # symbols; it looks like a translation issue.
I tried this and still got the extra ###... You might have to play with the TOCCSID() parameter. Although a failure, it did give me an idea: what if those # symbols are EBCDIC spaces being sent as-is to the *USERASCII print stream? All we'd need is a way to send only the number of bytes in the stream file, without any padding.
CRTPF FILE(QTEMP/PRTSTMF) RCDLEN(132)
CPY OBJ('/path/test.txt') TOOBJ('/qsys.lib/qtemp.lib/prtstmf.file/prtstmf.mbr') replace(*yes)
ovrprtf file(qprint) outq(*LIBL/prt3812) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)
cpyf prtstmf qprint
The data in QTEMP/PRTSTMF is in ASCII; DSPPFM shows that much. It also shows a bunch of spaces: after all, it is a fixed length file. My next step was to write an RPG program to read the stream file and print it, but Scott Klement already did that: http://www.scottklement.com/PrtStmf.zip
This works on my system:
ovrprtf file(qsysprt) outq(*LIBL/abcd) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)
prtstmf stmf('/path/test.txt') outq(abcd)
I have encrypted a PIN block under a TPK (clear)
When I am going to translation my PIN block from encryption under TPK to encryption under ZPK given from client on real HSM then it is giving me either error code 24 or 20.
What can i do to resolve my issue ? I have tried many ways but it is not getting resolved.
Translation command I am using is CA - Translate a PIN from TPK to ZPK/BDK (3-DES DUKPT) Encryption.
Al these my operations working beautifully with thales HSM simulator.
Errors you are getting are:
Error 20:PIN block does not contain valid values
Error 24:PIN is fewer than 4 or more than 12 digits in length
You said that you have clear TPK, but you can't do anything with clear keys on HSM. You have to import key and get key under LMK for any command.
You also have to import this key as TPK key in HSM to use CA command. You can also import it as ZPK, but than you should use CC command.
I have issue with special character in password - '#'.
Issue that i don't know how to pass password with this special character to script file and connect using sqlplus.
For example i have user 'test_user' with password 'temp123#'. For login via sqlplus i use following string with escaping: sqlplus test_user/\"temp123#\"#some-db:1521/SID
It's works well. For my case i need to pass password as parameter for sql script. For example, i have following script to connect (actually script using several pairs of login/password to update many users at once):
-- #deploy.sql
connect &&2./&&3.#&&1.
At have failure with that because password with '#' can't interpreted correctly by sqlplus. I tried many advices from google with escaping but mostly of them applicable for connect string at sqlplus invoke. For my case its required for parameter that passed to script.
use : cmd.exe and not powershell window
if not :
in powershell windows : sqlplus 'login/\"P#$$w0rd\"#TNS_NAME'
in cmde.exe : sqlplus login/\"P#$$w0rd\"#TNS_NAME
Just quotes required in connect string:
connect &&2./"&&3."#&&1.
I am using OpenSSL in iOS app to sign a message. I use RSA_sign to sign. When I use RSA_verify to verify the signature, result is like this
050 +(f2d7846a5f495a743e470663facf7a2858d052cf
Where f2d7846a5f495a743e470663facf7a2858d052cf is the original signature. So I am getting additional 050 +( at the beginning of the signature. Can anyone please tell me the reason of this?
This is how I am signing
int sign = RSA_sign(NID_sha1,( char *)reply, strlen(reply), signature, &siglen, myRSA );
where reply contains sha1 hashed data to be signed.
Best Regards
I'm very surprised that you see anything other than the original signature in the buffer. RSA_verify is not supposed to "return" anything other than the result of the verification (in the returned integer value, 0 for failure, 1 for success. Please use the methods as defined in the SSL documentation.
In my opinion it is a bug that you can see the hash in the first place. Unfortunately OpenSSL is not very well documented.
Given a LDAP password stored in SHA-1/{SSHA} how would I validate it in erlang.
For example - given the following {SSHA}:
% slappasswd -s myPassword
{SSHA}GEH5kMEQZHYHS95dgr6KmFdg0a4BicBP
%
How would I (in erlang) validate that clear text 'myPassword' matches with the hashed value of '{SSHA}GEH5kMEQZHYHS95dgr6KmFdg0a4BicBP'.
Passwords stored in a directory server are validated using the BIND operation. A properly configured and secured directory server will not allow access to password data; therefore LDAP clients must not be coded expecting that the password data is available, whether encrypted or hashed. LDAP clients must use the BIND operation to validate passwords.
After some help from others I've come up with a routine to do this in Erlang. Following up here to share with others.
First - this link (found in another post) gives functions in other languages doing what I wanted:
http://www.openldap.org/faq/data/cache/347.html
The trick was that the 'ldap {SSHA}' encoding is a salted-SHA1 hash which is also base64 encoded. So - you must decode it, extract the salt and then use that in the re-encoding of the 'clear password' for comparison.
Here is a short Erlang routine which does this:
validatessha(ClearPassword, SshaHash) ->
D64 = base64:decode(lists:nthtail(6, SshaHash)),
{HashedData, Salt} = lists:split(20, binary_to_list(D64)),
NewHash = crypto:sha(list_to_binary(ClearPassword ++ Salt)),
string:equal(binary_to_list(NewHash), HashedData).
Given the data in my original post - here's the output:
67> run:validatessha("myPassword", "{SSHA}GEH5kMEQZHYHS95dgr6KmFdg0a4BicBP").
true
68>
Thanx all.
Mike
My erlang is very rusty, so this isn't very pretty, but maybe it gets my idea along anyway.
run() ->
Password = "myPassword",
HashRaw = os:cmd("slappasswd -s " ++ Password),
Hash1 = lists:nthtail(6, HashRaw),
Hash2 = lists:concat ([integer_to_list(X, 16) || X <- binary_to_list(crypto:sha(Password))]),
string:equal(string:to_lower(Hash1),
string:to_lower(Hash2)).
My idea is that you:
Run the command whose output you are interested in verifying (slappasswd), save the output and trim away the extra decoration preceding the hash.
Run crypto:sha() from the erlang libraries. Take the binary output from this, and convert it to a list of integers, each of which you then convert to a hexadecimal string, which you then concatenate, thereby create Hash2.
Compare the output of your command to the output of crypto:sha()
EDIT: I don't have this command you're using, so I couldn't really try this very thoroughly.. But it works for sha1sum. I hope they are the same!