It works (but is sloooooow)
Source: BashonWindows (Ubuntu from Win10) not finding openssl · Issue #337 · drwetter/testssl.sh
Posted by jpluimers on 2016/08/08
It works (but is sloooooow)
Source: BashonWindows (Ubuntu from Win10) not finding openssl · Issue #337 · drwetter/testssl.sh
Posted in Encryption, Hashing, https, OpenSSL, Power User, Security, testssl.sh | Leave a Comment »
Posted by jpluimers on 2016/07/20
Great explanation of Diffie-Hellman Key Exchange – YouTube.
It is based on mixing colors and some colors of the mix being private.
Brilliant!
–jeroen
Posted in Algorithms, Development, Encryption, Hashing, https, OpenSSL, Power User, Public Key Cryptography, Security, Software Development | Leave a Comment »
Posted by jpluimers on 2016/07/11
Still relevant after a few years: DEFCON 17: More Tricks For Defeating SSL – YouTube.
I landed there after trying to find out how to verify the Internic root server file is actually pubished by Internic via authentication – Ways to sign gpg public key so it is trusted? – Information Security Stack Exchange.
I remember reading his “if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom” post (Moxie Marlinspike >> Blog >> The Cryptographic Doom Principle), but never noticed his videos.
It is still relevant as there are lots of implementations still vulnerable to these kinds of attacks.
Many more of his blog entries are interesting as well:
Posted in Encryption, Hashing, https, OpenSSL, PKI, Power User, Public Key Cryptography, Security, Signing | Leave a Comment »
Posted by jpluimers on 2016/06/10
For my own reference:
Always get at least two keys, configure them, and use only one. Store the rest in a safe place for when the first dies.
Get the NEO (if you need NFC) or NEO-n (if you don’t need NFC but love small form-factor).
–jeroen
(Image courtesy of Yubico)
Posted in Encryption, Hashing, Power User, Security, U2F FIDO Security Keys | Leave a Comment »
Posted by jpluimers on 2016/04/27
400+ Free Resources for DevOps & Sysadmins ranging from bitbucket/gitbub via letsencrypt through loggly to cloudflare and all soorts of *aaS online IDEs, payment services and more.
via: Mary Tee referred to by Joe Hecht.
–jeroen
Posted in Development, Encryption, Let's Encrypt (letsencrypt/certbot), Power User, Security, Software Development | Leave a Comment »
Posted by jpluimers on 2015/11/27
It feels like yesterday, but haxpo2015ams was already six months ago!
Session materials index:
–jeroen
Posted in *nix, *nix-tools, Encryption, Hashing, https, LifeHacker, OpenSSL, PKI, Power User, Public Key Cryptography, Security, Signing | Leave a Comment »
Posted by jpluimers on 2015/11/19
Interesting: a few quotes below, read How is NSA breaking so much crypto? and the full paper Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice for details.
The key is, somewhat ironically, Diffie-Hellman key exchange, an algorithm that we and many others have advocated as a defense against mass surveillance. Diffie-Hellman is a cornerstone of modern cryptography used for VPNs, HTTPS websites, email, and many other protocols. Our paper shows that, through a confluence of number theory and bad implementation choices, many real-world users of Diffie-Hellman are likely vulnerable to state-level attackers.
.. there was a very important detail that got lost in translation between the mathematicians and the practitioners: an adversary can perform a single enormous computation to “crack” a particular prime, then easily break any individual connection that uses that prime.
How enormous a computation, you ask? … For the most common strength of Diffie-Hellman (1024 bits), it would cost a few hundred million dollars to build a machine, based on special purpose hardware, that would be able to crack one Diffie-Hellman prime every year.
Would this be worth it for an intelligence agency? Since a handful of primes are so widely reused, the payoff, in terms of connections they could decrypt, would be enormous. Breaking a single, common 1024-bit prime would allow NSA to passively decrypt connections to two-thirds of VPNs and a quarter of all SSH servers globally. Breaking a second 1024-bit prime would allow passive eavesdropping on connections to nearly 20% of the top million HTTPS websites. In other words, a one-time investment in massive computation would make it possible to eavesdrop on trillions of encrypted connections.
NSA could afford such an investment. The 2013 “black budget” request … shows that the agency’s budget is on the order of $10 billion a year, with over $1 billion dedicated to computer network exploitation, and several subprograms in the hundreds of millions a year.
… However, our proposed Diffie-Hellman break fits the known technical details about their large-scale decryption capabilities better than any competing explanation. For instance, the Snowden documents show that NSA’s VPN decryption infrastructure involves intercepting encrypted connections and passing certain data to supercomputers, which return the key. The design of the system goes to great lengths to collect particular data that would be necessary for an attack on Diffie-Hellman but not for alternative explanations, like a break in AES or other symmetric crypto.
Since weak use of Diffie-Hellman is widespread in standards and implementations, it will be many years before the problems go away, even given existing security recommendations and our new findings. In the meantime, other large governments potentially can implement similar attacks, if they haven’t already.
Our findings illuminate the tension between NSA’s two missions, gathering intelligence and defending U.S. computer security. If our hypothesis is correct, the agency has been vigorously exploiting weak Diffie-Hellman, while taking only small steps to help fix the problem. On the defensive side, NSA has recommended that implementors should transition to elliptic curve cryptography, which isn’t known to suffer from this loophole, but such recommendations tend to go unheeded absent explicit justifications or demonstrations. This problem is compounded because the security community is hesitant to take NSA recommendations at face value, following apparent efforts to backdoor cryptographic standards.
–jeroen
via:
Posted in Algorithms, Development, Encryption, Power User, Security, Software Development | Leave a Comment »
Posted by jpluimers on 2015/02/16
Wow, finally a TrueCrypt successor. And it is open source too!
VeraCrypt is the successor of the venerable TrueCrypt file encryption software, which was abandoned by its developers a while ago. VeryCrypt is compatible with TrueCrypt containers, and is open-source. (TrueCrypt was not). The resulting product fixes all known vulnerabilities that TrueCrypt had, and strengthened the security.
Read more about changes from TrueCrypt at https://veracrypt.codeplex.com/discussions/569777#PostContent_1313325
Veracrypt is now at these locations:
https://sourceforge.net/projects/veracrypt/
https://github.com/veracrypt/VeraCrypt
–jeroen
Posted in Encryption, Power User, Security | Leave a Comment »
Posted by jpluimers on 2014/02/27
Interesting: Chrome Web Store – Mymail-Crypt for Gmail™.
–jeroen
Posted in Chrome, Encryption, GMail, Google, Power User | Leave a Comment »