Let me go back to my white board and think what approach would be good. Even if i store HASH message my client doesn't want any keys or hash messages stored in flash be the way it is and so is the reason we wanted to even encrypt the DEK using key wrap...
pkumarn wrote: > > Firstly i am really thankful for you to being patient and throwing some > light on basic... even thought i was aware of few things, it was like a > refresh course :) ... thanks for that... > > Coming to the usage, i really don't want to use HEX for the > PKCS5_PBKDF2_HMAC_SHA1(). I just want to input the values i got from > RAND_byes(). > > Here is what i am going to do, correct me if i am wrong > 1. unsgined char rand[32] > 2. RAND_bytes(rand, 32) > > I will direcrtly use rand() in PKCS5_PBKDF2_HMAC_SHA1() and assume i have > got the correct result. > > One of my engineer is asking me how do i know if PKCS5_PBKDF2_HMAC_SHA1() > has produced he right result.... he wants some other alternative tool to > verify my result... this is where i am stuck and found out the website but > i feel it is not going to be useful... any thoughts on this? > > > > > Dave Thompson-5 wrote: >> >>> From: owner-openssl-us...@openssl.org On Behalf Of pkumarn >>> Sent: Tuesday, 20 March, 2012 00:36 >> >>> Thanks a lot Dave for pointing out few things which i need to >>> take care. By >>> the way as this is not complete code, original code already >>> has taken care >>> of few things. >>> >>> Now coming to the original question, how do i make sure >>> PKCS5_PBKDF2_HMAC_SHA1() is generating the correct result of >>> my i/p data? >>> When i input RAND_bytes() data into PKCS5_PBKDF2_HMAC_SHA1(), i get a >>> different result but when the same is converted to ASCII >>> (human readable >>> format), i get a different result. ... >>> >> Use the correct input to _PBKDF2_ and you get the correct >> output. Or more exactly, since there are a huge number of >> possible input sets (pw + salt + niter) and corresponding >> output key values, make sure that decrypt uses the *same* >> derivation inputs as encrypt did. >> >> You seem to be not understanding some of my answers; >> either you are using standard terminology differently, >> or misunderstanding how characters work in C. So let me >> start from the basics, even if this may be repetitive. >> >> 'char' in C or its variants 'signed char' and 'unsigned char' >> are actually a byte of storage, which is at least 8 bits and >> on current-day machines you are likely to program (like PCs >> and Macs) exactly 8 bits. It can contain a small integer: >> 0..255 for unsigned 8 bits or -128..-127 for signed 8 bits >> two's complement. (C also allows ones' complement and >> sign-and-magnitude, but no machines you will use do so.) >> This small integer *optionally* can be and *usually* is the >> codepoint for a character in a character code like ASCII. >> (C doesn't require ASCII, but the machines you will use do >> have either ASCII or much more likely a superset of ASCII >> like Windows-1252 or ISO-8859-1.) In C a string is an array >> of char, each element containing a codepoint, terminated by >> null. For example on a typical ASCII-based machine: >> char xyz [4] = "Dog"; >> creates an array of 4 bytes, where >> xyz[0] = 68 = 0x44 // which is the ASCII codepoint for D >> xyz[1] = 111 = 0x6F // ditto o >> xyz[2] = 103 = 0x63 // ditto g >> xyz[3] = 0 // which is a null terminating byte/character >> >> C doesn't require that all byte values be codepoints for >> a character, and most commonly used codes have codepoints >> that either are totally unassigned or (now more common) >> aren't visible/displayable characters called graphics. >> (Space is displayable/printable but not a graphic.) >> >> Thus if you have arbitrary byte values, such as from >> RAND_bytes(a,n), they rarely (all) have meaning as ASCII >> graphics; they more often but not always have meaning >> as Windows-1252 or 8859-* graphics. To display such data >> 'losslessly' -- so that you can recover the exact bytes -- >> you need some conversion. You mention 'conversion to ASCII' >> as if there were one such conversion; there are many, and >> you want a conversion to the graphic subset of ASCII, not >> the several invisible control codes (aka control chars). >> The most common are hexadecimal (abbreviated hex) and base64 >> (with at least two major variants); you appear to want hex. >> >> If you convert 32 arbitrary bytes (your case) to hex, it >> is 64 characters (each of which is a hex digit). If you >> put that in a C string it also needs a null terminator. >> If you write it to a (text) file it may need a newline, >> and in some message formats it needs a tag or label etc. >> >> This converted hex string is different from the original >> data, and therefore using it for _PBKDF2_ will produce >> different (and wrong) output. >> >> Thus in general there are three approaches: >> >> - use arbitrary byte values for salt, in an environment where >> arbitrary values are okay. For example, in C you can write >> them to a disk file opened in binary mode and read them back >> unchanged. Some data formats, especially those using ASN.1 >> like PCKS#7/CMS and PKCS#12, can handle arbitrary bytes. >> >> - use arbitrary byte values for salt, convert them to a safe >> representation such as hex for transmission and/or storage, >> *and* convert back to the arbitrary bytes when re-used. >> >> - use byte values for salt that are restricted so they are >> *already* valid character codepoints. In my previous post >> I gave the simple example of 0x40-0x5F for ASCII. As I said >> this reduces the entropy of your salt, but it's still much >> more than needed and much more than plausible passwords. >> >> Choose one. >> >> *If* you want compability with the Javascript on the website >> you pointed to, as-is that apparently requires choice 3, >> although I think it can be modified to do hex for choice 2. >> I think Javascript itself can handle arbitrary bytes in >> strings but as far as I can tell they can't be input using >> a browser form as that code does, ruling out choice 1. >> >> >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-users@openssl.org >> Automated List Manager majord...@openssl.org >> >> > > -- View this message in context: http://old.nabble.com/How-to-use-PKCS5_PBKDF2_HMAC_SHA1%28%29-tp33529423p33544643.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
