Re: [cryptography] Zooko's semiprivate keys
Here's an implementation of semiprivate keys in SAGE (courtesy DCoder) that actually works: https://gist.github.com/tarcieri/40d2eb8e4e8f9ed28b3a I'm a bit lost as to where I'm going wrong in my NaCl-based implementation -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Which CA sells the most malware-signing certs?
On 19/02/13 02:33 AM, Jon Callas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 18, 2013, at 7:07 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: I've just done a quick tally of the certs posted to http://www.ccssforum.org/malware-certificates.php, a.k.a. Digital Certificates Used by Malware. Looks like Verisign (and its sub-brand Thawte) are the malware-authors' CA of choice, selling more certs used to sign malware than all other CAs combined. GeoTrust comes second, and everything below that is in the noise. GoDaddy, the most popular CA, barely rates. Other CAs who've sold their certs to malware authors include ACNLB, Alpha SSL (which isn't supposed to sell code-signing certificates at all as far as I can tell), Certum, CyberTrust, DigiCert, GeoTrust, GlobalSign, GoDaddy, Thawte, StarField, TrustCenter, VeriSign, and WoSign. Everyone's favourite whipping- boy CAs CNNIC and TurkTrust don't feature at all. Caveats: These are malware certs submitted by volunteers, so they're not a comprehensive sample. The site tracks malware-signing certs and not criminal- website certs, for which the stats could be quite different. Interesting, but I have a raised eyebrow. As Andy Steingruebl pointed out, there are a lot of malware certs that are stolen, so this data needs to be normalized against market share. Similarly relevant would be the CAs with significantly fewer certs there than market share would indicate. My former employer, Entrust, has zero certs in that database. What does that mean? Anything? Why pick on the CAs at all? Frankly, the real problem with signed malware is that the *platforms* have the policy that equates a signature with reputation. That's the thing that to me is mind-bogglingly daft. It's the equivalent of the TSA wanting a government issued ID, because as we all know, terrorists can't get ID. You, I, others can easily imagine solutions. We can even model them and predict success. But the browsers won't shift. Why is this? One word might capture it: CHANGE. The vendors are incapable of changing their security model, and the CAs are terrified of changing their revenue model. For quite different reasons, but it does seem that they are united in their desire to avoid CHANGE. Indeed, if you look at CABForum, two striking things come out. Firstly, nothing changed. Comparing their output in documents to the practices developed by VeriSign in the mid 1990s, the best thing you can say is that CABForum documents have better documented that 1990 security model. Secondly, and for this you need a bit of institutional business knowledge [0], the structure of CABForum is (or was [1]) designed perfectly to avoid CHANGE. Time-wise, code-wise, architecturally speaking, product-mix, structurally, everything about the sector is built to avoid CHANGE. When we look at the 1990s, the issue OP raises is quite simple. That wasn't envisaged in the 1990s. If you separate signatures from reputation, then anti-malware scanners can detect malware by a database of known malware signatures, and then infer upwards from a piece of malware to a key owned by or suborned by a malware author. They could conveniently kill malware by code signature or signing cert, as appropriate. They could even go beyond malware to disable things like known buggy or exploitable versions of software. I don't see why they aren't doing that now. They don't even need the platform makers to play along. An alliance of the platforms and the anti-malware people would make it unnecessary to even have a CA-issued code signing cert. That's the sort of CHANGE that causes all concerned to run away in fear, huddle, and ensure that such suggestions never ever see the light of day. Question then is, what to do about it? Peter has immense fun poking at the holes. Some get good mileage out of studying and reverse-engineering the business. I spent years trying to encourage one vendor to change, something, anything. Others with integrity participate in these 'forums' and get a frustration at the players, which grows into loathing. Because the sector is unified in its rejection of CHANGE, the only real systemic solution is bypass. Here is what I would do. If I was a CA, I'd sell out. The business is a bit of a cash cow. It is OK for now, but its future is a bit dim. If I was an outsider, I would simply not recommend the security model in any seriousness. As a security consultant, I would rate CA-provided certificates as mostly harmless and encourage my client to explore other solutions. Security consultants cannot recommend against a 'best practices' model without risking being labelled as a kook, but on the other hand, integrity of the business is such that one cannot recommend a solution knowing it to be facadal or dangerous, especially as there is a non-trivial and rising risk that someone is going to be sued by a bank over this, once a bad
Re: [cryptography] Bitmessage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jonathan, This looks like it could be a useful system, but I'm not sure I fully understand it. Each node is assumed to have a slowly changing set of addresses, is that right? A node migrates between streams by choosing whether to create new addresses in its current stream or a child of its current stream; when it has no more addresses in the current stream, the child stream becomes its current stream. So if addresses identify users, does that mean each node is assumed to have a slowly changing set of users (like a mail server, say, rather than a personal computer)? Or does each user change addresses over time? When a node first enters the network, how does it decide which stream to join? When a node leaves the network, a stream may be left empty. What happens if stream 1 (or any other non-leaf stream) becomes empty? Can a node in a leaf stream that wants to send a message to a node in another leaf stream still find a suitable node to connect to? Section 5 of the paper says that all users receive all messages. But that's no longer true once the network has divided into streams, right? So how does a broadcaster ensure that all subscribers receive her messages? It might be worth looking at P5, which uses some similar ideas: http://www.cs.umd.edu/projects/p5/p5-extended.pdf Also, some analysis of proof of work as a means of limiting spam: http://www.cl.cam.ac.uk/~rnc1/proofwork2.pdf I seem to remember a DHT-based system where messages could be addressed to all nodes with a given identifier prefix (of any length), but I can't find the reference. Cheers, Michael On 16/02/13 18:49, Jonathan Warren wrote: Hello everyone, I would like to introduce you to a communications protocol I have been working on called Bitmessage. I have also written an open source client released under the MIT/X11 license. It borrows ideas from Bitcoin and Hashcash and aims to form a secure and decentralized communications protocol which also doesn't rely on trust. Criticism of the X.509 certificate system is understandably common in this listserv (and also increasingly common in more public forums); Bitmessage instead uses Bitcoin-like addresses for authentication. It has a 'broadcast' and 'subscription' feature which other people have described as a decentralized Twitter and also aims to hide non-content data, like the sender and receiver of messages, from passive eavesdroppers like those running warrantless wiretapping programs. It may also be possible to be strong against active attackers although I'm not yet making that claim. A primary goal has been to make a clean and simple interface so that the key management, authentication, and encryption is simple even for people who do not understand public-key cryptography. I'm sure that there is quite a bit of demand for such a program and protocol although I am currently not actively promoting it because it has not been independently audited. I would be interested to hear your comments. The website https://bitmessage.org links to various resources like a short whitepaper describing how the protocol works and what its goals are ( https://bitmessage.org/bitmessage.pdf ) and the source code on Github ( https://github.com/Bitmessage/PyBitmessage ). The main source code file is bitmessagemain.py. Bitmessage is written in Python and uses an OpenSSL wrapper called pyelliptic (written by a different individual) to implement ECIES and ECDSA. Again I look forward to hearing comments; it is always easier to change or add to a protocol earlier than it is later. All the best, Jonathan Warren ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJRI3OzAAoJEBEET9GfxSfMzOkH/29tjxyzO2g949Pk8yM2V+lZ Sqd2BeamgzYoz3QCS5iwDjhgJedguNS0/CzTwzDW56mEzYKkqZPdfZlKR2s541hA Y10++AOy9yyumAZypAGD/0HDDRftMs4iUoZZbOlm6jB4Ul8Al5iHeNL2r1VIPaU/ pmP1cbUi8yLC86POmjMARfvbiAX4+G3EYxb+lKaZleFMg8cCoo07Ur6Po7mdTtkz nMkuNsmBgzUoaGHejB2tAe6B5QQNsqazFEK1UK/wg9829CedF6l1UKMFy5iDNIJa 60zQ9U0+SDnd0RedeR45pYIPKmPI4pGEp4COyv/n2derzRY52P1TrHx/T7jkx9k= =4oMp -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitmessage
IMO you might want to do something about forward secrecy (aka backward security) and forward anonymity, or you arguably end up with the same issue as reply blocks: a subpoena plus suspicion can force decryption (you won’t have the decrypt the reply-block via repeated subpoenas down the chain, but the participants are known or suspected, just coerce them to decrypt!) It is tricky to get forward secrecy for store-and-forward messaging [2], but perhaps you could incorporate rekeying into your protocol in some convenient way. It is tricky indeed. The handshaking necessary to set up the session key could piggyback on the first couple messages that users send to one another although those first several messages would not be forward-secret. I suppose that the session key could then be replaced with each message sent: The sender of a message would keep track of two session keys- one that the other party used previously (so that you can receive consecutive replies) and a new one that you are encouraging them to use on the next message. I think it would work. I’ve written out a message sequence chart and it appears that only the first message from Alice to Bob would be non-forward-secret. If a party is compelled to give up the keys, that very first message and also the last couple messages in a conversation would be exposed. It will be very difficult to explain this property to most people. If ever I have a mode for Instant Messaging (the thought is to give up anonymity for some addresses in exchange for the ability to send large files and not do any proof of work) then I will be sure to implement forward secrecy. And maybe a way to steganographically tunnel connections to participate This is very difficult. I will leave this to Tor; Bitmessage can use Tor with only a few clicks. Couldn't the protocol be sped up by implementing something similar to the way DNS work's i.e. but having trusted servers acting as re-distribution points. Yes, that would work. If more people want that feature it could be added. The address and corresponding QR code would be the same size- it would just be a hash of 2 signing and 2 encryption keys rather than just one of each. But Bitmessage (just like Bitcoin) would enjoy greater user enthusiasm if an individual can run a full node on their own without relying on a server. 2) What happens if someone/thing takes the whole of stream 1 off line permanently? can 2 and 3 re-join or have you got a net-split type event? I’m not sure how you would take stream 1 offline. I think of Bitcoin nodes as being all in their own stream 1. In Bitmessage, Stream 1 exists because nodes consider themselves to be part of stream 1 (and likely other streams as well). If you were to eliminate all of those nodes then stream 1 would become empty and remaining clients would start creating new addresses in stream 1 thus those nodes would become members of stream 1. The streaming concept doesn’t affect the possibility of net-splits. Net-splits in Bitmessage and Bitcoin have the same potential causes (i.e. A government disconnecting the country from the Internet) although are less serious in Bitmessage because there is no blockchain. If the police break down my door grab my private key, they have a copy of every message I've ever sent Yes. Forward secrecy as discussed above is something I would like. This gives me more reason to want to create an IM interface. BTW as I assume you're using it currently, how network heavy is it? I wonder if it's something that could be ported (as in running in parallel) to I2P? Someone went around advertising it on Reddit and there are currently tens of people running it which is still low. For I2P, it appears that the protocol would need to be modified to support the multi-hundred byte destinations, but I see no reason why it wouldn’t work. Once it is on I2P, it would be quite easy to make junction points between clients on the normal Internet and I2P. “A primary goal has been to make a clean and simple interface so that the key management, authentication, and encryption is simple even for people who do not understand public-key cryptography.” This is of course, the hard problem. I feel that those things are easy but anonymity is hard.. as long as people can accept using a human-unfriendly address. By the way, if anyone is aware of any distributed-network projects besides Namecoin which can securely link human-friendly names with human-unfriendly data, I would be interested to hear it. Namecoin gives me hope that something (or an improved Namecoin) will exist some day. So no one has anyone to talk to, nor anything to talk about, and if they did, they would have trouble recollecting who they were talking to, since all truenames look like gibberish, thus all truenames look alike. ... Seems to me that you need something like public web pages, and something like a favorites list / bookmarks list, where when you add
Re: [cryptography] Bitmessage
On 2013-02-20 6:21 AM, Jonathan Warren wrote: It is tricky indeed. The handshaking necessary to set up the session key could piggyback on the first couple messages that users send to one another although those first several messages would not be forward-secret. I suppose that the session key could then be replaced with each message sent: The sender of a message would keep track of two session keys- one that the other party used previously (so that you can receive consecutive replies) and a new one that you are encouraging them to use on the next message. I think it would work. If store and forward, cannot be forward secrecy. Suppose that human readable messages, messages that might contain important secrets, are only exchanged when the sender and the final recipient are both online at the same time, then forward secrecy no problem. Both parties set up a shared transient secret session key, as usual, which goes away when offline, reboot, or timeout. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitmessage
If store and forward, cannot be forward secrecy. Suppose that human readable messages, messages that might contain important secrets, are only exchanged when the sender and the final recipient are both online at the same time, then forward secrecy no problem. Both parties set up a shared transient secret session key, as usual, which goes away when offline, reboot, or timeout. Suppose when Alice firsts sends a message to Bob she also includes a short term public key. Bob takes the short term public key and encrypts symmetric_key_1 (SK1) and also encrypts a message with SK1 and sends the encrypted SK1 and the encrypted message to Alice. Alice decrypts the encrypted SK1 with her short term private key and then uses SK1 to decrypt the message. The short term public key pair can now be deleted. When Alice replies, she sends the message and a new SK2, encrypted with SK1, to Bob. Bob will decrypt with SK1 and store SK2. When he sends a message, he encrypts his message along with a new key, SK3, with SK2. This continues with a new symmetric key each time. Both parties must remember the last SK that they suggested to the other party, and also the last SK that they received from the other party. All others can be deleted. One might call the symmetric keys 'one time use' keys except that they can be used several times if one person replies to the other several times in a row. Thus the first initial message from Alice to Bob is not forward-secret, and the last several messages between them are not forward-secret, but all other messages are. Am I mistaken? Although I think I'd rather work on piggy-backing on an existing anonymity network to do forward secret instant messaging before all of that above. -Jonathan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
