I know that i have to encode any message in order to encrypt it using ElGamal cryptosystem. However, i know that's easy when you have a message of a pair of numbers, f.e (5,3). But if you have one like m=2, what should we do to use it as a pair?
Related
Im currently trying create some code to decode the SCT extension in a X.509 Certificate (OID: 1.3.6.1.4.1.11129.2.4.2). It has mostly been successful, however the SCT signature turns out wrong for me when comparing my result to OpenSSL. An example:
Mine:
37:F6:....:E2:16:....
OpenSSL:
30:45:02:20:37:F6:....:02:21:00:E2:16:....
To clarify the "...." are the same for both. For all my test cases, the same pattern of:
30:45:02:20 and 02:21:00 come up. When trying to interpret these additional octets my guess is that these represent: 0x30 -> SEQUENCE and 0x02 -> INTEGER and the following octets represents length etc. Should these be included in the signature or is there something i have missed?
I'm try to understand how the Certificated works in the https protocol.
With wireshark, I can capture the certificates, first,I export the singedCertificate, and calculate the hash value; Second, I export the encrypted data, and decrypt it with the public key, the result should equal to the hash of signedCertificate.
This is an example of the decryption:
3021300906052b0e03021a05000414a1038465d47c003d8540ec33879f86e24c43b21a
I found that "a1038465d47c003d8540ec33879f86e24c43b21a" equal to the hash of the signedCertificate, but the head "3021300906052b0e03021a05000414" seemed something relates to the method of hash and encryption.
So, my question is,what's the format of this "a1038465d47c003d8540ec33879f86e24c43b21a".
finally I solve this question.
It's so easy, open the file with wireshark, then everything looks fine.
I've just sign document using itext. I've LTV too.
I read in itext documentation - "The DSS contains references to certificates, and we can add
references to OCSP responses and CRLs that can be used to re-verify
the certificates"
yes, I fount them in my DSS.
I also read thet: "In the DSS, we can store VRI"
I dont understand why is VRI for? because there is the same OCSP responses and Certificates , which are in DSS.
Also wat does /61A2411B1..... means? is it some hash or Random number?
The structures you are interested in are defined in ETSI TS 102 778-4.
I dont understand why is VRI for? because there is the same OCSP responses and Certificates , which are in DSS.
While the Certs, OCSPs, and CRLs arrays in the DSS dictionary reference certificates, OCSP responses, and certificate revocation lists that may be used in the validation of any signatures in the document, the VRI dictionary contains Signature VRI dictionaries which reference the validation-related information for a single signature.
As your document contained but one signature, the information looks unnecessarily duplicated.
Also wat does /61A2411B1..... means? is it some hash or Random number?
The key of each entry in the VRI dictionary is the base-16-encoded (uppercase) SHA1 digest of the signature to which it applies.
PS: To clarify: key in the last sentence refers to the PDF structure: the VRI dictionary is a PDF dictionary in which a key (a PDF name object) is mapped to a value (another PDF object, in this case another PDF dictionary). It is not a cryptographic key from the signature...
Thus, you take the signature in question, calculate its SHA1 hash, write it in uppercase base-16-encoding, make that string as a PDF name, and then use that PDF name as PDF dictionary key.
Current latest ETSI specification is at https://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf
You can leave the VRI out as its a duplicated data and actually not needed.
The VRI dictionary is optional, since all necessary data to validate
the signature can be available from other sources like the DSS
dictionary itself. The VRI dictionary offers possibilities for
optimization of the validation process, since it relates the data to
one specific signature.
Ok after experimenting a little bit I found out that resin was calling my AbstractAuthenticator implementation "authenticate" method that takes an HttpDigestCredentials object instead of DigestCredentials (still don't know when is called each one of them) the problem is that HttpDigestCredentials doesn't have a getDigest() method, instead it has a getResponse() method which doesn't return a hash or at least not a comparable one.
After creating my own hash of [[user:realmassword] [nonce] [method:uri]] the hash is very different, in fact I think getResponse() does not return the digest but maybe the server response to the browser?.
Any way this is my debugging log :
USER:user:PASSWORD:password:REALM:resin:METHOD:GET:URI/appe/appe.html:NONCE:HsJzN+j+GQD:CNONCE:b1ad4fa1ba857cac88c202e64528bc0c:CLIENTDIGEST:[B#5dcd8bf7:SERVERDIGEST:I4DkRCh21YG2Mk14iTe+hg==
as you can see both the supposed client nonce is very very different from the server generated nonce, in fact the client nonce doesn't look like a MD5 hash at all.
Please has someone does this before? is there something missing in the HttpDigestCredentials? I know digest is barely used.
Please, I know about SSL but I can't have an SSL certificate just yet so don't tell me "Why don't you use SSL". ;)
Update:
Not sure if was the right thing to do but, as I read before Resin uses base64 format for hashes so I used apache commons-codec-1.6 to use encodeBase64String() method and now the hashes look alike but they are no the same.
I tried both passwordDigest.getPasswordDigest(a1+':'+nonce+':'+a2); passwordDigest.getPasswordDigest(a1+':'+nonce+':'+ncount+':'+cnonce+':'+qop+':'+a2);
and none of them gives the same hash as the one from HttpDigestCredentials.
Ok I finally made it . Weird subject Huh, only two views?
First, digest authentication makes use of user, password, realm, nonce, client_nonce, nonce_count, method, qop, and uri. Basically it uses the full digest spec. So in order to calculate the hash one must calculate it with all the whistles. Is just a matter of calling the get method for each one of the variables from HttpDigestCredentials except for user and password. The user will come in the form of a Principal and the password you must look for it yourself in your DB (in my case a DB4O database).
Then you must create a PasswordDigest object, that will take care of generate a hash with the getPasswordDigest() method, but first one must set the format to hex with passwordDigestObject.setFormat("hex").
There is one for the HA1 getPasswordDigest(user,password,realm) and there is another getPasswordDigest() method that takes just one string and one can use it to generate the rest of the hashes, both HA2 and with the previous hashed HA1 the final hash, of course with the nonce nonce_count client_nonce and qop, of course each one separated by a semicolon.
Then it comes the tricky part, although resin works with base64 encoding for digest when you call the getResponse() method from HttpDigestCredentials it returns a byte array (which is weird) so in order to compare it with your hash what I did was use the Hex.encodeHexString() method from org.apache.commons.codec.binary.Hex and pass the HttpCredentialsDigest getResponse() return value, and that will give a nice hex String to compare.
I was doing it the other way around, I was using the Base64 hash from PasswordDigest and converting the HttpDigestCredentials hash to Base64 and the resulting string were never the same.
How to encrypt a nsstring and store it in a file, and how to decrypt the same.
Please suggest me wat api's i shld use...
This is the function i used for encryptiong.
DES_cfb64_encrypt( ( unsigned char * ) pchInputData, ( unsigned char * ) pchOutCipher,
size, &schedule, &ParityKey, &no, DES_ENCRYPT );
I had to convert this to base64 so that i can store it in a file.
pstrResult = Base64encoding(size,( unsigned char * )pchOutCipher);
You can use gpgme
If you only need to support 10.5 or higher you can use the CommonCryptor API. The first comment to this post shows an example category for encrypting/decrypting NSData's:
http://iphonedevelopment.blogspot.com/2009/02/strong-encryption-for-cocoa-cocoa-touch.html
While not an API call, you could implement a simple XOR cipher. This is quick and simple to implement and depending on the characteristics of your string (i.e. if it is of fixed length) can be very secure. If you have a variable length string XOR encryption may not be secure enough depending on your needs. Have a look at the Wikipedia article.
If you are storing a password first decide whether or not you need to re-use the password or whether you just need to check that the user has entered the correct password.
If you just need to verify that the user has entered the correct password, then store the password using a hash, and compare the hash of the user input with the hash you have stored. If both hashes are equal, then the user has [probably] typed it correctly. See more information about hashes at Wikipedia.
If you need to re-use the password (i.e. for authenticating with other services, such as connecting to an Internet service), use Apple's Keychain service. If you are targeting the iPhone, then check out this related document.