You should take a look at the [encryption] tag on stack overflow. There is a lot of really depressing stuff there.
Implementing low level cryptographic algorithms is hard - I'd say near impossible to get right - if you apply high standards like side-channel resistance. There are a lot of use cases though, where side-channel resistance is not necessary to get secure "enough" against the slightly above average attacker. But the next level to get wrong is using the low-level crypto correctly. E.g. by assuming encrypting data is enough to protect the content, until you find out about CBC padding oracles and how your service involuntarily decrypts the sensitive date for the attacker (ASP.net: [1]). Or you realize, that your ad-hoc message authentication code does not protect your API at all, because MD5, SHA1 and the SHA2 family are all subject to length extension attacks (Flickr: [2]).
The subtleties are endless: In RSA, you can calculate the `e`th root over the real numbers, if `e` and the message is small, RSA has it's own padding problems [3], Stream ciphers provide no authenticity whatsoever as you can just xor the ciphertext with any value to manipulate the plaintext, password hashing is not at all about what most people believe it to be, comparing passwords should be done using a PAKE [4] (otherwise you can bruteforce passwords, like in WPA)... And then there is stuff that even the experts get wrong, think TLS Triple Handshake [5].
You can learn about this kind of stuff by reading the right books (I like to recommend "Cryptography Engineering" [6]) and keeping an eye open for vulnerabilities and how they work, so it is not obscure or hidden knowledge. But building cryptographic systems involves a lot more work and expert knowledge than the average programmer in the upper quartile imagines. And, crucially, you won't know when you get it wrong.
Sure, crypto is hard, but I don't think for the last 20 years or so we have been living in a world where the five countries (and one specially-administered territory) mentioned in the article as having received the software (China, Hong Kong, Russia, Israel, South Africa, and South Korea) would have significantly more trouble than a private company in the U.S. producing secure cryptographic software based on known algorithms and protocols. The only consequence of export restrictions on crypto beyond the things that live in the classified/military world, is reducing the competitiveness of American software firms and decreasing economic output by having every piece of security software developed twice, once in the U.S. and once in say Switzerland or India or whichever country doesn't have insane export restrictions on crypto.
Implementing low level cryptographic algorithms is hard - I'd say near impossible to get right - if you apply high standards like side-channel resistance. There are a lot of use cases though, where side-channel resistance is not necessary to get secure "enough" against the slightly above average attacker. But the next level to get wrong is using the low-level crypto correctly. E.g. by assuming encrypting data is enough to protect the content, until you find out about CBC padding oracles and how your service involuntarily decrypts the sensitive date for the attacker (ASP.net: [1]). Or you realize, that your ad-hoc message authentication code does not protect your API at all, because MD5, SHA1 and the SHA2 family are all subject to length extension attacks (Flickr: [2]).
The subtleties are endless: In RSA, you can calculate the `e`th root over the real numbers, if `e` and the message is small, RSA has it's own padding problems [3], Stream ciphers provide no authenticity whatsoever as you can just xor the ciphertext with any value to manipulate the plaintext, password hashing is not at all about what most people believe it to be, comparing passwords should be done using a PAKE [4] (otherwise you can bruteforce passwords, like in WPA)... And then there is stuff that even the experts get wrong, think TLS Triple Handshake [5].
You can learn about this kind of stuff by reading the right books (I like to recommend "Cryptography Engineering" [6]) and keeping an eye open for vulnerabilities and how they work, so it is not obscure or hidden knowledge. But building cryptographic systems involves a lot more work and expert knowledge than the average programmer in the upper quartile imagines. And, crucially, you won't know when you get it wrong.
[1] http://weblogs.asp.net/scottgu/important-asp-net-security-vu...
[2] http://vnhacker.blogspot.de/2009/09/flickrs-api-signature-fo...
[3] http://archiv.infsec.ethz.ch/education/fs08/secsem/Bleichenb...
[4] https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
[5] http://blog.cryptographyengineering.com/2014/04/attack-of-we...
[6] https://www.schneier.com/book-ce.html