Re: General Questions
Hello, 1: How is the IV handled in (AES) encryption - I can see supplying an initial vector is good but it also appears this should change with every encryption (if you like). So does a user have to know this + key ? IV is used by encryption mode (like CBC) not by encryption algorithm like AES. But if we are talking of AES in CBC mode then AES key and IV should be known on both sides to successful encrypt/decrypt. In this case AES key should be random 16/24/32 bytes and IV should be random 16 bytes (AES block size). From user point of view this is not very ease to remember and for this purpose exists password based key deriviation functions like PBKDF2 in PKCS#5 and password (or passphrase) - easy to memorize - is one of parameter of this function (other are salt, iteration count) and as output you may get for example 32 random bytes (16 for AES key and 16 for IV). 2: Is it possible to alter a key size say I am using SHA256 and want to output a SHA256 hash of a users password to use as a key ? Also can I pass something to openssl to get a hex digest ? Size of AES key (16/24/32) may not be altered but with (for example) PBKDF2 you may use any password/passphrase to get specified amount of random data (which may be used as AES key/IV). 3: If a cracker can only retrieve 1 part of an encrypted file that has been deliberately split up - would having this 'part file' help or hinder the task of decrypting the contents of that file. Depends on encryption mode - in ECB - yes :-) 4: Is there a way that when attempting to decrypt a file you cannot know if you have been successful, i.e. you don't know the contents and try a key - you get an output from the attempt but it is not obvious if that output is correct (i.e file encrypted multiple times) or do all the encryption algorithms give a pass or fail or empty output. (i.e I tell you my pass-phrase is X and you use this to get output Y but you don't know what output Y is [could be further encryption], can you tell just be running the decryption algorithm that the key was a valid key?) Block decryption process of AES is always successful (I mean - algorithm) but what you will get after that (garbage or real data) depends on key. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: General Questions
1. How is the IV handled in (AES) encryption? --Actually, in AES in CBC mode, the ciphertext is dependent on the already computed ciphertext block. That is, CT for block k is dependent on CT of block k-1 and plain text for block k. (How it is dependent is a complex maths). But how do you know the ciphertext for 1st block? This is where IV comes in. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Irvine Sent: Thursday, August 17, 2006 5:27 PM To: openssl-users@openssl.org Subject: General Questions Hi This may be a double post if it is I apologise (I think I may have posted this before I was authorised by majordomo). I have started using encryption and thought I would try this out. My question(s) are as follows - please be gentle 1: How is the IV handled in (AES) encryption - I can see supplying an initial vector is good but it also appears this should change with every encryption (if you like). So does a user have to know this + key ? 2: Is it possible to alter a key size say I am using SHA256 and want to output a SHA256 hash of a users password to use as a key ? Also can I pass something to openssl to get a hex digest ? 3: If a cracker can only retrieve 1 part of an encrypted file that has been deliberately split up - would having this 'part file' help or hinder the task of decrypting the contents of that file. 4: Is there a way that when attempting to decrypt a file you cannot know if you have been successful, i.e. you don't know the contents and try a key - you get an output from the attempt but it is not obvious if that output is correct (i.e file encrypted multiple times) or do all the encryption algorithms give a pass or fail or empty output. (i.e I tell you my pass-phrase is X and you use this to get output Y but you don't know what output Y is [could be further encryption], can you tell just be running the decryption algorithm that the key was a valid key?) I know this is a bit much for a first question but I am researching a lot and it is fairly new (but hopefully I am a quick learner). David DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: General Questions
Many thanks for a fantastic explanation and for taking the time to help me. I was just reading some docs there pointing me to this but you have saved me a good few hours. I will search out info for python info on PBKDF2 many thanks for that. Just quickly though in point 3 does that mean I should use ECB mode or not if I am going to split the file and send two parts to different locations? Again fantastic response to what must be silly questions for someone like yourself. David Marek Marcola wrote: Hello, 1: How is the IV handled in (AES) encryption - I can see supplying an initial vector is good but it also appears this should change with every encryption (if you like). So does a user have to know this + key ? IV is used by encryption mode (like CBC) not by encryption algorithm like AES. But if we are talking of AES in CBC mode then AES key and IV should be known on both sides to successful encrypt/decrypt. In this case AES key should be random 16/24/32 bytes and IV should be random 16 bytes (AES block size). From user point of view this is not very ease to remember and for this purpose exists password based key deriviation functions like PBKDF2 in PKCS#5 and password (or passphrase) - easy to memorize - is one of parameter of this function (other are salt, iteration count) and as output you may get for example 32 "random" bytes (16 for AES key and 16 for IV). 2: Is it possible to alter a key size say I am using SHA256 and want to output a SHA256 hash of a users password to use as a key ? Also can I pass something to openssl to get a hex digest ? Size of AES key (16/24/32) may not be altered but with (for example) PBKDF2 you may use any password/passphrase to get specified amount of random data (which may be used as AES key/IV). 3: If a cracker can only retrieve 1 part of an encrypted file that has been deliberately split up - would having this 'part file' help or hinder the task of decrypting the contents of that file. Depends on encryption mode - in ECB - yes :-) 4: Is there a way that when attempting to decrypt a file you cannot know if you have been successful, i.e. you don't know the contents and try a key - you get an output from the attempt but it is not obvious if that output is correct (i.e file encrypted multiple times) or do all the encryption algorithms give a pass or fail or empty output. (i.e I tell you my pass-phrase is X and you use this to get output Y but you don't know what output Y is [could be further encryption], can you tell just be running the decryption algorithm that the key was a valid key?) Block decryption process of AES is always successful (I mean - algorithm) but what you will get after that (garbage or real data) depends on key. Best regards, begin:vcard fn:David Irvine n:;David Irvine org:Ayrshire Business Consulting Ltd. adr:;;3 Wellington Square ;Ayr;Ayrshire;KA71EN;Scotland email;internet:[EMAIL PROTECTED] tel;cell:+44(0)7977583031 x-mozilla-html:TRUE url:http://www.open-source-consulting.org version:2.1 end:vcard
Re: General Questions
Hello, Just quickly though in point 3 does that mean I should use ECB mode or not if I am going to split the file and send two parts to different locations? Of course not, look at: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation (link posted to that list before). Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: General Questions
--- David Irvine [EMAIL PROTECTED] wrote: - Many thanks for a fantastic explanation and for taking the time tohelp me. I was just reading some docs there pointing me to this but youhave saved me a good few hours. I will search out info for python info on PBKDF2 many thanks for that.Just quickly though in point 3 does that mean I should use ECB mode ornot if I am going to split the file and send two parts to differentlocations? Girish: You should avoid ECB mode at all costs. Always go for CBC mode. ECB mode is just too easy to crack. I will try to give you an intuitive explanation of the difference bet CBC and ECB. In ECB , each block of the file is encrypted independently. So crackers can very easily correlate cipher data and launch a chosen ciphertext attack or some such. But in CBC mode, this is made very difficult by virtue of the fact that each successive plaintext block is not only encrypted with the secret key schedule, but also X-ORed with the ciphertext of the previous block. This ensures that the diffusion part of block ciphering is really thorough. After all encryption is nothing but confusion and diffusion... Feel free to ask whatever basic questions you have. :-) Also don't get too hung up with IV. It is enough if you are able to generate a secret key with good entropy. All the best! regards, Girish __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: General Questions
ohhps :-[ thanks again - I am more educated than I was 10 mins ago. I hope other folk read this and don't repeat my stupid question. CFB mode for me then (we may stream the data back a bit at a time). Again brilliant David Marek Marcola wrote: Hello, Just quickly though in point 3 does that mean I should use ECB mode or not if I am going to split the file and send two parts to different locations? Of course not, look at: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation (link posted to that list before). Best regards, begin:vcard fn:David Irvine n:;David Irvine org:Ayrshire Business Consulting Ltd. adr:;;3 Wellington Square ;Ayr;Ayrshire;KA71EN;Scotland email;internet:[EMAIL PROTECTED] tel;cell:+44(0)7977583031 x-mozilla-html:TRUE url:http://www.open-source-consulting.org version:2.1 end:vcard
Re: General Questions
Girish Venkatachalam wrote: --- David Irvine [EMAIL PROTECTED] wrote: - Many thanks for a fantastic explanation and for taking the time tohelp me. I was just reading some docs there pointing me to this but youhave saved me a good few hours. I will search out info for python info on PBKDF2 many thanks for that.Just quickly though in point 3 does that mean I should use ECB mode ornot if I am going to split the file and send two parts to differentlocations? Girish: You should avoid ECB mode at all costs. Always go for CBC mode. ECB mode is just too easy to crack. I will try to give you an intuitive explanation of the difference bet CBC and ECB. In ECB , each block of the file is encrypted independently. So crackers can very easily correlate cipher data and launch a chosen ciphertext attack or some such. But in CBC mode, this is made very difficult by virtue of the fact that each successive plaintext block is not only encrypted with the secret key schedule, but also X-ORed with the ciphertext of the previous block. This ensures that the diffusion part of block ciphering is really thorough. After all encryption is nothing but confusion and diffusion... Feel free to ask whatever basic questions you have. :-) Also don't get too hung up with IV. It is enough if you are able to generate a secret key with good entropy. All the best! regards, Girish Many thanks this is all fantastic stuff. I appreciate your help and candour and what a well behaved list this is - serious pro's and not a sign of snobbery at all - great, I will live here for a while and learn and hopefully help others eventually. David begin:vcard fn:David Irvine n:;David Irvine org:Ayrshire Business Consulting Ltd. adr:;;3 Wellington Square ;Ayr;Ayrshire;KA71EN;Scotland email;internet:[EMAIL PROTECTED] tel;cell:+44(0)7977583031 x-mozilla-html:TRUE url:http://www.open-source-consulting.org version:2.1 end:vcard
Re: General questions about Diffie-Hellman
Vincent Levesque wrote: Hello, I've looked around and I'm still a little bit confused about a few details of Diffie-Hellman. (This is not specific to openssl so feel free to ignore me :-). First of all, my "experimentations" seem to show that only the server side needs Diffie-Hellman parameters: why is that? Also I'd like to know if the Diffie-Hellman parameters can be safely stored as cleartext in a file. (I'm pretty sure they can but I'd like to be 100% sure.) Finally is hardcoding the Diffie-Hellman parameters into an application safe? The two keys that are used to produce the DH shared secret have to have the same parameters. The standard states that the server provides them. The client then uses these parameters and generates/uses a DH key with the same parameters. DH parameters can be safely stored in a world readable file. This stuff is sent out unencrypted during the SSL/TLS handshake anyway. As for hard coding parameters... hmm thats is debatable. Probably better to allow them to be overridden. When parameters are hard coded there is always the suspicion that there is some sinister motive, such as a back door of some sort. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
