9 ms·

Forget about creating your own crypto. I have had endless troubles just using crypto. Obscure options that aren't explained. Examples that don't actually work.

Forget about creating your own crypto. I have had endless troubles just using crypto. Obscure options that aren't explained. Examples that don't actually work. C# had an option that I finally got to work but the documentation specifically said not to use it; but the other choices didn't work. I had to encrypt something in PHP then decrypt it in ColdFusion. Despite being the same algorithm, key, etc, it didn't work. Strangely, the exact same data in the other direction (CF->PHP) worked just fine. I'd just like the libraries I use to have a simple choice: Encrypt(data,key) and Decrypt(data,key) and be done.

ori_b 10y ago
Have you looked at Libnacl or Libsodium?
dom0 10y ago
If it's something sparkling new you probably want to use NaCl or for more involved use cases a Noise implementation.
- tptacek 10y ago
  It's the opposite, I think: Noise is good for less-involved cases, the kinds of problems you would ordinarily solve by just using TLS. Nacl is better for when you need something customized to an application. Incidentally: Noise is great, but it's also fine to use TLS, if you're just a little careful. See also: https://gist.github.com/tqbf/be58d2d39690c3b366ad https://gist.github.com/tqbf/be58d2d39690c3b366ad
  - jjnoakes 10y ago
    The "Avoid /dev/random" recommendation, can you elaborate on that?
    - tptacek 10y ago
      https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...
      - jjnoakes 10y ago
        You should post these reasons in your gist. As I thought, there are a few reasons one might want to use /dev/random. Blanket "don't use X" statements are much more useful with context and information about why not to use X (and when using X may be required, useful, or a better choice).
        tptacek 10y ago
        No, there aren't. Don't use /dev/random.
        jjnoakes 10y ago
        The reasons I know about for using /dev/random are quoted in the article you yourself just posted here... https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...
        tptacek 10y ago
        Since I wrote that article, I'm pretty confident that it doesn't recommend ever using /dev/random.
        jjnoakes 10y ago
        I said the article mentioned reasons one might want to use /dev/random (or be careful about blindly using /dev/urandom), not that the article recommends using /dev/random. But since you wrote the article you should realize this. Just because the article recommends seeding over using /dev/random early at boot time doesn't mean the original gist shouldn't mention these issues so that readers are aware of them. Just saying "use /dev/urandom all the time" without mentioning the caveats we're discussing here means someone might read your article and in a (misguided) appeal to authority implement something solely on your recommendation without doing their research properly first. I would have thought someone writing security articles would want to avoid misleading someone into implementing something that's accidentally insecure. I hope I'm not wrong.
  - an_account_name 10y ago
    A bit of Googling reveals this to be a reply to this blog entry by Colin Percival, for those interested: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...
