Post reply

Free Encryption

  • February 27, 2006 at 6:18 am

    #623426

    Boy I'm glad I've found your post

    I've run into the very same problem this morning and was starting to feel desesperate.

    One stupid question: where can I see the toolkit's version? I've compared the zip's timestamp and it does look like I'm not using the latest version, but I haven't been able to figure out where I can see the actual version number.

    I also wanted to thank you for your toolkit, it's been very helpful, it's very nicely documented and really easy to use.

  • March 12, 2006 at 6:54 pm

    #626156

    Hi, the version is on the DLL's themselves.  Right click on one of the DLL's and the version should show up in the info. window.  The original DLL's didn't have version numbers, but the most recent ones do.

  • March 14, 2006 at 2:48 pm

    #626654

    We had this exact same situation-- memory fragmentation will all sorts of ugly errors: "General Network Error" and "There is insufficient system memory to run this query" and a few others. Turns out we had the "versionless" version-- installed version 0.9, and everything is working like a charm now. Thanks, Mike!

  • March 14, 2006 at 5:15 pm

    #626675

    No problem   I'm working on a newer version now that operates similarly to the SQL 2005 T-SQL encryption commands with key management, custom initialization vectors, multiple encryption keys encrypted and stored securely right in the database and hashing -- all accessible from within your T-SQL queries.

  • March 16, 2006 at 2:41 pm

    #627164

    Chris, were you able to resolve this problem:

    ODBC: Msg 0, Level 16, State 1

    Cannot load the DLL xp_rot13.dll, or one of the DLLs it references. Reason: 126(The specified module could not be found.).

     

    If yopu did could you please send the method you applied because I am getting the same error and have not been able to figured out the caujse of the problem:

     

    Thanks in advance

    Desmond

  • March 16, 2006 at 9:52 pm

    #627190

    This problem is caused by a couple of possible things:

    1.  The DLL's for the XP's are not in the MSSQL/BINN directory.  Make sure you've copied them into that directory.

    2.  The Open Data Services DLL and/or Visual C++ Runtime Library aren't on a default path for your SQL Server.  The easiest fix for this issue is to copy these two DLL's to you MSSQL/BINN directory.  This seems to be a recurring issue on SQL 2003 Server and SQL 2000 installations mostly.  I've included both of the versions of these libraries that I compiled with in the newest download.

    3.  Less likely, but you might have to change the build scripts as outlined in the README files in the download.  In particular, you might have to put the full path to the DLLs in the statements that install the extended stored procs.  I ran into this issue on a SQL 2003 test install.

  • March 16, 2006 at 9:56 pm

    #627191

    As I mentioned above, I'm working on a newer encryption toolkit, and I'm almost to the point of beginning the testing process.  If anyone out there has the time, energy, a spare machine and some data and would like to help me test it out, send me an email.  This is a lot more ambitious project than the previous version, as I'm basically mirroring the SQL 2005 encryption capabilities on SQL 2000 via extended stored procs.  I can use feedback on features, usability and general testing.  Thanks!

    So far I have implemented the following:

    • Built-in secure key management
    • User-defined key length Blowfish encryption
    • User-defined key length AES encryption
    • 56-bit key length DES encryption
    • 3x56-bit key length Triple DES (EDE style) encryption
    • SHA 256, 384 and 512 bit hashing
    • Better exception handling, better memory management and several speed optimizations

    I'm adding even more as we speak, and any feedback is appreciated.

    Thanks!

     

  • March 20, 2006 at 12:26 pm

    #627691

    Hi, we are using the AES encryption with NVARCHAR fields -- we made the changes as suggested in an earlier post.  It works fine except that when it tries to decrypt an unencrypted string we get a fatal error:

    SqlDumpExceptionHandler: Process 95 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process..

    This error locks up the SQL server and it has to be rebooted.   Is there a way to have it simply return an error or null value instead of generating a fatal exception? 

    I am also having trouble using different keys other than the 16 bit key in the sample files.  I tried using XP_Generatekey 256 and then xp_base64decode the result but when I use that key I get a bunch of null values or incorrect results.  Any suggestions?

    I double-checked and we are using the 0.9.0.0 version of the DLL's.

  • March 20, 2006 at 2:24 pm

    #627714

    Hi Kristine,

    Let me understand this - you're trying to decrypt a string that's not currently encrypted?  Is that correct?  You must be a QA person

    I've actually implemented encryption using more robust algorithms (see above post) that return NULL or garbage values when you try to do strange things like decrypting unencrypted strings.  I'm in the process of testing these new XP's now.  So far they are a lot more robust, and exit much more gracefully than the 0.9 [and previous] batches.

    I'm not sure what the problem is that you're having with XP_GenerateKey and XP_Base64Decode.  Are you storing the result of XP_Base64Decode in a VARBINARY?  (Needless to say I've also created a non-Base64 key generator with a much better random number engine than the C/C++ Rand() function, and I've set up a key management system that lets you encrypt/decrypt by key name while the system worries about managing the key details.)

    Are you using VARBINARY columns to store your encrypted data?  There have been issues with storing encrypted data in VARCHAR and CHAR columns, because SQL doesn't like some of the non-printable characters that can result from encryption.  In some cases it can truncate these values, or strip trailing non-printables, causing problems similar to the ones you're describing.  The truncation problem applies to keys as well.

    Finally, the NVARCHARs seem to cause issues because of how they are passed by SQL Server.  I think I pointed out in the article that these XP's were written specifically to handle CHAR and VARCHAR data.  NVARCHARs wouldn't be a problem except for the fact that SQL Server likes to drop the trailing NUL (ASCII 0) character from the end of NVARCHARs when they are passed into XP's, which results in loss of the last character in your string.  This causes problems.  The newer batch of XP's specifically handles everything in VARBINARY format.  To convert back, you CAST() to VARCHAR() or whatever other format you need.  I'm testing them against NVARCHAR() data as well.

    If you're interested, I can get the newer ones to you shortly and you can try them out.  I could use the help testing, as I've created over a dozen XP's so far with more in the works.

    Email me if you're interested.

  • March 22, 2006 at 10:24 am

    #628166

    Thanks for all the great feedback via email on the new tools I'm developing, and special thanks to the folks who are helping me test it!  I've just added regular expressions to the list of tricks this new toolkit performs.  I could use feedback on these tools from a few more people.  If you are interested in kicking the tires on this thing before I publish it to SSC, email me directly.  Thanks again.

  • March 24, 2006 at 11:59 am

    #628714

    I think I've found a few bugs.

    First of all, the constant in xp_generagekey:proc.cpp & blowfish*:proc.cpp

    #define ERR_KEY_SIZE "Key (@param2) must be 32 - 448 bits in length (8 - 56 bytes)"

    should be

    #define ERR_KEY_SIZE "Key (@param2) must be 64 - 448 bits in length (8 - 56 bytes)"

    In addition, you might want to modify the code in xp_generagekey:proc.cpp

    if (sqlerr == XP_NOERROR && (keylength % 8 != 0 || keylength 448)) {

    to fit the 64-bit restriction:

    if (sqlerr == XP_NOERROR && (keylength % 8 != 0 || keylength 448)) {

    Lastly in xp_generagekey:proc.cpp,

    BYTE *encodedkey;

    ULONG encodesize;

    BYTE *key;

    ULONG keylength;

    should have two NULL initializations, as if the user passes in a string < n bits, the two BYTE* variables never get initialized:

    BYTE *encodedkey = NULL;

    ULONG encodesize;

    BYTE *key = NULL;

    ULONG keylength;

    Otherwise, an access violation occurs here:

    // Clean-up
if (key != NULL) {
    memset(key, 0, keylength);
    delete [] key;
    key = NULL;
}
if (encodedkey != NULL) {
    memset (encodedkey, 0, encodesize);
    delete [] encodedkey;
    encodedkey = NULL;
}

  • March 24, 2006 at 1:34 pm

    #628743

    Thanks for the feedback.  You might want to check out:  http://www.schneier.com/blowfish.html.  The key length for Blowfish keys is specified by Bruce Schneier as 32 bits to 448 bits, multiple of 8.  The block length is 64 bits; the user doesn't have an option to change block length, however.

    The second part I've already fixed in a newer set of tools that I'm considering releasing.  I've re-written this routine and the others to handle a lot more user-generated errors and exceptions.

    Thanks.

  • May 2, 2006 at 9:19 am

    #635347

    We were wondering if you have heard of these problems:

    When converting a very large database (4 million+ records) the conversion takes forever.  (ran for over 12 hours).  Is there a way to speed up the aes encryption?

    We are alos having a problem with the SQL bombing with what appears to be a memory allocation problem (probably a memory leak).  The SP converts one table at a time and eventually blows up, each time it does it is in a different place.  Any suggestions on how to correct this problem?

  • May 2, 2006 at 9:43 am

    #635356

    Hello,

    I've personnally converted a big table (about 5 million rows), and it didn't take that long. About 3 hours on a two year old server.

    On an old server, the conversion of 1.2 million took about 3 hours. The same conversion on a newer piece of equipment (two times more memory, faster CPU) really toook less time (less than an hour). Please note that all our servers are dual or x4 processors.

    Regarding the memory leak, that's probably because you're not running the latest version of the toolkit (please see previous posts).

  • May 2, 2006 at 10:38 am

    #635373

    The location that is doing the conversion has millions of rows in multiple tables.  We are encrypting a column in 14 different tables.  The locatiojn is our biggest client.

    I have little idea what they are running this upgrade test on.

    We are runing the latest version (0.9).

     

Viewing 15 posts - 61 through 75 (of 153 total)

You must be logged in to reply to this topic. Login to reply