Re: Please tell me about encryption API of OpenSSL 1.0.1
On Tue, Apr 17, 2012 at 9:47 PM, Edward Ned Harvey wrote: >> From: owner-openssl-us...@openssl.org [mailto:owner-openssl- >> us...@openssl.org] On Behalf Of Ken Goldman >> >> The standard answer: If this is a real security project, hire an >> expert. If you design your own crypto algorithm, you will get it wrong. >> >> If this is just for fun, to learn about openssl, CTR mode will give you >> random access. > > The thing about CTR mode is that it needs a nonce. NIST 800-38A approves two ways to use counter mode. See Appendix B for guidance on choosing the initial value and the increment function. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Please tell me about encryption API of OpenSSL 1.0.1
On Tue, Apr 17, 2012 at 7:59 AM, Edward Ned Harvey wrote: >> From: owner-openssl-us...@openssl.org [mailto:owner-openssl- >> us...@openssl.org] On Behalf Of Edward Ned Harvey >> >> attacker doesn't know is your key and your plaintext. There is only one >> solution. You must use a second key. Use your first key to encrypt the >> second key (so an attacker can hopefully never know either one of your >> keys.) Use your second key combined with the block number (I suggest >> encrypting or hashing the block number using the second key, but simple >> AND >> or XOR should also be fine) and use the resultant data as the IV for your >> actual encryption operation. > > I don't see any reason why the second key couldn't match the first. You > could simply encrypt the block number, and use the result as the IV when you > encrypt your actual data block, using ECB. This is effectively > reimplementing CBC, where you don't make individual blocks dependent on each > other - instead you make each individual block dependent only on its block > number, where you're using the block number as the preceding block of data, > and the *only* preceding block of data. Sounds more like counter mode to me. > Every block number is guaranteed > unique and independent, so you're able to do random access, and since there > are never any repeats, there will never be any repeated cipherblocks, even > if there is repeated plaintext. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Please tell me about encryption API of OpenSSL 1.0.1
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Ken Goldman > > The standard answer: If this is a real security project, hire an > expert. If you design your own crypto algorithm, you will get it wrong. Or, if you're pretty confident you know how a block cipher works, you can create a solution (which is not the same as designing your own crypto algorithm) and then for the sake of diligence, hire an expert to review. Probably much cheaper this way. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Please tell me about encryption API of OpenSSL 1.0.1
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Ken Goldman > > The standard answer: If this is a real security project, hire an > expert. If you design your own crypto algorithm, you will get it wrong. > > If this is just for fun, to learn about openssl, CTR mode will give you > random access. The thing about CTR mode is that it needs a nonce. Good when you're engaging live communication with another party, so you can do the nonce exchange like a key exchange, but if the encrypted data is on disk for a later time... You need some way of regenerating the nonce. Which is conceptually the same thing as I originally said ... Store a second key, encrypted... Then decrypt the second key and apply it to the block number and using the result for IV. When I say "apply" to the block number, I suggested Adding or Xoring or encrypting... In CTR mode, you're basically adding the nonce & the counter, using it as the IV. So, in consideration of the two techniques: Storing an encrypted second key (or nonce) and adding or xor'ing with block number to generate IV (such as CTR mode), versus encrypting the block number with your original key to use for IV... If you store a second key (or nonce) separately, then you can decrypt the second key once, and repeatedly perform a really fast cheap operation such as add. (Such as CTR mode does.) If you directly encrypt the block number, then you don't need to store a second key, but you have to perform twice as many encryption/decryption operations, because you'll have to encrypt the block number once for every block, before you can encrypt/decrypt your data. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Remote access to my CA
On 17 Apr 2012, at 2:04 PM, Nathan Smyth wrote: >> If the apps only need to be able to verify certificates issued by that CA, >> then all they need is a copy of the CA's certificate and to know that that >> certificate should be used as a trust root. (And, perhaps, access to a CRL >> or something if you want to be able to revoke certificates before they >> expire.) This is the normal way that a small CA operates. > > Thanks for that. So in summary - each of the 'remote' machines should have a > copy of the CAs cert, and periodically pull down the CRL... ? Yes --- well, I've never set up CRL distribution (or OCSP) for my local CAs but that's my understanding, yes. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Remote access to my CA
> If the apps only need to be able to verify certificates issued by that CA, > then all they need is a copy of the CA's certificate and to know that that > certificate should be used as a trust root. (And, perhaps, access to a CRL or > something if you want to be able to revoke certificates before they expire.) > This is the normal way that a small CA operates. Thanks for that. So in summary - each of the 'remote' machines should have a copy of the CAs cert, and periodically pull down the CRL... ? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Please tell me about encryption API of OpenSSL 1.0.1
On 17/04/12 15:31, MauMau wrote: Hello, Edward, Jakob, Ken, Thanks for lots of ideas and information. I'll investigate Edward's block-number-based iv and Ken's CTR mode. Let me consult you if I get stuck again. I'll consider some way to eliminate the need to call EVP_EncryptInit_ex/EVP_DecryptInit_ex for each block/record. Regards MauMau I would second Ken's recommendation for CTR mode for random access if the random access is for *read* only. If you are going to try and use CBC mode for random (read) access then the IV must be set to the last 16 bytes of the immediately preceding 4k record...or the initial IV if it is the first 4k record. This is why in your example code you got wrong data for block2. However in your original post you said "File type 1 consists of 4 KB blocks. The application randomly reads and writes those blocks. ". If you are going to attempt to randomly change, write and re-encrypt a record in the middle of your file then this will absolutely not work in CBC mode. You will corrupt everything in your file beyond the write because as noted above the last 16 bytes of the record you have just written is the IV for the next record. As you have changed the last 16 bytes by reencrypting you will not be able to decrypt the following record. If you attempt to use CTR mode in random read/write mode then this will open a massive security hole in your application. In CTR mode the counter is initialised to a random value and then incremented for each 16 byte block. The encryption works by encrypting the counter and xor'ing it to the plaintext. So if the plaintext for block 7 is m7, then the ciphertext, c7, is calculated as follows: c7 = AES(ctr + 7) xor m7 Now if you modify m7 to be m7' then c7' would be: c7' = AEX(ctr +7) xor m7' The problem is that an attacker can xor the two ciphertexts together as follows: c7 xor c7' = AES(ctr + 7) xor AEX(ctr + 7) xor m7 xor m7' = m7 xor m7' In other words xoring the original block 7 with the modified block 7 will be equal to the two plaintexts xored togetherwhich is trivial to crack. If I have interpreted your original post correctly and you are trying to do random read/write then you need to select a mode that supports it. (Maybe XTS??? I'm not familiar with the details of this but probably worth looking at). Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Hello guyz and cryptobrains! :P
On 17/04/12 06:57, toredhiddenu...@tormail.net wrote: The library only supports Fp and F2^m custom curves. The easiest way to construct a custom curve is by using one of: EC_GROUP *EC_GROUP_new_curve_GFp(const BIGNUM *p, const BIGNUM *a, const BIGNUM *b, BN_CTX *ctx); EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const BIGNUM *a, const BIGNUM *b, BN_CTX *ctx); Where for an Fp curve p, a and b are used as follows: y^2 mod p = x^3 +ax + b mod p And for an F2^m curve p (p=2^m), a and b are: y^2 + xy mod p = x^3 + ax^2 + b (where b != 0) mod p Matt So, do you say it can't be done with executable? Will this be a feature in future releases? Are you sure there's no way to do that than digging the C source? Well ultimately openssl is a library. The functions I mention above are part of the public API so you don't need to modify the openssl source to use them. It does require programming though. From your question I assume you are referring to the openssl command line tool. I am not particularly familiar with the command line tool as most of my work has been with the library directly. However I would be surprised if you can define custom curves using it...that's fairly advanced stuff that most users are never going to need to use (nor would it be advisable for them to do so). In almost all cases using a standard curve will be sufficient - and its by far the safest option. In terms of future support for new curves, I imagine that is going to be driven by the standards. As curves get defined and standardised they will work their way into openssl. Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Remote access to my CA
On 17 Apr 2012, at 10:48 AM, Nathan Smyth wrote: > I created a CA on my local machine (using CA.sh), which I used to develop > some socket-based applications. The apps access the CA using > SSL_CTX_load_verify_locations, with the (local) path of the CA. > > I'm now distributing the applications to other machines, and was wondering > how I can allow other machines to use my (existing, local) CA. Do I just need > to transfer some files to the remote machines? (is that smart?) Or is there > some existing service I can use to pass the data through a socket on demand? > I suppose there must be ways to tie this into a webserver, but I have no > desire to run one. If the apps only need to be able to verify certificates issued by that CA, then all they need is a copy of the CA's certificate and to know that that certificate should be used as a trust root. (And, perhaps, access to a CRL or something if you want to be able to revoke certificates before they expire.) This is the normal way that a small CA operates. If the apps need to be able to issue *new* certificates using the CA's authority, then there isn't an out-of-the-box solution that I know of, but mostly because that's usually not something you want to do; you usually want to issue an intermediate certificate to each app and allow them to issue leaves using that. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Remote access to my CA
Hi all, I created a CA on my local machine (using CA.sh), which I used to develop some socket-based applications. The apps access the CA using SSL_CTX_load_verify_locations, with the (local) path of the CA. I'm now distributing the applications to other machines, and was wondering how I can allow other machines to use my (existing, local) CA. Do I just need to transfer some files to the remote machines? (is that smart?) Or is there some existing service I can use to pass the data through a socket on demand? I suppose there must be ways to tie this into a webserver, but I have no desire to run one. Any advice appreciated. Thanks!! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Selecting certificate to be presented by a given endpoint in establishing an ssl connection
Quick question regarding certificate usage in an ssl connection; you can associate a number of certificates with a server endpoint - is there any way of deciding at runtime which certificate is presented to the client (depending on the identity of the client say). And would the same mechanism be usable for the certificate the client presents in the case of mutual authentication? (Pointers to documentation if any would be sufficient!) Thanks N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Making AES-CCM available as a TLS-negotiated cipher suite
Hello all, I've been working on getting AES-CCM available for negotiation over a TLS connection. I know that AES-CCM is available via the EVP interface, but I need it to be available as a TLS cipher suite so it can be negotiated with a client. I started adding it as a new cipher suite, in a manner to how AES-GCM seems to be implemented, but I'm having trouble just getting it reported at an available cipher using the "openssl ciphers" command. I started thinking I was going down the wrong path, since CCM is already available via EVP. Is my approach to add a new "AES128-CCM" cipher suite a reasonable one, or would it be better/quicker to just change the default mode of AES (and the related cipher suite ids) so that I can get a TLS-negotiated AES-CCM connection? Regards, Paul Muschick
Re: Please tell me about encryption API of OpenSSL 1.0.1
Hello, Edward, Jakob, Ken, Thanks for lots of ideas and information. I'll investigate Edward's block-number-based iv and Ken's CTR mode. Let me consult you if I get stuck again. I'll consider some way to eliminate the need to call EVP_EncryptInit_ex/EVP_DecryptInit_ex for each block/record. Regards MauMau __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Please tell me about encryption API of OpenSSL 1.0.1
The standard answer: If this is a real security project, hire an expert. If you design your own crypto algorithm, you will get it wrong. If this is just for fun, to learn about openssl, CTR mode will give you random access. On 4/16/2012 6:41 PM, MauMau wrote: As for Q4, yes, decrypting blocks in the same order as encrypting them certainly produced correct data. owever, I cannot do that because the application needs to encrypt/decrypt blocks/records in random order. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Please tell me about encryption API of OpenSSL 1.0.1
On 4/17/2012 1:59 PM, Edward Ned Harvey wrote: From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Edward Ned Harvey attacker doesn't know is your key and your plaintext. There is only one solution. You must use a second key. Use your first key to encrypt the second key (so an attacker can hopefully never know either one of your keys.) Use your second key combined with the block number (I suggest encrypting or hashing the block number using the second key, but simple AND or XOR should also be fine) and use the resultant data as the IV for your actual encryption operation. I don't see any reason why the second key couldn't match the first. You could simply encrypt the block number, and use the result as the IV when you encrypt your actual data block, using ECB. This is effectively reimplementing CBC, where you don't make individual blocks dependent on each other - instead you make each individual block dependent only on its block number, where you're using the block number as the preceding block of data, and the *only* preceding block of data. Every block number is guaranteed unique and independent, so you're able to do random access, and since there are never any repeats, there will never be any repeated cipherblocks, even if there is repeated plaintext. Note: I think there is a misunderstanding of the word "block" here. The OP refers to data blocks of about 4Kbyte, you refer to the individual AES blocks of 16 bytes each. As for using the main key to generate IVs from block numbers, an expert once confirmed to me that the following should be safe: Set CBC-IV=AESrawFunc(key, block number). I think (not sure at this moment) this is the same as Set CBC-IV=CBC-AES(key, 0, block number) // Second arg is IV Which for encrypt (but not decrypt) I think is the same as Set encrypted=ThrowAwayFirst16Bytes(CBC-AES, 0, Concat(block number-as-16-bytes, 4K data block)) Decrypt will need to do the two steps separately. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Please tell me about encryption API of OpenSSL 1.0.1
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Edward Ned Harvey > > attacker doesn't know is your key and your plaintext. There is only one > solution. You must use a second key. Use your first key to encrypt the > second key (so an attacker can hopefully never know either one of your > keys.) Use your second key combined with the block number (I suggest > encrypting or hashing the block number using the second key, but simple > AND > or XOR should also be fine) and use the resultant data as the IV for your > actual encryption operation. I don't see any reason why the second key couldn't match the first. You could simply encrypt the block number, and use the result as the IV when you encrypt your actual data block, using ECB. This is effectively reimplementing CBC, where you don't make individual blocks dependent on each other - instead you make each individual block dependent only on its block number, where you're using the block number as the preceding block of data, and the *only* preceding block of data. Every block number is guaranteed unique and independent, so you're able to do random access, and since there are never any repeats, there will never be any repeated cipherblocks, even if there is repeated plaintext. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
