I have to implement a client and server for end-to-end encryption.
So if I am correctly informed, I need to encode and decode my keys with Base64.
ArgumentError (string contains null byte):
app/controllers/users_controller.rb:46:in `register'
This is what I get just after the request reached my Server.
And that is the code i have written.
43 tempkey = Base64.decode64(params[:privkey_user_enc])
44 #user = User.new(:identity => params[:identity], :salt_masterkey => params[:salt_masterkey], :pubkey_user => params[:pubkey_user], :privkey_user_enc => tempkey)
45 if !(User.find_by_identity(#user.identity))
46 if #user.save
And a snippet from the key:
LSFzoeT/7VLtWCQHEx3p3Nz3AfC7toACKRWELNC5E6CtSEsp6pZ7b4zldP\n2J5otJjjGSmVgg7e8XtndpAoI6ZJdBr/XeMoKNID9bs1kiWw2BAOduTWJ37a\nBAurnBZlOGycwvRXPmSDbMLSEyuCf53UTpskIhCkLDv21rW2qklIVC22Z+k6\n3dSRYZ5dQjPwhdfkaUgXwcRQFMazbdw/RSSNH0twcax7msHZms2iVlgvjElN\n+qi5Iu77J3DZCOE2fAo06WXALQfG2gOuzTWwlsVOW+iwj/tMypYzEAu+Y+kx\n51M0XlwRgAyRSqg7MMyT8OGC/jtJgc1A8gwSn7pz9cSnTCFUFh1eulE4pLpS\n4Gxm30aqHPCpNgvjJssNdntbdMxn10mfg7wzJNvSeFof90rSZb+PNWwvlYBZ\nQLjB1J9myQwq1+ptzvcgeskaRaGBWpSXyeo2HUCcsRNbajqjSViyheKKMWDb\n7H6tdlrIE+d1XcwIvczU9DbgtIB8gy8PBL6XI5KLSq9gzy/TSVahCeqURyA4\nnmT2luNxdggQLc7aY0aL03vNl5dun0Xem2rVCI3lFo2e4WH
I think I may have narrowed the problem down to tempkey but I am not quite sure.
I would really appreciate any help. I found nothing in the Internet that solved my problem.
Thanks.
You may have run into this bug which prevents you storing data with embedded nulls.
I would just store the key as-is (ie. in Base64 format) as this will have no nulls. Then... when you need the key for a crypto operation just Base64.decode64(#user.privkey_user_enc) before use.
Base64 is just a mechanism for converting binary data into a text string that can be easily stored/transmitted
Related
I've got this query:
https://api-v3.mojepanstwo.pl/dane/krs_podmioty.json?conditions[krs_podmioty.nip]=7282827109
In a browser, it works OK, showing data specific for the given nip number.
But in Indy, I get a response as if the query part was omitted:
https://api-v3.mojepanstwo.pl/dane/krs_podmioty.json
I've tried this so far:
BurL = "https://api-v3.mojepanstwo.pl/dane/krs_podmioty.json?conditions[krs_podmioty.nip]=7282827109";
BurL = TIdURI::URLEncode("https://api-v3.mojepanstwo.pl/dane/krs_podmioty.json?conditions[krs_podmioty.nip]=7282827109");
End even raw urlencoded data:
BurL= "https://api-v3.mojepanstwo.pl/dane/krs_podmioty.json?conditions%5Bkrs_podmioty.nip%5D=7282827109";
Code:
try {
Resp = IdHTTPKrs->Get(BurL);
} catch (EIdHTTPProtocolException& e) {
ShowMessage(e.Message);
}
What's wrong, and how can I fix this? Or, maybe I am too tired already and am missing something obvious?
I suspect there is something with the [] part of the query, but I am just guessing here. Similar queries without the [] work OK.
I am using C++Builder XE6 pro, with Indy 10.6.0.512
Your Indy version is out of date. The latest version, at the time of this writing, is 10.6.2.5448. Using the latest version, I can't reproduce your issue. Both URL encodings return the same data for me. As they should be, since a web server is required to decode urlencoded characters when processing the requested URL. conditions%5Bkrs_podmioty.nip%5D=7282827109 and conditions[krs_podmioty.nip]=7282827109 should be getting processed the exact same way by the server, as they are sematically identical data.
I have been using DocuSign SOAP and REST based API calls to create envelope and am also using their Connect feature to update the recipient and envelope statuses for my clients.
I am getting a strange error parsing DocuSign Connect update for one client.
The error says "There is an error in XML document (1, 16174)".
Here is my code...
Dim sr As New StreamReader(Request.InputStream)
Dim reader As XmlReader = New XmlTextReader(New StringReader(xml))
Dim serializer As New XmlSerializer(GetType(DocuSignEnvelopeInformation), "http://www.docusign.net/API/3.0")
If Not serializer Is Nothing Then
envelopeInfo = TryCast(serializer.Deserialize(reader), DocuSignEnvelopeInformation)
Dim envid As String = envelopeInfo.EnvelopeStatus.EnvelopeID.ToString
I have tried bunch of things such as removing the XML definition from the XML document but did not work. The strange thing is that the same code works for all of my other clients. This is the only client that is having issues. They have added closed 65 tags in the document to be signed but I don't think that the tags are causing issues on their end since I also tried removing them.
Please advise.
Minal
I have run into this issue before when there are unsupported characters in the tab values or in the PDF byte stream itself when it is decoded. I suspect that copying and pasting values into tabs from external programs like Word introduce some invisible weird characters like
- carriage returns and the like. You should validate your XML in its entirety.
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!
I'm receiving messages from a JMS MQ queue which are supposedly utf-8 encoded. However on reading the out using msgText = ((TextMessage)msg).getText();
I get question marks where non standard characters were present. It seems possible to specify the encoding when using a bytemessage, but I cant find a way to specify encoding while reading out the TextMessage. Is there a way to solve this, or should I press for bytemessages?
We tried adding Dfile.encoding="UTF-8" to Websphere's jvm and we added
source = new StreamSource(new ByteArrayInputStream(
((TextMessage) msg).getText().getBytes("UTF-8")));
In our MessageListener. This worked for us, so then we took out the Dfile.encoding bit away and it still works for us.
Due to preferred minimum configuration for Websphere we decided to leave it this way, also taking into account that we may easier switch the UTF-8 string by a setting from file or database.
If the text is not decoded correctly, then probably the client is not sending the message with the utf-8 codec; this should work:
byte[] by = ((TextMessage) msg).getText().getBytes("ISO-8859-1");
String text = new String(by,"UTF-8");