> You have probably never used a crypto tool that used either Dual_EC or extended-random, for what it's worth.
Dual_EC was default PRNG in BSAFE-SSL-C for almost a decade. Shodan matched 1700 banners from this time, online now. The chance that a person interacted with a https service in that time is quite high I would think.
Thank for following this up.
I think you are right. RH SWS was EOL before the Dual_EC default switch was made. If the only public banners for this product are from before this time, I will conceed that DUAL_EC likely never saw use on the Public Internet.
This seems somewhat related to some work I did last year on using blockchain to 'register' and provide distributed revocation of certs.
I called it UTXOC or Unspent Transaction Output based Certificates
https://github.com/MiWCryptoCurrency/UTXOC/
Specifically, I called 'self-signed' certs 'Cryptocurrency Bonds' and could be revoked by spending the funds associated with a public key (bitcoin-like address), and others could verify this by inspection of the blockchain.
The difference here is that I was using the cert privkey as as the bitcoin privkey; Problem being that modern browsers don't and likely never will support the secp256k1 curve for EC keys in TLS.
I did built a custom NSS+Firefox that did, and it worked, so it is possible.
In fact, NSS used to support the full range of EC curves until 2005.
https://raw.githubusercontent.com/MiWCryptoCurrency/Certific...
Would be great to discuss your thoughts on using blockchain for x509 and trusts.
Use slower / heavier hash -- PBKDF2 or better. For lulz use something like Darkcoin Cryptocurrency 'X11' Proof of Work function - multiple rounds of 11 different hashes.
Or more. (X13, X15 and X17 all exist as PoW functions in CryptoCurrencies today).
A <$1000 bitcoin (SHA-256) mining ASIC appliance is likely to be doing 1TH/s. Makes 2^16 rounds look kinda weak.
This is a really well written article; full of great, reusable tricks and techniques in reverse engineering.
Clear screenshots, humorous yet technical content, neat results.
Hats off to you, sir, keep up the good work and I look forward to reading more of your tutorials.
I respect and admire agl, his and very important work on EC; but i must respectively disagree with his analysis of bitcoin and other blockchain based technologies.
This paper was written in 2011, and a lot has changed since then. Today, we have an infrastructure similar to what Certificate Transparency is said to produce -- without collusion or support from the CAs. Bitcoin and other blockchain based technologies have an economic incentive to continue to propagate. I fail to see why anyone other than the CA's would have an incentive for the Certificate Transparency blockchain to propagate.
I proposed an alternative model which i called 'UTXOC'. I wrote a paper and published some python scripts to generate certificates based on a prior bitcoin transaction.
A certificate validity can be determined by some bitcoin-like value left unspent. If the value is spent, the cert if invalid.
If the private key is compromised, the attacker has an economic advantage in 'cashing out' the value; thus invalidating the certificate.
I propose that also adds to the cost of key substitution attacks on TLS; an active MiTM would need to spend at least as much cryptocurrency in order to successfully fake a certificate, even with a trusted root in the client.
It could go either way -- with CA support for such things, or a self-signed 'cryptocurrency bond' style model where TLS operators hold cryptocurrency in order to maintain the validity of their certs.
Very interested to hear opinions on this, its a work in progress. Yes, support for secp256k1 is limited in mainstream OS's -- it only works with openssl s_client and s_server currently.
Given time I hope that the secp256k1 curve is added to browsers and operating systems, and this or similar blockchain based record architectures are adopted.
Minor correction: this article was written by Ben Laurie, not agl. (Same company though.) But you also mentioned 2011 so I'm not exactly sure what you are referring to.
Your proposal is interesting, but it won't really 'scale'. An attacker can get a _lot_ of value out of a banking certificate, and could possibly continue to "milk the cow" until found, probably collecting more credentials then the associated BTC is worth.
Plus, how are you going to be handling validation? Can I just pay (presumably) a lot less then I would need to crack RSA-2048 (or RSA-1024, given the still-trusted roots) and go on an MITM frenzy?
Ideally the certificate would be worth, or have a value associated greater than that of the transactions being handled by the site it is protecting; Then the attacker has more to gain by invalidating the certificate than intercepting traffic. Otherwise you have the same situation that we have now with current certificates without a decentralised store of value associated.
Also, every day CA's could sign these certificate requests, and so you have the equivalent to trusted root today.
One thing that is advantagous here is that even trusted CA's cannot reproduce a 'trusted' certificate without spending the same amount of cryptocurrency. This would defend against firewall/IPS MiTM that is occuring today.
I brought this whole topic up because of the likeness with blockchains and certificate transparency. My argument is that why would CA's have an incentive to maintain the certificate transparency chain, when you already have many people with an incentive to maintain the bitcoin blockchain.
Validation, or checking for validity of the certificate can be done either through a 3rd party lookup service like blockchain.info or inspection of the blockchain with the wallet software.
I think that adoption of certificates like this would require modification to TLS protocols, or at least some application support to require certain types of certificates - just like EV or Certificate Pinning.
Not all sites deal with transactions (ex: my personal site). This would pretty much reverse any adoption rates TLS has. (who wants to pay >$200 for a certificate?)
For example, Wells Fargo has like 840 billion in loans. They obviously don't want to pay $800 billion for an SSL certificate, and they'd lose that $800 billion if one file is compromised...
Right now, you can essentially pay to be a certificate authority. This just allows you to pay per site you want to attack.
This is a new 100% premined cryptocurrency from the makers of ripple. Stripe has invested in this technology; so it already has some fiat backing behind the haul.
Whomever this is, and they are likely associated with the project as have an associated email, is gathering funds from the projects premined wallets for distribution.
Like ripple, they are handing these out to people interested in the technology. I received part of the initial distribution of ripple by posting on the bitcoin forums. I encourage you to make an account, nothing to lose here; the initial distribution of the currency helps with its decentralization.
Paypal used to pay people to make new accounts too!
The person here is not affiliated with the project. (That @stellar.org is their federated payment address, which is assigned to anyone who signs up for an account.)
We've talked with the user, and it sounds like this is not in fact a code bug. We've invited him to post more details in this thread, so hopefully you'll hear more soon.
I had to use this mirror recently as there are already bad copies floating about; it is a trusted hosting for the last ungimped version for windows and linux. check the hashes n' sigs!
* screenshot of the back office application
* OSX and Windows back office application binaries
* btc_xfer_total_summary.txt
* CV-Mark_Karpeles_20100325.pdf
* home_addresses.txt
* trades_summary.txt
* btc_xfer_report.csv containing every deposit and withdraw
* mtgox_balances containing the balances of all user wallets
* trades.zip containing monthly csv files of all trades within mtgox & coinlab between 2011-04 to 2013-11
* trades csvs have fields:
Trade_Id Date User_Id User User_Id_Hash
Japan Type Currency Bitcoins Money
Money_Rate Money_JPY
Money_Fee Money_Fee_Rate Money_Fee_JPY
Bitcoin_Fee Bitcoin_Fee_JPY User_Country User_State
From this data you could reconstruct every trade within the site, and identify the address from transaction values.
This dataset could lead to loss of anonymity to a significant number of people in the cryptocurrency world.
If what you say is true and this data is sufficient to recreate and de-anonymize the trades on gox against withdrawals from their addresses shouldn't we be able to see if coins were actually stolen through tx malleability?
Dual_EC was default PRNG in BSAFE-SSL-C for almost a decade. Shodan matched 1700 banners from this time, online now. The chance that a person interacted with a https service in that time is quite high I would think.