2uppence worth If you have an array of objects you would still need exclusive access to each array, so your example is fine "if" 1 and only 1 thread has access to each array element. It's the same as mutual exclusion with a mutex, bottom line is do not allow multi thread access to a common crypto object in a raw state. Best to create your own objects and protect those, that way you are safer and can supply a degree of abstraction if you alter algorithms/libs later on.
Best Regards David Irvine On Mon, Oct 8, 2012 at 12:25 PM, Folkert van Heusden <[email protected] > wrote: > Hi, > > I have a question regarding thread safety of crypto++. > The readme says: > > "2. Crypto++ is thread safe at the class level. This means you can > use Crypto++ safely in a multithreaded application, but you must > provide synchronization when multiple threads access a common Crypto++ > object." > > This is a bit ambiguous to me. > Does this mean that if I have multiple instances(!) of, say, a > blowfish encryptor, that I still need to do locking? > E.g.: > > typedef struct { unsigned char iv[8], key[16]; } entry_t; > entry_t pars[10]; > // init each pars-entry > > CryptoPP::CFB_Mode<CryptoPP::Blowfish>::Encryption *enc[10]; > for(int i=0; i<10; i++) > enc[i] = new > CryptoPP::CFB_Mode<CryptoPP::Blowfish>::Encryption(pars[i].key, 16, > pars[i].iv); > > Now if thread A wants to use enc[0] and thread B wants to use enc[1], > do they still need locking to be able to do so? (e.g. due to global/static > variables etc in the used classes). > > -- > You received this message because you are subscribed to the "Crypto++ > Users" Google Group. > To unsubscribe, send an email to > [email protected]. > More information about Crypto++ and this group is available at > http://www.cryptopp.com. -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
