I'm in a situation that I need to use AES-256, SHA1,2 and RSA, but these functions need to be loaded from an intrinsic windows dll file (something like cryptoAPI in advapi32.dll, which can be found in C:\Windows\system32).
I've found almost everything I need in advapi32.dll except RSA encryption. So,do you know any other crypto libraries from windows (XP2 should be supported)?
In the worst case, any free external crypto library in dll format is appreciated.
RSA encryption/decryption is supported by the CryptoAPI.
From http://en.wikipedia.org/wiki/Microsoft_CryptoAPI:
[...]It is a set of dynamically linked libraries that provides an abstraction layer which isolates programmers from the code used to encrypt the data.
So, advapi32.dll ≠ CryptoAPI. However, since it is an abstraction of the CryptoAPI functions, linking to that dll should expose whichever functionality you need, algorithm-agnostic.
To answer the question strictly, the CSP library file that handles RSA stuff is rsaenh.dll. However, I'm not sure why you should need to know that necessarily; like #SimonMourier (and I) stated, CryptoAPI handles linking to the appropriate CSP. Calling the appropriate functions from advapi32.dll should allow the use of a variety of algorithms, including RSA.
If you're really that averse to using the built-in Windows stuff then there's always Crypto++. It supports being compiled as a DLL afaik. http://www.cryptopp.com/
Without using .Net or a 3rd party component, I've found no reasonable solution for RSA in windows. So, about .Net, please see klugerama's last comment. About 3rd party component, I've found a great library for VB6 user, which will works in Windows XP without the installation of .NetFramework 2.0+. It's called VBCOrLib :
http://www.kellyethridge.com/vbcorlib/
Alternative solution for C++ users was Crypto++ as suggested by RaptorFactor.
Thanks for all your helps !
Related
I am not sure if StringCbPrintf and the include file strsafe.h where it is defined belong the the WinAPI. On one hand, Microsoft documents the function on its WinAPI sites and strsafe.h is under the Windows SDK directory structure which indicates (to me, at least) that it is indeed part of the WinAPI. On the other hand, strsafe.h includes stdio.h etc. which belong to the CRT. I was always under the impression that the WinAPI is completely independent from the CRT (but not vice versa). Possibly, my assumption about the relationship between WinAPI and CRT is wrong. Thus my question: is StringCbPrintf part of the WinAPI?
The StrSafe API is a bit strange because it does not have its own .DLL nor its own exported functions. I assume it was developed this way because it needed to support older versions of Windows that had already been released. It was created during the WinXP service pack security push:
During February and March 2002, all application development in
Microsoft stopped and developers took part in the Security Push
initiative. The goal was to check all code for possible security
vulnerabilities and fix those problems. One of the outcomes of the
Security Push was a library of safe string functions called
"strsafe.lib" with an associated header called "strsafe.h." This
library is available through the Platform SDK that can be downloaded
from the MSDN web site and is automatically installed as part of
Visual C++.NET 2003.
As far as I can tell, a copy of strsafe.h was also included with Writing Secure Code (Second Edition) by Michael Howard and David LeBlanc but I'm not sure if they are the original authors (David LeBlanc is the author of SafeInt):
You can find a copy of Strsafe.h in the companion content in the
folder Secureco2\Strsafe.
msvcrt.dll is basically a system file these days, only Windows 95 shipped without it. You are not supposed to use it as your C run-time but SDK code from Microsoft can probably use it without issues.
msvcrt.dll is now a "known DLL," meaning that it is a system
component owned and built by Windows. It is intended for future
use only by system-level components.
If you want to use msvcrt.dll as your C run-time as well then you must use the WDK for <= Windows 7 but when using the inline version of StrSafe.h, as long as you link to a .lib that contains the required vsnprintf type functions it should not really matter which CRT it comes from. There is also a StrSafe.lib file but Microsoft recommends that you use the inline version.
You are correct that the Windows API is supposed to be independent of the CRT but StrSafe also supports stdin functions like StringCbGetsA and they did not choose to separate those into a separate header for whatever reason. That combined with the need for a existing vsnprintf type function to do the actual work means that StrSafe is somewhat attached to the CRT even though it is meant to be used by all WinAPI developers.
There is probably no true answer to whether it is part of the WinAPI or not since it is a bit subjective. Since it is included with the SDK in the include folder one would assume that Microsoft believes it is a SDK/API component and not a CRT component.
If it's not implemented in Windows and exported from one of its DLLs (as e.g. CreateFile() or CloseHandle() from kernel32.dll), I'd say it's not part of the WinAPI, even if it ends up calling things that are implemented in Windows.
TL;DR: How do you verify the digital signature of a COM interop assembly from VB6?
Full question: I have a legacy VB6 project which needs to call some .net code (these requirements are a must). We think the best way to do this is with COM interop. However we don't want any hackers switching out the COM assembly for a fake one. We think the best way to guard against this is to digitally sign the COM assembly. If this is the best way to go (please say if otherwise), how do I verfiy the digital signature of the COM assembly fromVB6?
I've tried googling but all I get is 3rd party libraries or implementations for verifying specific signing algorithms. Surely there must be a simpler way?
Thanks!
I am trying to write my own CSP. I am trying to do this by implementing a dll file, but I am not sure if I am on right way.
I found something like this:
Cryptographic Service Provider Developer's Toolkit (CSPDK)
there are samples with CSP API
CPAcquireContext
CPGenKey
... etc.
(it looks for me like an old api or api for winCE)
And here comes my question, which functions should I implement to provide new CSP for windows 7 and XP.
Is my plan good? - should I implement simple DLL and put her reference in register?
Or am i missing something?
You might be missing CNG which is a (long term) replacement for the MS Crypto API. You can create modules for that as well. Unfortunately it is only available since Vista. Windows XP is too old (and you should probably not be producing new applications for XP anyway).
Your HSM vendor will have their CSP written for you. You will get this csp when you install their driver. All you will be required is to access this CSP from your code.
To interface with your HSM vendor's CSP(check what they support), either you should use PKCS#11 or use the cryptoAPI CSP functions.
Most applications created with Microsoft developer tools need some kind of runtime to be installed first.
However most viruses never need any kind of runtime to work. Also they also seem to use undocumented core/kernel APIs without have lib files etc.
So what runtime/application do most virus /virus writers use ?
If the runtime is statically linked in (as opposed to dynamically), then an EXE will be self-contained and you won't need a runtime DLL. However, really, you don't even need a runtime library at all if your code can do everything without calling standard library functions.
As for Windows APIs, in many cases you don't strictly need an import library either -- particularly if you load addresses dynamically via GetProcAddress. Some development tools will even let you link directly against the DLLs (and will generate method stubs or whatever for you). MS tries to ensure that names for documented API calls stay the same between versions. Undocumented functions, not so much...but then, compatibility typically isn't the foremost of concerns anyway when you're deliberately writing malicious software.
How do you call IFileOpenDialog and IFileSaveDialog from VBA?
According to Microsoft, applications written for Windows 7 and later should use IFileOpenDialog/IFileSaveDialog API calls instead of GetOpenFileName/GetSaveFileName (see Using the Common File Dialog). This is especially important for full Library support.
Short answer: it's probably not worth the effort.
Longer answer: the CFD interfaces don't extend IDispatch, which makes them impossible to call via late binding from VBA. That doesn't mean they can't be called from VBA, but it means they require a typelib to describe the "shape" of the IUnknown-based CFD interfaces. Unfortunately, Microsoft doesn't provide the CFD interface definitions in a typelib. You can roll your own typelib by reverse-engineering the header files (or try to find the original IDL in the SDK), but you'd then have to register that typelib on every machine you want to use it on (the tools for which are not shipped on the machine, unlike regsvr32 for COM stuff). Assuming you did all that, you could then reference the typelib from VBA, and conditionally call it on Vista or higher OSes. You could also shim through to a small .NET assembly that would create a System.Windows.Forms.FileDialog-derived type and marshal the results back to VBA- that would be much easier, but still more-or-less require that you register the assembly on every machine (or use C++/CLI or other hacks to export a managed DLL function), and it requires you to take a .NET dependency.
They sure didn't make it easy... :) Good luck!