lordnacho 10y ago
I've run into the same issue. One of the main frustrations is you don't know if the output is correct until you manage to reproduce some known key/document exactly. When you're debugging anything else, you can sort of see what's wrong as you come closer to a correct solution. A crypto scheme is only correct (you've put the right things in the right places) when it's exactly right. Until then, you have a jumble of characters. It took me ages to match ECDSA on java with Python. In the end, it was because of some fine print where I needed to hash one version but not the other before signing.
- tptacek 10y ago
  What's especially unfortunate about this is that experts would caution you against using ECDSA at all.
  - lordnacho 10y ago
    Tell me more? I was doing some bitcoin calculations and needed it.
    - tptacek 10y ago
      If you have to use ECDSA you have to use it. Bitcoin is an example of where you have to use it. Otherwise, though, it's an inferior and outmoded signature system. It's got the worst random nonce dependency of any modern crypto primitive: if it's even biased, just a little bit, you can recover keys from groups of signatures (a full repeat instantaneously destroys security with a single pair of signatures). It's weak against simultaneous attacks on multiple signatures, so it minimizes the effort attackers need to spend. Meanwhile, it's inefficient compared to the alternatives, so it tends to maximize the effort you have to spend. It's also hard to implement without side channels. Modern cryptography engineers would recommend something like EdDSA instead.
      - wolf550e 10y ago
        Do you believe CFRG took so long to standardize EdDSA because of natural bikeshedding, or because the NSA worked to slow them down?
niftich 10y ago
Crypto APIs being hard to correctly use was the principal motivation behind Daniel Bernstein's nacl [1]. As others have said, nacl and its reimplementation libsodium try to adhere to this philosophy. [1] https://cr.yp.to/talks/2012.08.08/slides.pdf https://cr.yp.to/talks/2012.08.08/slides.pdf
- wolf550e 10y ago
  And it's available for PHP: https://paragonie.com/book/pecl-libsodium https://paragonie.com/book/pecl-libsodium https://github.com/jedisct1/libsodium-php https://github.com/jedisct1/libsodium-php
  - lisper 10y ago
    And Javascript: https://tweetnacl.js.org/ https://tweetnacl.js.org/ And Python: https://github.com/pyca/pynacl https://github.com/pyca/pynacl This is one of my projects using these libraries, a PGP replacement based entirely on the NaCl API: https://github.com/Spark-Innovations/SC4 https://github.com/Spark-Innovations/SC4
- Buge 10y ago
  I used that in a project and found that the Java and the Javascript implementations I was using did things slightly differently, so I had to modify the Java version to behave like the Javascript version. Simpler than Openssl or whatever, but still not ideal.
pvg 10y ago
I had to encrypt something in PHP then decrypt it in ColdFusion. That still ends up being 'rolling your own crypto' and mostly the kind of crypto the article is talking about. The author is describing putting together cryptographic constructs from the sort of low-level pieces provided by your typical runtime crypto library. This is probably the far bigger problem with the admonition - it's vague enough that someone might think that since they're not actually implementing AES themselves, they're not rolling their own crypto. Stackoverflow is full of questions just like your PHP/Coldfusion problem.
pps43 10y ago
> Encrypt(data,key) and Decrypt(data,key) and be done. That's the easy part. You can find a library that does exactly that, and only that. Will probably be just one file, not even a library [1]. But then you'll also need padding, MAC, signatures, key distribution, web of trust, etc. [1] Example: https://github.com/dimview/speck_cipher https://github.com/dimview/speck_cipher
- PeterisP 10y ago
  Well, that's kind of the point - the default Encrypt(data,key) should also implement padding, combine blocks for arbitrary length messages, and include MAC; so that it's reasonably secure out of the box with the default settings. Key distribution is a different issue, but doing the abovementioned things would be sufficient to ensure that you can just run Encrypt/Decrypt(data, key) and expect most of the common tampering attacks to be impossible.
- lvh 10y ago
  The linked repo is not a solution, single-file or otherwise. Speck is not only a weird and unusual block cipher to pick, it is more importantly only a block cipher. It does not let you encrypt more than a block size at a time, and it does not give you authentication! Both of those things are anything but trivial. Furthermore, Speck has a variable block size between 32 and 128 bits. If you pick wrong, safe-looking things like CTR+HMAC-256 become unsafe (it's not hard to overflow a 32-bit counter).
  - pps43 10y ago
    Well, it does Encrypt() and Decrypt(), which is what was asked. And it's not particularly difficult to pick 128 bit block size (after all, bigger is better). The problem is, it's not nearly enough to just do Encrypt() and Decrypt(). Only when you see that, the benefits of a real crypto library NaCL become apparent.
    - lvh 10y ago
      It has things called "encrypt" and "decrypt", but it does not do anything a programmer could reasonably consider "encrypt" and "decrypt". If you don't authenticate your ciphertext, there's a decent chance your ciphertext won't remain secret. It doesn't give you an option for randomized encryption. Compare with Fernet: you get the same API, but you get to encrypt any message, and it's securely authenticated such that it stays secret. (secretbox is fine too; but it makes you pick a nonce). Additionally, "bigger is better" is not a reasonable way to pick primitives. Defaults matter. Perf matters. From experience and stats, people pick according those two vectors a lot more often than they pick along the "bigger is better" axis. When's the last time you saw an RSA-16384 signature? AES-256 might have twice as big a number as AES-128, but how much faith do you have in that extended key expansion? You use AES-128 a lot more often than you use AES-256, and you definitely use RSA-2048 a lot more often than RSA-16384. I don't think you can responsibly insist that this was an answer to the question. It is not a secure way to encrypt messages.
wbond 10y ago
I found the issue to be more insidious. Don’t roll your own crypto. Ok, that makes sense. Don’t implement existing crypto algorithms. Ok, arguments sound good. This leaves the options of using existing libraries. Cool. So let’s go find an existing library to deal with validating an SSL certificate chain in Python. PyCrypto (https://www.dlitz.net/software/pycrypto/api/current/ https://www.dlitz.net/software/pycrypto/api/current/) - hmm, so basically the OpenSSL API, probably a minefield unless you are really up on crypto. M2Crypto (https://gitlab.com/m2crypto/m2crypto https://gitlab.com/m2crypto/m2crypto) - umm, so no real docs. The recommendation is to go read a book about network security with OpenSSL. So after reading a network security book, I should be good to wire together some OpenSSL, right? cryptography (https://cryptography.io/en/latest/ https://cryptography.io/en/latest/) - sweet, we have docs! Hmm, so for humans we have Fernet and the ability to look at X.509 certificates. But nothing about validating. Oh, but there is a stalled PR (https://github.com/pyca/cryptography/pull/2460 https://github.com/pyca/cryptography/pull/2460) from 14 months ago, to verify a certificate signatures. Which then leaves the typical programmer to – hack something together? So it is (practically) 2017, and using one of the most popular programming languages, you can’t verify an SSL certificate in a sane way without becoming journeyman cryptographer. I like crypto, but using cryptography to integrate with existing protocols/standards sucks. Can we really not have an end-user focused implementation of RFC 5280 with a few knobs to turn? Perhaps people would stop "rolling their own" crypto if there were half-decent, maintained, documented solutions out there. Maybe some day!
- paulddraper 10y ago
  And you used Python as the example, probably has the easiest cryptography libraries to use. C/C++, Ruby, JS, etc. are much, much worse in usability.
- wolf550e 10y ago
  Look at this code from urllib3 (requests bundles this code): https://github.com/shazow/urllib3/blob/master/urllib3/contrib/pyopenssl.py https://github.com/shazow/urllib3/blob/master/urllib3/contri... If you install the dependencies, requests uses the package cryptography to use openssl to validate certificates, by running that code. Note that openssl does not validate certificates the way Mozilla Firefox does, even if they use the exact same root CA bundle, because some of the validation logic is code in NSS instead of data (e.g. certificate transparency requirements). Ryan Sleevi wrote on tweeter that Red Hat are working on doing something to let applications using openssl use Firefox's full cert validation logic.
mindcrime 10y ago
Tell me about it. I spent WAY too much time just yesterday, trying to use the Bouncy Castle OpenPGP stuff to encrypt a message such that I could turn around and decrypt it with GnuPG. In the end I got it to work, but what a rigmarole. Crypto API's are, as you said, full of many obscure options and bizarre permutations of how components can be put together, that it's ridiculous. And they also seem to change rapidly, meaning documentation and even Stack Overflow answers are often out-of-date and useless. The thing that saved me finally turned out to be that Bouncy Castle actually do package some example programs in with the source. So once I cloned the git repo and dug into those, I was finally able to find an example of doing exactly what I needed. But trying to piece it together from the javadocs and the other online documentation? Hell no... I'd have been working on that until the heat death of the universe. :-(
- lvh 10y ago
  Out of interest; why do you care about GnuPG decryption specifically? (I write cryptographic software. I care about usability. I might want to provide people with GnuPG-compatible crypto, but that's not necessarily where I'd start.)
  - mindcrime 10y ago
    I'm working on a SaaS offering where I might need to be able to email sensitive information to customers. Or even just make it available for download. In either case, I'd like the data to be encrypted. So I'm planning to ask users to upload a PGP/GPG compatible public key so that we can encrypt this stuff for them. I'm focused on GnuPG specifically just because it's freely available, well known, available on all the important platforms, etc.
    - cpach 10y ago
      Just a word of caution: If your customers are on Windows, using Gpg4win might not be a very smooth experience. I just helped someone to install that package and I found the UX to be really suboptimal. For one, it’s GTK-based, which makes it stick out like a sore thumb in a Windows environment.
balls187 10y ago
> I had to encrypt something in PHP then decrypt it in ColdFusion. Despite being the same algorithm, key, etc, it didn't work. Strangely, the exact same data in the other direction (CF->PHP) worked just fine. Padding issues most likely. PHP might auto detect padding, while CF might not.
j_s 10y ago
I just found out about this 3 year old .NET crypto best practices book / library this past week: http://securitydriven.net/inferno/ http://securitydriven.net/inferno/

ori_b 10y ago

Have you looked at Libnacl or Libsodium?

dom0 10y ago

If it's something sparkling new you probably want to use NaCl or for more involved use cases a Noise implementation.

tptacek 10y ago
It's the opposite, I think: Noise is good for less-involved cases, the kinds of problems you would ordinarily solve by just using TLS. Nacl is better for when you need something customized to an application. Incidentally: Noise is great, but it's also fine to use TLS, if you're just a little careful. See also: https://gist.github.com/tqbf/be58d2d39690c3b366ad https://gist.github.com/tqbf/be58d2d39690c3b366ad
- jjnoakes 10y ago
  The "Avoid /dev/random" recommendation, can you elaborate on that?
  - tptacek 10y ago
    https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...
    - jjnoakes 10y ago
      You should post these reasons in your gist. As I thought, there are a few reasons one might want to use /dev/random. Blanket "don't use X" statements are much more useful with context and information about why not to use X (and when using X may be required, useful, or a better choice).
      - tptacek 10y ago
        No, there aren't. Don't use /dev/random.
        jjnoakes 10y ago
        The reasons I know about for using /dev/random are quoted in the article you yourself just posted here... https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...
        tptacek 10y ago
        Since I wrote that article, I'm pretty confident that it doesn't recommend ever using /dev/random.
        jjnoakes 10y ago
        I said the article mentioned reasons one might want to use /dev/random (or be careful about blindly using /dev/urandom), not that the article recommends using /dev/random. But since you wrote the article you should realize this. Just because the article recommends seeding over using /dev/random early at boot time doesn't mean the original gist shouldn't mention these issues so that readers are aware of them. Just saying "use /dev/urandom all the time" without mentioning the caveats we're discussing here means someone might read your article and in a (misguided) appeal to authority implement something solely on your recommendation without doing their research properly first. I would have thought someone writing security articles would want to avoid misleading someone into implementing something that's accidentally insecure. I hope I'm not wrong.
- an_account_name 10y ago
  A bit of Googling reveals this to be a reply to this blog entry by Colin Percival, for those interested: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...

lordnacho 10y ago

I've run into the same issue. One of the main frustrations is you don't know if the output is correct until you manage to reproduce some known key/document exactly. When you're debugging anything else, you can sort of see what's wrong as you come closer to a correct solution. A crypto scheme is only correct (you've put the right things in the right places) when it's exactly right. Until then, you have a jumble of characters. It took me ages to match ECDSA on java with Python. In the end, it was because of some fine print where I needed to hash one version but not the other before signing.

tptacek 10y ago
What's especially unfortunate about this is that experts would caution you against using ECDSA at all.
- lordnacho 10y ago
  Tell me more? I was doing some bitcoin calculations and needed it.
  - tptacek 10y ago
    If you have to use ECDSA you have to use it. Bitcoin is an example of where you have to use it. Otherwise, though, it's an inferior and outmoded signature system. It's got the worst random nonce dependency of any modern crypto primitive: if it's even biased, just a little bit, you can recover keys from groups of signatures (a full repeat instantaneously destroys security with a single pair of signatures). It's weak against simultaneous attacks on multiple signatures, so it minimizes the effort attackers need to spend. Meanwhile, it's inefficient compared to the alternatives, so it tends to maximize the effort you have to spend. It's also hard to implement without side channels. Modern cryptography engineers would recommend something like EdDSA instead.
    - wolf550e 10y ago
      Do you believe CFRG took so long to standardize EdDSA because of natural bikeshedding, or because the NSA worked to slow them down?

niftich 10y ago

Crypto APIs being hard to correctly use was the principal motivation behind Daniel Bernstein's nacl [1]. As others have said, nacl and its reimplementation libsodium try to adhere to this philosophy. [1] https://cr.yp.to/talks/2012.08.08/slides.pdf https://cr.yp.to/talks/2012.08.08/slides.pdf

wolf550e 10y ago
And it's available for PHP: https://paragonie.com/book/pecl-libsodium https://paragonie.com/book/pecl-libsodium https://github.com/jedisct1/libsodium-php https://github.com/jedisct1/libsodium-php
- lisper 10y ago
  And Javascript: https://tweetnacl.js.org/ https://tweetnacl.js.org/ And Python: https://github.com/pyca/pynacl https://github.com/pyca/pynacl This is one of my projects using these libraries, a PGP replacement based entirely on the NaCl API: https://github.com/Spark-Innovations/SC4 https://github.com/Spark-Innovations/SC4
Buge 10y ago
I used that in a project and found that the Java and the Javascript implementations I was using did things slightly differently, so I had to modify the Java version to behave like the Javascript version. Simpler than Openssl or whatever, but still not ideal.

pvg 10y ago

I had to encrypt something in PHP then decrypt it in ColdFusion. That still ends up being 'rolling your own crypto' and mostly the kind of crypto the article is talking about. The author is describing putting together cryptographic constructs from the sort of low-level pieces provided by your typical runtime crypto library. This is probably the far bigger problem with the admonition - it's vague enough that someone might think that since they're not actually implementing AES themselves, they're not rolling their own crypto. Stackoverflow is full of questions just like your PHP/Coldfusion problem.

pps43 10y ago

> Encrypt(data,key) and Decrypt(data,key) and be done. That's the easy part. You can find a library that does exactly that, and only that. Will probably be just one file, not even a library [1]. But then you'll also need padding, MAC, signatures, key distribution, web of trust, etc. [1] Example: https://github.com/dimview/speck_cipher https://github.com/dimview/speck_cipher

PeterisP 10y ago
Well, that's kind of the point - the default Encrypt(data,key) should also implement padding, combine blocks for arbitrary length messages, and include MAC; so that it's reasonably secure out of the box with the default settings. Key distribution is a different issue, but doing the abovementioned things would be sufficient to ensure that you can just run Encrypt/Decrypt(data, key) and expect most of the common tampering attacks to be impossible.
lvh 10y ago
The linked repo is not a solution, single-file or otherwise. Speck is not only a weird and unusual block cipher to pick, it is more importantly only a block cipher. It does not let you encrypt more than a block size at a time, and it does not give you authentication! Both of those things are anything but trivial. Furthermore, Speck has a variable block size between 32 and 128 bits. If you pick wrong, safe-looking things like CTR+HMAC-256 become unsafe (it's not hard to overflow a 32-bit counter).
- pps43 10y ago
  Well, it does Encrypt() and Decrypt(), which is what was asked. And it's not particularly difficult to pick 128 bit block size (after all, bigger is better). The problem is, it's not nearly enough to just do Encrypt() and Decrypt(). Only when you see that, the benefits of a real crypto library NaCL become apparent.
  - lvh 10y ago
    It has things called "encrypt" and "decrypt", but it does not do anything a programmer could reasonably consider "encrypt" and "decrypt". If you don't authenticate your ciphertext, there's a decent chance your ciphertext won't remain secret. It doesn't give you an option for randomized encryption. Compare with Fernet: you get the same API, but you get to encrypt any message, and it's securely authenticated such that it stays secret. (secretbox is fine too; but it makes you pick a nonce). Additionally, "bigger is better" is not a reasonable way to pick primitives. Defaults matter. Perf matters. From experience and stats, people pick according those two vectors a lot more often than they pick along the "bigger is better" axis. When's the last time you saw an RSA-16384 signature? AES-256 might have twice as big a number as AES-128, but how much faith do you have in that extended key expansion? You use AES-128 a lot more often than you use AES-256, and you definitely use RSA-2048 a lot more often than RSA-16384. I don't think you can responsibly insist that this was an answer to the question. It is not a secure way to encrypt messages.

wbond 10y ago

I found the issue to be more insidious. Don’t roll your own crypto. Ok, that makes sense. Don’t implement existing crypto algorithms. Ok, arguments sound good. This leaves the options of using existing libraries. Cool. So let’s go find an existing library to deal with validating an SSL certificate chain in Python. PyCrypto (https://www.dlitz.net/software/pycrypto/api/current/ https://www.dlitz.net/software/pycrypto/api/current/) - hmm, so basically the OpenSSL API, probably a minefield unless you are really up on crypto. M2Crypto (https://gitlab.com/m2crypto/m2crypto https://gitlab.com/m2crypto/m2crypto) - umm, so no real docs. The recommendation is to go read a book about network security with OpenSSL. So after reading a network security book, I should be good to wire together some OpenSSL, right? cryptography (https://cryptography.io/en/latest/ https://cryptography.io/en/latest/) - sweet, we have docs! Hmm, so for humans we have Fernet and the ability to look at X.509 certificates. But nothing about validating. Oh, but there is a stalled PR (https://github.com/pyca/cryptography/pull/2460 https://github.com/pyca/cryptography/pull/2460) from 14 months ago, to verify a certificate signatures. Which then leaves the typical programmer to – hack something together? So it is (practically) 2017, and using one of the most popular programming languages, you can’t verify an SSL certificate in a sane way without becoming journeyman cryptographer. I like crypto, but using cryptography to integrate with existing protocols/standards sucks. Can we really not have an end-user focused implementation of RFC 5280 with a few knobs to turn? Perhaps people would stop "rolling their own" crypto if there were half-decent, maintained, documented solutions out there. Maybe some day!

paulddraper 10y ago
And you used Python as the example, probably has the easiest cryptography libraries to use. C/C++, Ruby, JS, etc. are much, much worse in usability.
wolf550e 10y ago
Look at this code from urllib3 (requests bundles this code): https://github.com/shazow/urllib3/blob/master/urllib3/contrib/pyopenssl.py https://github.com/shazow/urllib3/blob/master/urllib3/contri... If you install the dependencies, requests uses the package cryptography to use openssl to validate certificates, by running that code. Note that openssl does not validate certificates the way Mozilla Firefox does, even if they use the exact same root CA bundle, because some of the validation logic is code in NSS instead of data (e.g. certificate transparency requirements). Ryan Sleevi wrote on tweeter that Red Hat are working on doing something to let applications using openssl use Firefox's full cert validation logic.

mindcrime 10y ago

Tell me about it. I spent WAY too much time just yesterday, trying to use the Bouncy Castle OpenPGP stuff to encrypt a message such that I could turn around and decrypt it with GnuPG. In the end I got it to work, but what a rigmarole. Crypto API's are, as you said, full of many obscure options and bizarre permutations of how components can be put together, that it's ridiculous. And they also seem to change rapidly, meaning documentation and even Stack Overflow answers are often out-of-date and useless. The thing that saved me finally turned out to be that Bouncy Castle actually do package some example programs in with the source. So once I cloned the git repo and dug into those, I was finally able to find an example of doing exactly what I needed. But trying to piece it together from the javadocs and the other online documentation? Hell no... I'd have been working on that until the heat death of the universe. :-(

lvh 10y ago
Out of interest; why do you care about GnuPG decryption specifically? (I write cryptographic software. I care about usability. I might want to provide people with GnuPG-compatible crypto, but that's not necessarily where I'd start.)
- mindcrime 10y ago
  I'm working on a SaaS offering where I might need to be able to email sensitive information to customers. Or even just make it available for download. In either case, I'd like the data to be encrypted. So I'm planning to ask users to upload a PGP/GPG compatible public key so that we can encrypt this stuff for them. I'm focused on GnuPG specifically just because it's freely available, well known, available on all the important platforms, etc.
  - cpach 10y ago
    Just a word of caution: If your customers are on Windows, using Gpg4win might not be a very smooth experience. I just helped someone to install that package and I found the UX to be really suboptimal. For one, it’s GTK-based, which makes it stick out like a sore thumb in a Windows environment.

balls187 10y ago

> I had to encrypt something in PHP then decrypt it in ColdFusion. Despite being the same algorithm, key, etc, it didn't work. Strangely, the exact same data in the other direction (CF->PHP) worked just fine. Padding issues most likely. PHP might auto detect padding, while CF might not.

j_s 10y ago

I just found out about this 3 year old .NET crypto best practices book / library this past week: http://securitydriven.net/inferno/ http://securitydriven.net/inferno/