In the following MSDN page it states the encryption algorithms that are supported by BizTalk 2010
http://msdn.microsoft.com/en-us/library/aa559843(v=BTS.70).aspx
"BizTalk Server supports RSA and Diffie Hellman encryption certificates.
BizTalk Server supports Data Encryption Standard (DES), 3DES, and RC2 encryption algorithms."
My question is - Can BizTalk also support SMIME messages encrypted using the newer AES encryption algorithm?
3DES is getting quite old now and is getting replaced by AES so I'm wondering if BizTalk has built in support for it yet?
Thanks.
I've finally got an answer that Biztalk does not currently support AES encryption.
We are now looking into alternative workarounds to solve this issue..
Related
I wonder about PKWARE Strong Encryption algorithm.
ZIP File Format Specification v6.3.5 says about Strong Encryption by PKWARE (7.0 Strong Encryption Specification). This description is not completed and it's impossible to implement this encryption in the application.
I wonder about is there any working source code using this encryption algorithm? Does not matter what language. I'm planning to add it to my own application but did not succeed yet.
P.S. This is not a Traditional PKWARE Encryption, that described in 6.0 Traditional PKWARE Encryption
To my knowledge, there are no open source implementations.
The strong encryption functionality is patented. If you have not already done so, contact zipformat#pkware.com to obtain a license.
After you have a license, if you provide more details about what you think is missing from the description, I can try to help.
Source: I'm an engineer at PKWARE
what is difference between symantec command line pgp encryption and other pgp encryption tool like iGolder,GnuPG etc.
Is it possible that a file pgp encrypted by symantec command line that can be decrypt by other tool like iGolder,GnuPG, bouncy castle etc.
In general, compatibility between various OpenPGP applications and libraries is achieved by using the algorithms defined in the RFC 4880. This means that if Symantec PGP follows OpenPGP standard and doesn't use proprietary patented extensions (they do exist), the resulting file would be handled by other applications.
The other thing to check is that the algorithm used by the originating application is supported by the software that decrypts the file later. For modern versions this is not an issue, but some companies use the dated versions of PGP software, which doesn't handle some of the newer algorithms. In this case you can have an issue.
I am starting a communication test work with a webservice, and this interaction includes encryption protocols AES and RSA. However, the site that has the webservice (followzup) only provides examples in PHP and Java.
How to proceed this test? What protocol should I use first?
I've got a situation where the source system has PGP installed, and they can only encrypt the file with PGP tool, and Target System has GPG installed, and we can decrypt only using GPG. is is possible to accomplish this functionality ?
The thing with encrypting is the encryption algorithm you're using. These algorithms are published and documented - and that means anyone can write code to implement it.
PGP is a piece of software written to implement a crypto algorithm. GPG is the Gnu implementation of the same.
So there's no reason to think this wouldn't work - as long as you use an algorithm that both products support. I believe GPG has more options than PGP.
From:
http://en.wikipedia.org/wiki/GNU_Privacy_Guard
As of versions 2.0.26 and 1.4.18, GnuPG supports the following algorithms:
Pubkey: RSA, ElGamal, DSA
Cipher: IDEA (from 1.4.13/2.0.20), 3DES, CAST5, Blowfish, AES-128, AES-192,
AES-256, Twofish, Camellia-128, Camellia-192, Camellia-256 (from 1.4.10/2.0.12)
So as long as your encrypting application uses one of these it should work fine. (RSA is probably a pretty good bet.)
We are putting an HTTP RESTful interface into an embedded platform of ours. The hardware is too limited to support SSL, but we do use AES encryption for other things.
I'm thinking of using AES with a shared key to encrypt the data. Is there anything else that is at least a somewhat standard way of encrypting via HTTP?
The standard way of encrypting HTTP is SSL (or its successor TLS, nowadays) (this is then known as HTTPS).
As GregS asked in a comment, in what way is your platform too limited for SSL, but still allows AES? Does it have not enough computing power/memory to do modular exponentiation (which is used in RSA, DSA, Diffie-Hellman)?
Then you might be able to use a pre-shared key version of TLS. RFC 4279 defines cipher suites with pre-shared key authentication, where the TLS_PSK_WITH_AES_128_CBC_SHA looks like if needs only AES and SHA-1, no modular exponentiation.
Of course, you shouldn't use this if there is the danger that an attacker can get the secret (e.g. by cracking your device), since this allows also to read all previously registered connections (in contrast to Diffie-Hellman, which provides a new session key for each session).
Found this gem: Diffie-Hellman Key Exchange in 10 lines of C
http://www.cypherspace.org/rsa/dh-in-C.html