August 13, 2007 at 8:04 am
Hi rsomasundar,
You'll need to modify the class that contains the encryption algorithm. I believe it's called AES, or something similar (sorry, can't look into the source code right now). You'll probably have to add your own implementation of PCKS7 padding. The mode used in the toolkit is CBC, so you should be good there. The source code is in VC++ 7.1, so you might have a bit of a learning curve if you've only used VB. I recommend looking at the AES class first to determine what is going on there. If I were trying to make it interoperable with the .NET Cryptography classes, I might even consider replacing the AES class with a wrapper around a call to the Windows CryptoAPI encryption call using AES. AFAIK the Windows CryptoAPI AES implementation is only supported on Windows Server 2003 (or at least it used to be only supported there...)
November 27, 2007 at 4:42 am
Hi Mike,
Great set of tools, thank you.
I'm trying to extract Dir/File data relating to database and doc managent filestore on our production db server, for monitoring purposes. Your xp_dirscan proc is the ideal tool, but It seems to be truncating 'Size' values for some of the larger files. Bigint is the type used for the 'Size' column.
An example would be:
for one db file the proc returns a 'Size' value of 1619656704 (1,581,696 Kb), which matches the windows explorer file size.
for a different db file the proc returns a 'Size' value of 771555326 (753,472 Kb), which does not match the windows explorer file size of 9,142,080 Kb.
It may be something I've missed.
Thanks,
Wayne
December 6, 2007 at 11:07 am
I'm experiencing the same DLL 126 issue described above...has anyone solved this????
December 6, 2007 at 6:01 pm
The system is windows XP SP2
SQL Server version : 8.00.194
Followed the instructions in the INSTALL NOTES document.
Tried both ADD_XP.SQL scripts but nothing works.
I keep getting this error message on trying to run ROT13.SQL file provided in the sample_sql document
"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.)."
the MSSQL/Binn directory contains the opends60.dll (version: 2000.080.0194.00) and the MSCVR71.dll (Version: 7.10.3052.4) files. The dependency watcher output for xp_rot13.dll shows no flags.
I used an exe generated from a c program called loadlib.exe where i provided the library name (in this case xp_rot13.dll) and the function name (in this case xp_rot13) and it outputs 'xp_rot13 found and loaded successfully."
Please point out my error. Thanks.
April 25, 2008 at 3:42 am
No need to invoke CLR (only if you want greater speed).
Free RC4 encryption here
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=76258
Free MIME64/BASE64 encoding here
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=67831
Free ROT algorithm herehttp://www.sqlteam.com/forums/topic.asp?TOPIC_ID=67752
N 56°04'39.16"
E 12°55'05.25"
April 25, 2008 at 11:05 am
Thanks for the wonderful article. This thread has been around a long time. That means that the code has had the $%^ beat out of it already.
Have you tried this with the Compact Edition yet (SQL Server CE)? I'm interested in encryption for handheld databases.
ATBCharles Kincaid
April 27, 2008 at 9:59 pm
Hi jpachman,
Sorry I didn't see your post sooner. I only tested on SQL 2000 SP 4, and it looks like (from the version number you gave) that you're running on a non-patched RTM release. Installing the latest service pack may help resolve your issue since there are some known issues with the non-SP'd versions. I would definitely try that first. The next thing to check is the path when the XP's are added. SQL Server defaults to the BINN directory when looking for XP DLL's, but depending on the path specified when it's installed SQL Server may not be able to locate the DLL. I would definitely address the service pack issue first though.
April 27, 2008 at 10:02 pm
Hey Charles,
I haven't had an opportunity to test on compact editions (mostly because I don't have access to any right now). It does sound like an interesting idea though, and I'd love to hear the results if someone does try it out.
BTW, Steve was kind enough to post the C++ source code for this project somewhere here on the SSC site. I imagine if it doesn't work as-is on compact editions it could probably be modified to use functionality supported on the compact platform.
April 27, 2008 at 10:04 pm
Hi Wayne,
There are some interesting issues surrounding the bigint data type, but I don't know why it would be giving you results so out of whack. I'll look into it when I get a chance. Thanks!
April 27, 2008 at 10:08 pm
Peso (4/25/2008)
No need to invoke CLR (only if you want greater speed).Free RC4 encryption here
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=76258
Free MIME64/BASE64 encoding here
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=67831
Free ROT algorithm herehttp://www.sqlteam.com/forums/topic.asp?TOPIC_ID=67752
Thanks for the links! Actually the XP's here don't use CLR - they are native extended procedures. The BASE64 encoding was included as a convenience feature, and the ROT algorithm was added as a test proc to ensure the installation went smoothly. I decided to implement AES in this release instead of RC4.
April 28, 2008 at 1:07 pm
I must be further behind on my encryption terminology than I thought. The blurb for the article says:
Free SQL Server 2000 Encryption for your data!!! Author Michael Coles has put together a tolljit and some XPs that you can use to encrypt your data with the Blowfish algorithm.
Google only brings me back to here when I try to figure out what a "tolljit". JIT, I figure, means "Just In Time", but that is only a guess.
April 28, 2008 at 1:24 pm
I think it was supposed to say "toolkit" 🙂
May 21, 2008 at 10:09 am
Hi Mike,
Thanks a lot for the encryption solution, it works excellent.
We are working on a solution where we have to provide sorting on the column which is encrypted.
This seems to be impacting a lot on the performance.
Could you please suggest something on this?
Thanks,
Kamalesh
May 22, 2008 at 9:34 pm
Hi Kamalesh,
Well, the problem is that searching/ordering data and encrypting it are two problems with diametrically opposed goals. When you search and order data transparency is your best friend, and raw speed is generally a driving goal. Sorting and searching rely strongly on patterns inherent in the data (for instance "A" comes before "B", "B" comes before "C", etc.).
Encryption removes transparency. The goal of encryption is to obfuscate your data and remove patterns. In terms of encryption the more patterns you remove, the more secure your data from attack. Encryption removes the patterns that allow you to sort data and search on ranges of data without going through the decryption process first.
By not using a SALT/IV you can perform exact equality searches on encrypted data. You can also create a hash of your data for search purposes, although this could expose statistical patterns in your data to hackers.
Thanks
Michael
July 25, 2008 at 9:28 am
Has anyone used the xp_blowfish dll on SQL 2005? We just moved to a new server and we're getting error messages to the effect.
Could not load the DLL C:\Program Files\Microsoft SQL Server\90\Tools\binn\Encryption DLL\xp_blowfishdecrypt.dll, or one of the DLLs it references. Reason: 193(C:\Program Files\Microsoft SQL Server\90\Tools\binn\Encryption DLL\xp_blowfishdecrypt.dll is not a valid Win32 application.).
Viewing 15 posts - 106 through 120 (of 153 total)
You must be logged in to reply to this topic. Login to reply