OpenSSL support a lot of systems, but that is not support XBox One, because XBox One only C++ compiler so there is no way to support?
Separate from OpenSSL some of the algorithms seem very troublesome, if I want to use XBox One above encryption algorithm should be how to do?
Related
The title is self explanatory.
A decision was made early on not to re-invent crypto in managed classes, it caused lots of problems for FIPS and frankly why re-invent the wheel?
So we use the OS facilities for crypto - we call into CNG on Windows, and then, because OpenSSL is basically the standard on Linux we use that. It also means when there are crypto bugs you don't have to wait for .NET Core to get updated, you just update the OS.
I have been trying for a while to do some basic cryptography on my Mac OS X Mavericks. I would need MD5, SHA256, AES and possibly also RSA.
I need to develop in C++ but I only need a terminal application with Xcode. I DON'T need to do anything on iPhone. I have a very basic configuration and I am not an expert. I tried crypto++ and OpenSSL, both gave me immense lists of errors at build time.
Thanks!
Apple supplies several encryption Technologies Specific to OS X: General information.
CommonCrypto, a C-level API that can perform most symmetric encryption and decryption tasks
CDSA/CSSM—a legacy API that should be used only to perform tasks not supported by the other APIs, such as asymmetric encryption.
Security Transforms API—a Core-Foundation-level API that provides support for signing and verifying, symmetric cryptography, and Base64 encoding and decoding.
There is also OpenSSL, it is useful for many command line operations but is no longer provided by Apple mainly due to the incompatibilities between versions.
CommonCrypto is supported by both OSX and iOS, this is what I generally use. Security Transforms are OSX only and the newer technology. There are many examples of CommonCrypto usage on SO as well as libraries in GitHUb.
My suggestion is CommonCrypto, it is a "C" library so there should be no problem using it from C++.
We are selling an image processing application (about 120k lines of code) developed with wxWidgets. We planned everything to be as most cross platform as possible in case the porting from Windows to other OS was needed. And in fact we are going to realiza a version for Mac.
We haven't tested wxWidgest on Mac yet, but we haven't read very good things about it.
In general, do you think is it worth to port from wxWidgets to QT? Do you believe it will be an hard and long job?
Is QT for Mac much better than wxWidgets implementation?
Is QT much more productive that wxWidgets?
I would like to add that we would'n like to keep code bases for gui, so the choice is just wxWidgets vs QT.
Test your application on Mac, and then decide. If there are only a few wrinkles to iron out, why put in all that extra work to switch toolkits?
It will be a long hard job. Without knowing more about your application and situation, it is hard to say whether making the switch is worth the effort. I do know that I would rather work on a Qt app than a wx app.
I have a friend who recently switched a significant wx application to Qt, and he is quite happy with the change. Mac support is one of his (boss's) important features, but I think wx's support for Mac was adequate, if not stellar.
My experience has been that Qt is definitely more productive than wx.
It is worth noting that wxWidgets on the Mac is transitioning to Cocoa. This should be done for wxWidgets 3.0, but is testable with the development release wxWidgets 2.9 now. Is Qt Cocoa or Carbon based?
We have an application that runs under Windows and the Mac, built using wxWidgets. The application performs very well on both platforms.
I recommend switching over to Qt. wxWidgets is a GUI toolkit, whereas Qt is an application framework with much, much more features.
I can't say anything about their mac implementations, but i can clearly say that i am far more productive using Qt. When i was using wxWidgets, i was a student and then when i got a job, i started using Qt.
wxWidgets gave me a feeling of incompleteness, but as i said, this may be caused by the fact that i was an inexperienced student but nonetheless, i think Qt is way better.
Until you have investigated more and have a good reason(s) to switch toolkits, then absolutely not.
We are using wxWidgets for Linux & the like, Mac, and Windows. It's a great toolkit and certainly much more than just a GUI.
Like dtw and NuSkooler, we are using wxWidgets on Mac (carbon/cocoa), Linux (32/64), Windows (32/64) and all works fine. In wx, we use gui, filesystem, threads, html libs.
+1 for Qt
I have used both wxWidgets and Qt extensively on different projects for the Windows platform writing C++ applications.
Having used both and compared the two after, I would absolutely use Qt over wxWidgets. You need to consider (as some of the others have pointed out) if the re-factoring effort is is something you have time for and are willing to do.
Also consider the cost -- this may not matter in your situation, but unlike wxWidgets, the Qt Library is not free for commercial use. I have spoken to TrollTech at length and read through their licensing agreement to verify this; you definitely have to pay unless you GPL your application.
Regarding licensing see:
http://qt.nokia.com/about/licensing/frequently-asked-questions
"Will you continue to offer Qt under a
commercial license?"
"Yes, absolutely. Our commercial
licensing will continue."
"Why would I want to buy a commercial
license? What is the difference?"
"The commercial Qt license includes
email support, access to upgrades and
allows you to develop fully closed
source software. The LGPL carries some
restrictions regarding the ability for
users to relink libraries and other
restrictions that may impose
architectural requirements that some
organizations might not be comfortable
with."
Qt is definitely worth the money though, even if you are not doing cross-platform development. It has a lot more and better documentation. Qt and wxWidgets are not perfect... The fact that they are bloated and provide APIs for networking, data structures, and database handling is not necessarily a good thing. Sometimes sticking with the STL or Boost libraries (if you're coding in C++) is a much better solution.
Good luck.
-bn
+1 for wxWidgets. A big project of mine used wxWidgets and found it a nice framework to use, and an easy enough framework to get your head around to modify if you need to (to support Mac specific features).
Try it: you could be 80% there when you first generate the binary.
Which technology stack do you recommend for developing native windows executable (has GUI), other than .NET stack?
Other that C++ (MFC, ...) some could be named; yet which one is mature and pragmatic enough?
Delphi 7?
Common Lisp (Which one is proper for developing GUI?)?
Scheme?
Qt or wxXXX stack?
For native Win32 GUI apps, I've found nothing that beats Delphi. (Your question asks about Delphi 7, but please note that all versions of Delphi (including the latest - Delphi 2010) can produce single, standalone .EXEs).
Python is a good choice for some sorts of problems, and you can package python programs into a single .exe using py2exe.
Here is a nice py2exe tutorial: http://www.py2exe.org/index.cgi/Tutorial
Tcl/Tk is very mature, has a small footprint, is easy to learn and use, and uses native widgets on Windows and the Mac. Plus, it has a deployment mechanism second to none by way of starpacks, starkits and tclkits. You can either create a single-file executable (starpack) that embeds a very full featured virtual filesystem, or a two-file solution of a platform-specific runtime engine (tclkit) with a platform-independent application file (starkit).
It's downside is that it's low on "flash" -- there's not a lot of support for transparency, multimedia, animation and fancy graphics. So, depending on whether or not you need a lot of eye candy it may or may not be the right choice for you.
I am working on a project that does a large amount of hashing, signing, and both asymmetric and symmetric encryption. Since these steps have a significant effect on our performance and available load, I was wondering if there is a hardware based solution to offloading the work.
I have done some surfing to find out, and the only items I can find are dedicated to SSL based communications. I need a more generic solution that will allow me to speed up signing and encryption regardless of where it occurs.
Is it possible to adapt these SSL based solutions (maybe it's just marketing and it would be easy to re-use elsewhere)? Is there a good generic co-processor that can help out?
I need this on a Windows Server 2008 based box, but I would be interested in solutions on any platform.
If the algorithms you're working on are standard encryption algorithms like 3DES and AES, there is definitely hardware available. Hifn is the most well known, but Broadcom also has a line of chips from their BlueSteel acquisition a number of years ago. nCipher also has a line of encryption products, though when last I looked at them (years ago) they were much more focussed on their secure key management hardware than the acceleration of block algorithms.
Even cards designed for SSL may be useful to you, though you'll need to get access to the low level details. The biggest win for SSL hardware is an exponentiator and wide multipler unit, both of which are generally accessible independently in the hardware I know of. If you're using asymmetric encryption algorithms, these two units would likely be useful to you as well.
You should also check whether a more efficient software implementation is available. For example, Dan Bernstein and Peter Schwabe published a paper in September 2008 regarding optimization of AES for modern CPUs. The software implementation has been placed in the public domain (i.e. disavow all copyright, use it however you like).
Finally, future AMD (and probably Intel) CPUs will include SSE5, which adds instructions specifically useful for AES. If you can hold out until then, your next server upgrade may provide all the hardware support you need.
I'm not sure how helpful this will be, however I have seen a few papers dealing with using Graphics Hardware to accelerate encryption
Heres a quick google search
Good Luck.
Several companies make cryptography-specific hardware. For example, I recently coded support in an application for a nCipher hardware device which processed AES on the card (and supported many other encryption algorithms). They are not cheap, but they do support a variety of algorithms and modes of operation.
The most popular hardware crypto engine is VIA Padlock, included in C3, C7 and later processors. These are low-performance, low-power; but (supposedly) easily outperform a Core2 on crypto algorithms.
Linux kernel 2.6.16 and later include support for RNG, MD5, SHA1/256, SSL, GPG and other standard things. I'm not sure about ssh.
You mention non-SSL, so you might not benefit from existing code, but Via's site has the documentation needed to use it from userspace.
On windows you want to find a device that has an API that supports MSCAPI, CAPING or PKCS#11, The first and last are all very common, MSCAPI however does not support hardware AES/3DES.
nCipher (now Thales) Do several boxes or PCI/PCIe cards that support the above (and support openssl) and also support other platforms inlcuding Linux and Solaris, Safenet do similar hardware too with similar platform support.
If I were starting out I would pick PKCS#11, you then get a good choice of languages to write in including C or java.
If you want to write in C#/.Net then you can use MSCAPI from .Net or you can PInvoke into the PKCS#11 DLL for your hardware.