Re: [cryptography] Introducing SC4 -- feedback appreciated
ohio, On Fri, Apr 17, 2015 at 10:56:01AM -0700, Ron Garret wrote: 1. It is a standalone web application. putting keys in the browser is like putting keys in front of a dmz. browsers are not designed for this, they are designed for delivering impressions and services to you. the security features you find in any browser are there to secure the revenue-stream of some companies, not for the protection of the interests of its users. (same goes for phones), the tool might be good (haven't checked), but the foundation it's built on is sand. you want to isolate your keys, current end-host security does not provide much protection against some malware in case recovery of your keys becomes a priority. you also want to make sure the code running is authentic, with js delivered over the net this is quite hard to do verifiably (again, not your protection, industry revenues are the thing to protect). cheers,s ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Entropy is forever ...
Dear all: Quoting the basic definition of entropy from Wikipedia, In information theory, entropy is the average amount of information contained in each message received. Here, message stands for an event, sample or character drawn from a distribution or data stream. In applied cryptography, the entropy of a truly random source of messages is an important characteristic to ascertain. There are significant challenges when applying the information theory, probability, and statistics concepts to applied cryptography. The truly random source (and computations using random message data) must be kept secret. Also the following dilemma should be noted: the truly random source is needed in a digital processor system typically engineered with determinism as a design goal derived from the basic reliability requirement. Quantitatively, the entropy measure for applied cryptography, in the order of hundreds of bits, is way beyond any workable statistical analysis processes. In practice, a truly random source usable for applied cryptography is a system procurement issue that can seldom be blindly delegated as an ordinary operating system service. Thus, one wants a reliable source of uncertainty, a trustworthy one than can barely be tested, as a universal operating system service totally dependent on hardware configuration. Applying the information theory to actual situations is error-prone. Is there a lower entropy in Smith-725 than in gg1jXWXh as a password string? This question makes no sense as the entropy assessment applies to the message source. A password management policy that rejects Smith-725 as a message originating from the end-user population actually constraints this message source with the hope of a higher average amount of information in user-selected passwords. From a single end-user perspective having to deal with an ever growing number of passwords, the entropy concept appears as a formalization of the impossible task he/she faces. Significant conceptual deviation may occur from the common (and correct) system arrangement where a software-based pseudo-random number generator (PRNG) of a suitable type for cryptography is initially seeded from a secret true random source and then used for drawing secret random numbers. It is often inconvenient for statistical testing to apply directly to the true random source messages, but statistical testing of the PRNG output gives no clue about the true random source. The design of PRNG seeding logic is an involved task dependent on the true random source which may be hard to modelize in the first place. In actual system operations, the inadequate seeding may have catastrophic indirect consequences but it may be difficult to detect, and it is certainly a challenging error condition for service continuity (programmers may be inclined to revert to insecure PRNG seeding when the proper true random source breaks down). Despite these pitfalls, I assume my reader to share my endorsement of the true random seeding of a cryptographic PRNG as the main source of random secrets for a digital processor system dedicated to cryptographic processing. As this PRNG output is being used in various ways, chunks of the output sequence may be disclosed to remote parties. It is an essential requirement for a cryptographic PRNG that no output chunk may allow the recovery of its internal state (i.e. some data equivalent to PRNG seed data leading to the same PRNG output sequence as the secret PRNG). In this note, I challenge the view that an entropy pool maintained by an operating system ought to be depleted as it is used. I am referring here to the Linux entropy pool. My challenge does not come through a review of the theory applied to the implementation. Instead, I propose a counter-example in the form of the above arrangement and a very specific example of its use. The central question is this problem. A system is booted and receives 2000 bits of true randomness (i.e. a 2000 bits message from a source with 2000 bits of entropy) that are used to seed a cryptographic PRNG having an internal state of 2000 bits. This PRNG is used to generate 4 RSA key pairs with moduli sizes of 2400 bits. The private keys are kept secret until their use in their respective usage contexts. No data leak occurred during the system operation. After the key generation, the system memory is erased. What is the proper entropy assessment for each of the RSA key pairs (assume there are 2^2000 valid RSA moduli for a moduli size of 2400 bits, a number-theoretic assumption orthogonal to the entropy question)? My answer is that each of the 4 RSA key pairs are independently backed by 2000 bits of entropy assurance. The entropy characterization (assessment) of a data element is a meta-data element indicating the entropy of a data source at the origin of the data, plus the implicit statement that no information loss occurred in the transformation
[cryptography] Introducing SC4 -- feedback appreciated
TL;DR: I took tweet-NaCl-JS and wrapped a little PGP-like webapp around it. I would like to solicit feedback and code review from this community before I submit it for a formal audit and release it to the general public. Links: Source code: https://github.com/Spark-Innovations/SC4 Live demo: https://sc4.us/sc4.html FAQ for experts: http://sc4.us/expert_faq.html FAQ for non-experts: http://sc4.us/regular_faq.html Note that the FAQ links are not secure. This will be fixed eventually. The production push process is a work-in-progress. Unique features of SC4: 1. It is a standalone web application. The server only serves static files. You can even run SC4 from a FILE: URL, though this requires the keys to be embedded in the code. SC4 includes code to automatically generate a standalone version. This is mainly intended to be a proof-of-concept, but it does work. 2. It’s tiny, and therefore easy to audit. It consists of three standard libraries (tweet-NaCl, jQuery, and purify) plus 1000 lines of additional code, and that includes the HTML and CSS. 3. It runs in FF, Chrome and Safari. It might even run in IE but I haven’t tried it. SC4 aims for a point in the design space that balances security against ease of use. PGP is bullet-proof, but not widely deployed because there is a lot of friction in getting it up and running. SC4 aims to eliminate this friction while remaining reasonably secure. It is also based on open standards so that more secure implementations can be easily produced in the future. (Part of my long-term plan is to build an HSM dongle using a Teensy 3 board.) Feedback and constructive criticism much appreciated. Also, I’m seeking someone to serve as a paid consultant on this project. If you’re interested please contact me off-line. My SC4 key is: ---START KEY--- X-sc4-content-type: public-key From: r...@spark-innovations.com Timestamp: Fri, 17 Apr 2015 17:40:56 GMT AocfySUwQXhMGFezXFEJKPL77AoMLupwREpCeOZgRB4= RBDrBehSHbm1x/o+yPFrpdD6kWwSV3QQI8S/y8MdeEg= JaP8eUTkBh2OKRPJYSti9uTuB/vd8a+HV9rCCknw7l95 a9C8lRa1PfP7/rcR8qwUM3BvXkBvT8kaZMJhcCoPCw== ---END KEY--- Thanks, Ron Garret ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Introducing SC4 -- feedback appreciated
At some level, this is in the same conceptual space as Peerio / Minilock. The primary notable difference I see is you have used a binary format for keys and messages. Minilock uses a compressed curve25519 point without any metadata as public key. This is more compact than your format. It'sBase58 encoded it is tweetable which is very nice. Minilock uses JSON for the message format rather than a binary format. I also really like using a protocol buffers for message formats which is what TextSecure does. It looks like your key portability strategy is for users to manage their keys directly as file they provide to instances. Peerio has switched to providing users with a wordlist from which the private key can be derived through a KDF for portability. Text Secure https://play.google.com/store/apps/details?id=org.thoughtcrime.securesmshl=en: +1650-862-5992 Public Key https://raw.github.com/zmanian/pub_keys/master/gpg/%3cz...@manian.org%3E.public.gpg-key On Fri, Apr 17, 2015 at 10:56 AM, Ron Garret r...@flownet.com wrote: TL;DR: I took tweet-NaCl-JS and wrapped a little PGP-like webapp around it. I would like to solicit feedback and code review from this community before I submit it for a formal audit and release it to the general public. Links: Source code: https://github.com/Spark-Innovations/SC4 Live demo: https://sc4.us/sc4.html FAQ for experts: http://sc4.us/expert_faq.html FAQ for non-experts: http://sc4.us/regular_faq.html Note that the FAQ links are not secure. This will be fixed eventually. The production push process is a work-in-progress. Unique features of SC4: 1. It is a standalone web application. The server only serves static files. You can even run SC4 from a FILE: URL, though this requires the keys to be embedded in the code. SC4 includes code to automatically generate a standalone version. This is mainly intended to be a proof-of-concept, but it does work. 2. It’s tiny, and therefore easy to audit. It consists of three standard libraries (tweet-NaCl, jQuery, and purify) plus 1000 lines of additional code, and that includes the HTML and CSS. 3. It runs in FF, Chrome and Safari. It might even run in IE but I haven’t tried it. SC4 aims for a point in the design space that balances security against ease of use. PGP is bullet-proof, but not widely deployed because there is a lot of friction in getting it up and running. SC4 aims to eliminate this friction while remaining reasonably secure. It is also based on open standards so that more secure implementations can be easily produced in the future. (Part of my long-term plan is to build an HSM dongle using a Teensy 3 board.) Feedback and constructive criticism much appreciated. Also, I’m seeking someone to serve as a paid consultant on this project. If you’re interested please contact me off-line. My SC4 key is: ---START KEY--- X-sc4-content-type: public-key From: r...@spark-innovations.com Timestamp: Fri, 17 Apr 2015 17:40:56 GMT AocfySUwQXhMGFezXFEJKPL77AoMLupwREpCeOZgRB4= RBDrBehSHbm1x/o+yPFrpdD6kWwSV3QQI8S/y8MdeEg= JaP8eUTkBh2OKRPJYSti9uTuB/vd8a+HV9rCCknw7l95 a9C8lRa1PfP7/rcR8qwUM3BvXkBvT8kaZMJhcCoPCw== ---END KEY--- Thanks, Ron Garret ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Introducing SC4 -- feedback appreciated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, what problem of traditional PGP implementations did you solve? * Looks like key exchange problem is still present (sent by mail) * Any key authentication? I don't see any verification or certification model. Regards Dominik On 04/17/2015 08:21 PM, stef wrote: ohio, On Fri, Apr 17, 2015 at 10:56:01AM -0700, Ron Garret wrote: 1. It is a standalone web application. putting keys in the browser is like putting keys in front of a dmz. browsers are not designed for this, they are designed for delivering impressions and services to you. the security features you find in any browser are there to secure the revenue-stream of some companies, not for the protection of the interests of its users. (same goes for phones), the tool might be good (haven't checked), but the foundation it's built on is sand. you want to isolate your keys, current end-host security does not provide much protection against some malware in case recovery of your keys becomes a priority. you also want to make sure the code running is authentic, with js delivered over the net this is quite hard to do verifiably (again, not your protection, industry revenues are the thing to protect). cheers,s ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJVMVCNAAoJEHGMBwEAASKCdd0IAIP0zgu/GcT8V3RqjPGDqJ+K aoX2dneLwuPtYmCvoRRkv3iiCoc/XdefktJsF7bMKo4k1cnpq3+Y1mUa4kHG6PjK sBL5o0Jj9xKH3hTol18ownZB1oCZuKIsJB83+RdndjZdvdPqTl3mHldUkRWtyS6n sC7RM9THBHNRvBCWntYyolY0wsdpO61Aagq60joEeoQWM4Yb2l4hmLp10CTm6EJU 66SJoJkDR/VGCJHbFKUSHfJEsOPTyltbxUXR5hpvR+DpPPHO0l/e2uHzdQ3xLiKC jSi+GfQbCYoZIBc5Hzl0rmJjECP7Mg+LEts4aV66s3zpRjaDfe4Won1sUvFxU9M= =nwNR -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Introducing SC4 -- feedback appreciated
On Apr 17, 2015, at 11:27 AM, Dominik Schuermann domi...@dominikschuermann.de wrote: what problem of traditional PGP implementations did you solve? The fact that to use PGP you have to install an application. (This is true for Peerio as well.) That turns out to be too much friction for most people. Whenever you have to install an application you have to decide whether or not you trust the application, and most people have no basis for making that assessment. That leads to potential disasters like NQ Mobile Vault [1]. There are a couple of other advantages too [2] but that’s the main one. * Looks like key exchange problem is still present (sent by mail) At the moment that’s true. I’m planning to build a key server, but I wanted to make sure I had the crypto working first. * Any key authentication? I don't see any verification or certification model. Not yet. The key server will do automatic email verification, but key authentication in general is a very hard problem that I’m not really addressing. The goal here is to make something with very low friction to encourage non-technical people to use it and get them accustomed to having and using a key. rg --- [1] http://www.slate.com/articles/technology/bitwise/2015/04/nq_mobile_vault_the_popular_encryption_app_has_laughably_crackable_encryption.html [2] A secondary advantage (I claim) for SC4 over PGP is that PGP uses RSA keys by default, which are big and cumbersome, and difficult to generate securely because you need a trustworthy prime number generator. ECC keys are much easier to generate from any source of entropy because you don’t need to generate primes. signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Introducing SC4 -- feedback appreciated
On Fri, Apr 17, 2015 at 11:56:48AM -0700, Ron Garret wrote: On Apr 17, 2015, at 11:27 AM, Dominik Schuermann domi...@dominikschuermann.de wrote: what problem of traditional PGP implementations did you solve? The fact that to use PGP you have to install an application. (This is true for Peerio as well.) That turns out to be too much friction for most people. that is actually true and sad, instead of new webapps, maybe the focus should be on multi-platform installers. Whenever you have to install an application you have to decide whether or not you trust the application, i don't see how this decision is not made in the sc4 case -- otr fp: https://www.ctrlc.hu/~stef/otr.txt ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Introducing SC4 -- feedback appreciated
On Apr 17, 2015, at 12:32 PM, z...@manian.org wrote: I don't think this really solves any actual crypto problems. Just to be clear, I’m not claiming to solve any actual crypto problems. I’m claiming (or maybe “aiming” is a better word) to solve a UI/UX problem. I also suspect it's pretty hard to solve any of the big problems while retaining this level of simplicity. But I'm sure you'll learn stuff along the way. Yep, that’s also one of my goals. :-) You should take a look at reop as well which is an even older nacl PGP clone. https://github.com/tedu/reop Thanks. Just FYI, this was my first attempt at a PGP clone: https://github.com/rongarret/clmm That code implemented passphrase protection on the keys. But someone here (Robert Ransom) pointed out to me that if you really care about file security then you should be using a secure file system instead of trying to implement a “half-assed” password protection scheme. That led me to thinking deeply about attack models and the conclusion that a browser based solution could be reasonably secure, where “reasonably secure” means “as secure as the current state of the art in the hands of a non-technical user”. Minilock uses a compressed curve25519 point without any metadata as public key. This is more compact than your format. It'sBase58 encoded it is tweetable which is very nice. SC4 and Minilock use the same underlying crypto. The reason SC4 keys look longer is that it gives you separate keys for signing and encryption. But SC4 keys could be easily made tweetable if people cared about that. NACL encryption is authenticated. The shared secret is used in the MAC as well encryption steps. If all you want is an encryption app, you don't need a ed25519 signing key as well. Yes, I know. Signing is a separate feature. (SC4 lets you sign without encrypting and vice versa.) The main reason for separate keys is that I didn’t know if it was possible to securely convert back and forth between them (but I know now! Thanks for the pointer.) Another reason to keep the keys separate is so that you can revoke them independently. But I’m not sure that’s a good enough reason. rg ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Introducing SC4 -- feedback appreciated
On Fri, Apr 17, 2015 at 11:56 AM, Ron Garret r...@flownet.com wrote: The fact that to use PGP you have to install an application. (This is true for Peerio as well.) That turns out to be too much friction for most people. Whenever you have to install an application you have to decide whether or not you trust the application, and most people have no basis for making that assessment. Why should anyone trust your web page? Do you expect people to audit the source code every time they use it? If they don't, perhaps you made a change which exfiltrates the plaintext to your personal server. Perhaps you targeted a single person, and everyone else sees the real version This is why web pages aren't trustworthy for cryptographic purposes. I wrote a blog post on this topic: http://tonyarcieri.com/whats-wrong-with-webcrypto -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Introducing SC4 -- feedback appreciated
On Apr 17, 2015, at 3:51 PM, Tony Arcieri basc...@gmail.com wrote: On Fri, Apr 17, 2015 at 11:56 AM, Ron Garret r...@flownet.com wrote: The fact that to use PGP you have to install an application. (This is true for Peerio as well.) That turns out to be too much friction for most people. Whenever you have to install an application you have to decide whether or not you trust the application, and most people have no basis for making that assessment. Why should anyone trust your web page? Why should anyone trust anyone’s web page? When was the last time you obtained a software application that was *not* delivered via the web? I’m not saying this isn’t a problem, just that it is not a problem unique to SC4. *Every* application has this problem. Do you use PGP? Did you build it from source? Are you sure you can trust your compiler? Did you verify the signatures? Are you really confident in the root of your chain of trust? Do you expect people to audit the source code every time they use it? No. SC4 was designed to support a wide variety of risk postures. If you don’t trust my server, you can run SC4 from a standalone file on your own file system. The code to generate that standalone file is part of the current SC4 distribution. If you don’t trust that, then it’s pretty easy to write an SC4 implementation in C. If you don’t trust that then I confess that I am at a loss. If they don't, perhaps you made a change which exfiltrates the plaintext to your personal server. Perhaps you targeted a single person, and everyone else sees the real version” Yes, all these things are possible, but they are also possible for PGP. This is why web pages aren't trustworthy for cryptographic purposes. Then what do you propose? If I want to run secure crypto software, how should I do it under the attack model that you’ve implied by your questions? I wrote a blog post on this topic: http://tonyarcieri.com/whats-wrong-with-webcrypto Yes, and I am very sympathetic to this argument. But the problem is that it applies to anything you download from the web, not just webapps. My claim is not that SC4 is secure. My claim is that SC4 is at least potentially as secure as anything else in today’s world. rg ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Introducing SC4 -- feedback appreciated
On Fri, Apr 17, 2015 at 4:25 PM, Ron Garret r...@flownet.com wrote: Why should anyone trust anyone’s web page? When was the last time you obtained a software application that was *not* delivered via the web? There's a big difference between a web page with JavaScript loaded in a browser and a static artifact delivered over the HTTP protocol. Static artifacts downloaded over HTTP by tools like apt-get or yum for example can carry cryptographic signatures that are checked before the artifact is used. In fact this same thing applies to browser extensions like Minilock or Peerio. This means there's a transparent history of these artifacts, and you can verify you got the same version as everyone else. The same thing applies to every Smartphone app. Short of a line-by-line source code audit each time you load a web page, this isn't possible with the web today. No. SC4 was designed to support a wide variety of risk postures. If you don’t trust my server, you can run SC4 from a standalone file on your own file system How is this materially any different than installing an app? Especially a Chrome App like Peerio. That's effectively what Chrome lets you do, except such apps carry cryptographic signatures from their publishers, so you have end-to-end security. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Introducing SC4 -- feedback appreciated
On Apr 17, 2015, at 6:59 PM, Tony Arcieri basc...@gmail.com wrote: On Fri, Apr 17, 2015 at 4:25 PM, Ron Garret r...@flownet.com wrote: Why should anyone trust anyone’s web page? When was the last time you obtained a software application that was *not* delivered via the web? There's a big difference between a web page with JavaScript loaded in a browser and a static artifact delivered over the HTTP protocol. Static artifacts downloaded over HTTP by tools like apt-get or yum for example can carry cryptographic signatures that are checked before the artifact is used. In fact this same thing applies to browser extensions like Minilock or Peerio. This means there's a transparent history of these artifacts, and you can verify you got the same version as everyone else. The same thing applies to every Smartphone app. Short of a line-by-line source code audit each time you load a web page, this isn't possible with the web today. It’s not quite that bad. You only have to audit the code once, and then verify that what you’re running is the same as what you audited. It’s true that there is a real problem here, but it’s not quite as bad as you describe. (And, it is worth noting, it is a political problem, not a technical one. There is no technical obstacle to defining and implementing a signature verification protocol for web pages. In fact, you could even implement a secure script loader using SC4. Hm, there’s an idea :-) No. SC4 was designed to support a wide variety of risk postures. If you don’t trust my server, you can run SC4 from a standalone file on your own file system How is this materially any different than installing an app”? It isn’t any different. That’s the whole point. If you want the security of a local app you can have that. If you want the convenience of a web app at the cost of having to trust the server, you can have that too. rg ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
