Re: [cryptography] Open Whisper Systems intellectual property dispute
On Tue, May 10, 2016 at 8:35 PM, Mansour Moufid wrote: > So what could the dispute possibly be about? > They did a line-by-line translation of libsignal-protocol-java from Java to Rust. The incident ended with them attributing the original library to OWS: https://twitter.com/moxie/status/730230320553828352 -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Kernel space vs userspace RNG
On Thu, May 5, 2016 at 2:40 AM, shawn wilson wrote: > I wonder what the gain is for putting RNGs in the kernel. > A naive userspace RNG will duplicate its internal state when you fork, which can be catastrophic in a cryptographic context. That's a problem that can be fixed by configuring a proper pthread_atfork() (or thereabouts) callback to reseed a userspace RNG when a process forks, but illustrative of the sorts of sharp edges that can occur with userspace RNGs. If performance is important, properly implemented userspace RNGs can be helpful, but they're easy to screw up. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Show Crypto: prototype USB HSM
On Wed, Apr 13, 2016 at 10:14 AM, Ron Garret wrote: > Is that small enough for you? > Yes, that's significantly better. Sorry if I was overly negative before. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Show Crypto: prototype USB HSM
On Wed, Apr 13, 2016 at 9:40 AM, Ron Garret wrote: > Tony: I really don’t mind negative feedback when it’s constructive. In > fact, I very much appreciate it. But I’m really having a hard time > discerning a constructive purpose in your critique. What exactly do you > think that I should be doing differently? Change the design? > Yes, make it significantly smaller than the current form factor. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Show Crypto: prototype USB HSM
On Wed, Apr 13, 2016 at 2:06 AM, Thierry Moreau < thierry.mor...@connotech.com> wrote: > Who wants to be optimistic with respect to threat models in the current IT > landscape? I prefer to be realistic about threats, especially when UX tradeoffs are involved -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Show Crypto: prototype USB HSM
On Tue, Apr 12, 2016 at 7:26 PM, Ron Garret wrote: > This HSM is much more general-purpose than a U2F token. > Well, that's true, but it's also hundreds of times bigger than a token in the Yubikey "nano" form factor, which is actually convenient to keep permanently in the USB slot of a laptop. Your physical design seems pretty unwieldy for laptops (see also Yubico's keychain designs). Yubikey "nano" factor tokens like the NEO-n have also supported more general purposes than a U2F token (e.g. CCID interface, OpenPGP applets, see also PIV) I swear I'm not a paid shill for Yubico, but I'm a fan of small display-free hardware tokens. While a token like what you've built might provide Maximum Security under pessimistic threat models, its large size makes it look rather inconvenient to me. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Show Crypto: prototype USB HSM
On Tue, Apr 12, 2016 at 8:28 AM, Ron Garret wrote: > Some hardware tokens have an input device built in (usually a push button, > sometimes a fingerprint sensor) which needs to be activated before the > token will operate, but these are still subject to phishing attacks Not to rain on your parade, but if you're talking about authentication contexts, U2F solves the phishability problem by deriving domain-separated keys per origin, so it's not possible for an attacker to leverage it for phishing purposes. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] a new blockchain POW proposal
On Sun, Jan 17, 2016 at 2:13 AM, wrote: > 4) Would it be useful to decouple any of the aspects of the block > chain from each other? Right now Bitcoin's transaction throughput is inherently capped by the combination of how many transactions fit in a block and how frequently new blocks are published (hence the "Bitcoin XT" debacle). The proof-of-work function provides what's effectively a Sybilproof leader election system. I thought a clever idea was to decouple leader election from authenticating transactions: http://arxiv.org/abs/1510.02037 (This specific approach has flaws, but I'd like to see the general idea better explored) -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] "There is something Google can do. So they should do it."
On Fri, Nov 27, 2015 at 7:34 PM, Greg wrote: > I dedicated about a third of the blog post to Dell and basically called > them liars. I hardly think that counts as a “ parenthetical”. > You are literally using it as a pretext to go after Google. Can you point to a single time in the past you've mentioned Dell's involvement in this incident without mentioning Google? Firefox has the same behavior for HPKP: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning "Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, default)" Why do you never mention this? Your blog post doesn't mention Firefox once. > > > Your threat modeling priorities are, to put it bluntly, pretty fucked up > Greg. > > Ditto, Tony! Threat: an attacker with local system administrator privileges can override HPKP. This is what you're worried about. You are trying to defend against an attacker with local system administrator privileges. If your local truststore is compromised, your system is compromised. Your best bets are to reinstall the entire operating system or get a new computer. You are worried the door lock is pickable when the house is on fire. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] "There is something Google can do. So they should do it."
On Fri, Nov 27, 2015 at 3:47 PM, Greg wrote: > Thought this list would be interested in reading about the roll that > Google played in compromising 100k+ users (in addition to Dell) Dell puts a malicious certificate in the local trust store and the corresponding private key on all of these systems, and they're a mere parenthetical in your concerns. Your threat modeling priorities are, to put it bluntly, pretty fucked up Greg. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NIST Workshop on Elliptic Curve Cryptography Standards
On Tue, May 12, 2015 at 11:14 AM, Thierry Moreau < thierry.mor...@connotech.com> wrote: > I do not want to push any plot theory without a deep understanding of the > ECC fundamentals. But recalling that NSA had prior knowledge of > differential cryptanalysis (versus academia) and prior knowledge of RSA and > D-H, is there any specific research directions in the ECC field in which > the NSA could have advance knowledge that would induce them to push ECC > deployment over factoring-based RSA? I think it's unlikely that the NSA had advance knowledge of some sort of class of weak curves / attack in the late '90s and baked that attack into the NIST curves in such a way that civilian cryptographers are yet to discover it in 2015. However, the NIST curves definitely have (unintentional?) security problems in addition to large mystery constants which do not inspire confidence. Hence djb and friends / MS / CFRG's desire to have rigid curve generation guidelines. Dual EC DRBG smelled much more of a backdoor. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NIST Workshop on Elliptic Curve Cryptography Standards
On Tue, May 12, 2015 at 1:56 AM, Thierry Moreau < thierry.mor...@connotech.com> wrote: > With ECC, I have less confidence in NIST ability to leverage the > cryptographic community contributions. One hopes they will recommend the same elliptic curve standards that the IRTF's CFRG is standardizing for use in e.g. TLS. Given that, so far, the CFRG has standardized curves developed by djb and Mike Hamburg, at least to me they feel free of NSA influence. We'll see what NIST actually ends up doing. Standardizing the CFRG curves seems like a great way they could help promote interoperability and rebuild their reputation. -- Tony Arcieri ___ 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 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 Fri, Apr 17, 2015 at 11:56 AM, Ron Garret 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] Unbreakable crypto?
On Fri, Mar 20, 2015 at 4:02 AM, Enrique Soriano wrote: > These days we can buy 128GB pendrives (i.e. very long pads) for $35. > > This simple approach seems viable to me: > > https://www.codeandsec.com/Poor-Mans-Unbreakable-Encrypted-TCP-Tunnel Poorly implemented, one time pads are in fact quite dangerous: 1) Extremely great care must be taken to never reuse any portion of the pad. When reused, the attacker can easily obtain the XOR of the plaintexts encrypted with the reused portion of the pad 2) Without authentication (i.e. a MAC), one time pads are highly malleable The author of that software doesn't know the difference between a one time pad and a stream cipher. There's no practical reason to prefer a one time pad to a modern stream cipher like ChaCha20, which can be combined with the Poly1305 MAC to create an authenticated encryption scheme that isn't malleable like an unauthenticated one time pad. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Cryptanalysis of RADIUS MD5 cipher?
On Wed, Feb 4, 2015 at 5:22 AM, Thor Lancelot Simon wrote: > Given how widely used the protocol is, and the failure of various successor > protocols (cute names and all -- TANGENT anyone?) I have always been > surprised > that the cipher seems not to have received any serious cryptanalytic > attention. More modern deployments of RADIUS have better security options, like EAP-TTLS which tunnels the traffic through TLS. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE
On Wed, Jan 7, 2015 at 6:24 PM, listo factor wrote: > He did try to sell maiden-voyage seat reservations. I have no idea > if he collected any money, but if he did, I would not blame him, > I would blame those that coughed up their coin. tl;dr: caveat emptor? -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] What's the point of using non-NIST ECC Curves?
On Mon, Oct 13, 2014 at 9:19 AM, Derek Miller wrote: > However, both scenarios (NSA engineered them to be bad, NSA engineered > them to be good) mean that the NSA knows a great deal more about weaknesses > in Elliptic Curve Cryptography than we do. Doesn't that give you great > pause in using the algorithm at all? > Sure, that's why djb and friends are also working on implementing McEliece and Merkle signatures -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] What's the point of using non-NIST ECC Curves?
On Mon, Oct 13, 2014 at 7:51 AM, Derek Miller wrote: > If the NIST curves are weak in a way that we don't understand, this means > that ECC has properties that we don't understand. > While there's djb's worry that the NSA may have tweaked a curve parameter in such a way as to generate a curve with a one-in-a-million weakness that only they know how to exploit, the NIST curves are weak in other known ways: https://safecurves.cr.yp.to Additionally, newer curves are being picked with an emphasis on performance -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Weak random data XOR good enough random data = better random data?
On Mon, Jul 28, 2014 at 9:23 AM, Lodewijk andré de la porte wrote: > If I XOR probably random data with good enough random data, does that > result in at least good enough random data? > Yes, in fact, it's provably at *least* as random as the most random of the two data sources: https://en.wikipedia.org/wiki/Product_cipher -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] STARTTLS for HTTP
On Sat, Aug 30, 2014 at 3:08 AM, Florian Weimer wrote: > Some clients do not send SNI, so it's possible to send HTTP requests > to the right server, but not HTTPS requests. For STARTTLS to even work, it needs to be supported on both the client and the server. If there are *any* issues with STARTTLS operation for a particular service, the server can merely choose not to enable it, and things would proceed as normal. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] STARTTLS for HTTP
Anyone know why this hasn't gained adoption? http://tools.ietf.org/html/rfc2817 I've been watching various efforts at widespread opportunistic encryption, like TCPINC and STARTTLS in SMTP. It's made me wonder why it isn't used for HTTP. Opportunistic encryption could be completely transparent. We don't need any external facing UI changes for users (although perhaps plaintext HTTP on port 80 could show a broken lock). Instead, if the server and client mutually support it, TLS with an unauthenticated key exchange is used. It seems most modern web browsers and web servers are built with TLS support. Why not always flip it on if it's available on both sides, even if it's trivially MitMed? -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Question About Best Practices for Personal File Encryption
On Fri, Aug 15, 2014 at 9:05 PM, Mark Thomas wrote: > any commercial product could be compromised and not completely secure. > Like Apple’s FileVault2, which Apple has a key to. There aren't known backdoors in FileVault2, or for that mater, Microsoft's Bitlocker. Apple, on the other hand, has been pretty forthcoming with law enforcement backdoors in iPhones (which, actually, seem fairly reasonable, IMO) Don't trust their encrypted filesystem? You better not trust the OS either, for that surely has access to all of the encryption keys you've ever put in main memory. tl;dr: if you don't trust proprietary encrypted filesystems, you better not trust the proprietary OSes they're built into either. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Browser JS (client side) crypto FUD
On Tue, Jul 29, 2014 at 6:53 AM, Lodewijk andré de la porte wrote: > > JavaScript cryptography is possible, there are usecases, and it is > *definitely* *not *"considered harmful" by default. > By default you aren't using HTTPS, HSTS, and CSP. Without these things, doing cryptography in a web page is most definitely harmful and insecure. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Browser JS (client side) crypto FUD
On Sat, Jul 26, 2014 at 8:03 AM, Lodewijk andré de la porte wrote: > Is surprisingly often passed around as if it is the end-all to the idea of > client side JS crypto. > > TL;DR: It's a fantastic load of horse crap, mixed in with some extremely > generalized cryptography issues that most people never thought about before > that do not harm JS crypto at all. > What's in the Matasano article is common sense advice. It may seem elementary for some. But you'd be surprised how many sites fit the pattern the Matasano post describes, arguing that they can provide *better* security by serving JavaScript crypto code over easily-MitMed plaintext HTTP. Here are a couple offenders... #3 Google search result for "encrypted chat": http://www.chatcrypt.com/ Not popular by Google results, but a similarly silly effort: http://www.peersm.com/ -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Silent Circle Takes on Phones, Skype, Telecoms
On Thu, Jul 10, 2014 at 4:45 PM, John Young wrote: > This is the comsec dilemma. If a product or system becomes mainstream > it is more likely to be overtly and/or covertly compromised. This is why it's important the client is open source, the binaries are reproducible, and the encryption is end-to-end. Silent Circle is halfway there: most of the source code is available, but last I heard not all the pieces were there and people weren't able to build it (perhaps that changed?) Clearly OpenSSL is a great demonstration that many eyes don't make bug(door?)s shallow, but if the source is available, it's certainly something that can be used to build trust in a system. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Stealthy Dopant-Level Hardware Trojans
This went to the cypherpunks list, but not to the others: http://eprint.iacr.org/2014/508 Reversing stealthy dopant level trojans! ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Is it time for a revolution to replace TLS?
On Thu, May 15, 2014 at 1:26 PM, Phillip Hallam-Baker wrote: > JSON is a lot more than 10% better than ASN.1 or XML because both of the > latter are bjorked. XML prefixes are insane > And TLS isn't? ;) -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Is it time for a revolution to replace TLS?
On Tue, May 13, 2014 at 4:23 PM, Phillip Hallam-Baker wrote: > In general any proposal of the form 'lets replace X with something 10% > 'better'' is a losing proposition. Particularly when we are talking > about systems where network effects dominate such as protocols, APIs > and keyboard layouts[1]. Does that mean that JSON was more than 10% better than XML, or REST more than 10% better than SOAP? That's not to say that "enterprise" users don't still make extensive use of the, for lack of a better term, crappier technologies, but for the rest of us, we hopefully don't have those monstrosities in our daily lives anymore. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Best practices for paranoid secret buffers
Can anyone point me at some best practices for implementing buffer types for storing secrets? There are the general coding rules at cryptocoding.net for example, that say you should use unsigned bytes and zero memory when you're done, but I'm more curious about specific strategies, like: - malloc/free + separate process for crypto - malloc/free + mlock/munlock + "secure zeroing" - mmap/munmap (+ mlock/munlock) Should finalizers be explicit or implicit? (or should an implicit finalizer try to make sure buffers are finalized if you don't do it yourself?) Are paranoid buffers worth the effort? Are the threats they'd potentially mitigate realistic? Are there too many other things that can go wrong (e.g. rewindable VMs) for this to matter? -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Announcing ClearCrypt: a new transport encryption library
On Sun, May 4, 2014 at 6:38 PM, Greg wrote: > Can you discuss your thoughts on those two, the pros and cons of each, why > you chose one over the other, and whether you'll consider changing your > mind? ^_^ > No specific choices have been made yet. CurveCP and MinimaLT are both valid options. Another one is Trevor Perrin's Noise: https://github.com/trevp/noise/wiki -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Announcing ClearCrypt: a new transport encryption library
ClearCrypt's goal is to produce a minimalist transport encryption library written in a memory-safe language: Rust. Web site: http://clearcrypt.org/ The problem: http://clearcrypt.org/tls/ Github repo: https://github.com/clearcrypt/clearcrypt The project is presently complete vaporware, but the goal is to produce a Rust implementation of a next generation transport encryption library. The protocol itself is still up for debate, but will likely be based off CurveCP or Noise. Emphasis will be placed on simplicity, clarity, and audibility. New features will be rejected unless they meet these goals. Every commit will be approved by multiple people once it has been thoroughly audited. First up: the choice of a license: https://github.com/clearcrypt/clearcrypt/pull/1 -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On Tue, Apr 29, 2014 at 7:10 PM, wrote: > > Or Certificate Transparency. :-) > > And how is that supposed to work? Here, let me help you out: http://lmgtfy.com/?q=certificate+transparency&l=1 -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is it time for a revolution to replace TLS?
On Friday, April 25, 2014, Marcus Brinkmann < marcus.brinkm...@ruhr-uni-bochum.de> wrote: > There are also whole classes of bugs in memory-safe languages that can't > occur in C, for example anything related to garbage collection. > Rust doesn't have a garbage collector. It uses region typing so garbage collection is unnecessary. This is also the main thing that makes Rust an interesting tool for use cases where C/C++ would be the only viable options. Rust is a systems programming language suitable for things like kernel development or RTOS-free "bare metal" development on microcontrollers. Anyway, I'd suggest reading a bit more about how it works before dismissing it out of hand. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On Fri, Apr 25, 2014 at 3:10 AM, ianG wrote: > Worse, consider Firefox's behaviour: it considers a certificate-secured > site such as a self-cert'd site to be dangerous, but it does not > consider a HTTP site to be dangerous. So it tells the user HTTP is > safe, whereas an attempt to secure means that the user is being robbed! I actually brought this up with one of Chrome UX engineers, specifically how to Joe User the address bar makes it appear that plaintext HTTP is more secure than HTTPS with an untrusted cert. While one is MitM-able by an active attacker, the other is most certainly being passively MitMed by someone! :O The response was that users have an expectation of security when using HTTPS that they don't with HTTP, but I wonder, how many people just think they're safe because of the absence of scary warning signs and have no idea what HTTP vs HTTPS actually means? I think plaintext HTTP should show an lock with a big "no sign" over it or something to highlight to users that the connection is insecure. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Is it time for a revolution to replace TLS?
On Fri, Apr 25, 2014 at 1:42 AM, Peter Gutmann wrote: > As with "let's replace C with My Pet Programming Language", you can > write crap in any language you want. The problem isn't the language There's an entire class of memory safety bugs which are possible in C but not possible in Rust. These also happen to be the class of bugs that lead to Heartbleed-like secret leakage or remote code execution vulnerabilities. The problem is very much the language. C has too many sharp edges to write crypto code safely. Heartbleed has also done a great job of illustrating that all the band-aids they try to put on these sharp edges are also flawed. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [ANN] RbNaCl 3.0.0: a modern cryptography library for Ruby
Sidebar: Check out my talk Being Boring - A Survivor's Guide to Ruby Cryptography (describes RbNaCl): http://www.youtube.com/watch?v=e13irYP6WJA RbNaCl is a Ruby FFI binding to the Networking and Cryptography Library by Dan Bernstein and his collaborators: https://github.com/cryptosphere/rbnacl Version 3.0 includes a new "SimpleBox" API designed to be the most straightforward API for cryptography possible. It automatically uses a random nonce per message (using libsodium's randombytes implementation which pulls from /dev/urandom on *IX and CryptGenRandom on Windows). Simplebox is usable for both public-key and secret-key cryptography: https://github.com/cryptosphere/rbnacl/wiki/SimpleBox http://rubydoc.info/github/cryptosphere/rbnacl/master/RbNaCl/SimpleBox Full list of changes from 2.0 below: * Rename RandomNonceBox to SimpleBox (backwards compatibility preserved) * Reverse documented order of SimpleBox/RandomNonceBox initialize parameters. Technically backwards compatible, but confusing. * Ensure all strings are ASCII-8BIT/BINARY encoding prior to use -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Is it time for a revolution to replace TLS?
http://clearcryptocode.org/tls/ Probably not going to happen, but it's nice to dream... -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Techniques for protecting CA Root certificate Secret Key
On Thu, Jan 9, 2014 at 11:08 AM, Thierry Moreau < thierry.mor...@connotech.com> wrote: > I guess a multisignature trust system requires some algorithm support > beyond RSA and ECC signature schemes pushed by NIST, and thus would have > been rejected on the (questionable) basis of lack of support in the DNS > software culture and the (political) basis of lack of NIST approval. > Not at all. You can use any digital signature scheme you want. Give the data you want signed to each of the participants and they can add their signature. It's not much different than the digital equivalent of a paper document signed by multiple parties. Verifiers merely ensure there's t signatures present on a given piece of data before treating it as valid. An example of a system using this approach is The Update Framework: http://freehaven.net/~arma/tuf-ccs2010.pdf See section 6.2: Multi-Signature Trust. There are also multisignature Bitcoin addresses: http://bitcoin.stackexchange.com/questions/3718/what-are-multi-signature-transactions -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Techniques for protecting CA Root certificate Secret Key
On Thu, Jan 9, 2014 at 7:51 AM, Thierry Moreau wrote: > I would suggest that the DNSSEC deployment at the root would be a good > case study for IT security management, from an historic perspective. The > primary source documents, and the conclusion of such case study, could be > helpful to you but ... > I'd actually look at DNSSEC as something of an antipattern. They ostensibly seem to be using One Key To Rule Them all and a Shamir-like secret sharing scheme. This makes less sense to me than a multisignature trust system / threshold signature system with n root keys and a threshold t such that we need t of n signatures in order for something to be considered signed. While I'm sure they took great care to airgap and delete the DNSSEC root key from the computer it was generated on, that's an unnecessary risk that simply doesn't have to exist. Furthermore a multisignature trust system makes it easy to rotate the root keys: if one is compromised you simply sign a new root key document with t of n signatures again, listing out the newly reissued public key. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Allergy for client certificates
On Mon, Sep 30, 2013 at 9:55 AM, Guido Witmond wrote: > On 09/30/13 17:43, Adam Back wrote: > > Anyway and all that because we are seemingly alergic to using client side > > keys which kill the password problem dead. > > > Hi Adam, > > I wondered about that 'allergy' myself. I have some ideas about that and > I'm curious to learn about other. We use client certs extensively for S2S authentication where I work (Square). As for web browsers, client certs have a ton of problems: 1) UX is *TERRIBLE*. Even if you you tell your browser to use a client cert for a given service, and you go back to that service again, browsers often don't remember and prompt you EVERY TIME to pick which cert to use from a giant list. If you have already authenticated against a service with a given client cert, and that service's public key hasn't changed, there's absolutely no reason to prompt the user every single time to pick the cert from all of the client certs they have installed. 2) HTML tag workflow is crap and confusing. It involves instructing users to install the generated cert in their browser, which is weird and unfamiliar to begin with. Then what? There's no way to automatically direct users elsewhere, you have to leave a big list of instructions saying "Please install the cert, then after the cert is installed (how will the user know?) click this link to continue" 3) Key management UX is crap: where are my keys? That varies from browser to browser. Some implement their own certificate stores. Others use the system certificate store. How do I get to my keys? For client certs to replace passwords, browsers need common UI elements that make managing, exporting, and importing keys an easy process. Passwords may be terrible, but they're familiar and people can actually use them to successfully log in. This is not the case for client certs. They're presently way too confusing for the average user to understand. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Tue, Oct 1, 2013 at 12:00 PM, Jeffrey Goldberg wrote: > If the NSA had the capability to pick weak curves while covering their > tracks in such a way, why wouldn’t they have pulled the same trick with > Dual_EC_DRBG? > They wanted us to think they were incompetent, so we would expect that Dual_EC_DRBG was their failed attempt to tamper with a cryptographic standard, and so we would overlook the more sinister and subtle attempts to tamper with the NIST curves -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Tue, Oct 1, 2013 at 9:51 AM, Adam Back wrote: > Right but weak parameter arguments are very dangerous - the US national > infrastructure they're supposed to be protecting could be weakened when > someone else finds the weakness. As the fallout from the Snowden debacle has shown (with estimates of the damage to US businesses in the tens of billions) the NSA seems to be unconcerned with the blowback potential of doing things that are potentially damaging when discovered. I wouldn't put it past them to intentionally weaken the NIST curves. That said, my gut feeling is they probably didn't. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Tue, Oct 1, 2013 at 3:08 AM, Adam Back wrote: > But I do think it is a very interesting and pressing research question as > to > whether there are ways to plausibly deniably symmetrically weaken or even > trapdoor weaken DL curve parameters, when the seeds are allowed to look > random as the DSA FIPS 186-3 ones do. See slide #28 in this djb deck: http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf Specifically: http://i.imgur.com/C7mg3T4.png If e.g. the NSA knew of an entire class of weak curves, they could perform a brute force search with random looking seeds, continuing until the curve parameters, after the seed is run through SHA1, fall into the class that's known to be weak to them. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Compromised Internet
On Wed, Sep 25, 2013 at 1:07 PM, John Young wrote: > Now that it appears the Internet is compromised What threat are you trying to prevent that isn't already solved by the use of cryptography alone? -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Dual_EC_DRBG was cooked, but not AES?
On Sun, Sep 22, 2013 at 7:05 AM, Ed Stone wrote: > There was some criticism from various parties, including from public-key > cryptography pioneers Martin Hellman and Whitfield Diffie,[2] citing a > shortened key length and the mysterious "S-boxes" as evidence of improper > interference from the NSA. The suspicion was that the algorithm had been > covertly weakened by the intelligence agency so that they — but no-one else > — could easily read encrypted messages.[3] Alan Konheim (one of the > designers of DES) commented, "We sent the S-boxes off to Washington. They > came back and were all different."[4] It's now known that the NSA selected S-boxes that hardened the algorithm against differential cryptanalysis. Furthermore, 3DES continues to remain a viable cipher. See: http://www.cosic.esat.kuleuven.be/publications/article-2335.pdf -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
On Mon, Sep 16, 2013 at 3:22 PM, Fabio Pietrosanti (naif) < li...@infosecurity.ch> wrote: > Shouldn't we first try to improve Internet Standard, and only after look > for custom (and usually not interoperable) implementation? > Well, if you want a forward secrecy for asynchronous communication using existing Internet standards, perhaps you could use DTLS? http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework-01#page-20 But FWIW, most of the design elements of Nitro come from CurveCP (albeit implemented atop TCP): http://curvecp.org/ Call CurveCP "custom" if you wish, but it's the sort of thing that *should* be an Internet standard ;) -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Asynchronous forward secrecy encryption
On Mon, Sep 16, 2013 at 4:45 AM, Marco Pozzato wrote: > I'm looking for an asynchronous messaging protocol with support for > forward secrecy > There's also Nitro, which is a CurveCP derivative: http://gonitro.io/ Unfortunately they didn't implement the full CurveCP handshake, which provides both passive and active forward secrecy. It's unfortunate :( -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Compositing Ciphers?
On Fri, Sep 6, 2013 at 5:53 PM, Natanael wrote: > Apparently it's called "cascade encryption" or "cascade encipherment" More generally it's known as a product cipher, which underlies things like Feistel Networks which were used to compose algorithms like DES: https://en.wikipedia.org/wiki/Product_cipher If A1 and A2 are secure PRGs, and we encrypt message m under the keystream of A1(k1) ⊕ A2(k2) [where k1 and k2 are unrelated randomly generated keys], the resulting cipher is at least as strong as the strongest of the two ciphers. This can provide a failsafe if a cryptanalysis is found for either of the two ciphers. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] regarding the NSA crypto "breakthrough"
On Fri, Sep 6, 2013 at 11:47 AM, James A. Donald wrote: > Time to generate and select new elliptic curves by an open process, > wherein any large random quantities are chosen by a non secret process, > such as searching for the appropriate value nearest a round number. > There are curves not selected by e.g. NIST with a published rationale for their selection, like Curve25519. Is there any reason why such curves can't be evaluated retroactively? http://cr.yp.to/ecdh/curve25519-20060209.pdf See in particular Theorem 2.1. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 12:55 PM, Tony Arcieri wrote: > I was quoting the title of the paper in the context of a thread in which > someone claimed that /dev/random should be used in lieu of /dev/random. > That's all I was pointing out. > Blah, /dev/urandom... -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 12:49 PM, Patrick Mylund Nielsen < cryptogra...@patrickmylund.com> wrote: > You replied with a link to a paper that states that both /dev/random and > /dev/urandom have the same weaknesses, and said that "/dev/random isn't > robust." > I was quoting the title of the paper in the context of a thread in which someone claimed that /dev/random should be used in lieu of /dev/random. That's all I was pointing out. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 9:18 AM, Patrick Mylund Nielsen < cryptogra...@patrickmylund.com> wrote: > Yes, but they aren't talking about urandom. Your reply made it sound like > random is weak, but the paper points to both (as urandom is seeded by > random), and they propose a new AES-based PRNG that accumulates entropy > properly. > I'm not sure if you feel the same way, but the opinion of many uneducated observers[1] seems to be that using a PRNG at all in these contexts is "insecure" when that is absolutely not the case, and for the most part there isn't a meaningful difference between the security of random vs urandom except that random will run out of entropy. The "urandom is insecure" claims are specifically what I was trying to challenge, and I hope this paper helps drive it home. If "urandom is insecure" it isn't more so than /dev/random [1]: http://arstechnica.com/security/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/?comments=1&post=25102733#comment-25102733 -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 8:47 AM, Patrick Mylund Nielsen < cryptogra...@patrickmylund.com> wrote: > Not for nothing, but that refers to both random and urandom, showing one > problem with the entropy estimation, and another with the pool mixing > function. > "Finally, we propose a simple and very efficient PRNG construction that is provably robust in our new and stronger adversarial model. We therefore recommend to use this construction whenever a PRNG with input is used for cryptography." -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 6:32 AM, shawn wilson wrote: > I thought that decent crypto programs (openssh, openssl, tls suites) > should read from random so they stay secure and don't start generating > /insecure/ data when entropy runs low. This presumes that urandom is somehow more "insecure", which is not the case despite the ancient scare-language in the manpage. The security of all stream ciphers rests in secure CSPRNGs. Meanwhile, /dev/random is not robust: https://cs.nyu.edu/~dodis/ps/rng.pdf -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OpenPGP adoption post-PRISM
Here's the source of the data, if you're curious: https://sks-keyservers.net/ On Mon, Jul 29, 2013 at 4:22 PM, Tony Arcieri wrote: > Interesting chart: > > https://pbs.twimg.com/media/BQYA_qWCEAIoUFT.png > > -- > Tony Arcieri > -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] OpenPGP adoption post-PRISM
Interesting chart: https://pbs.twimg.com/media/BQYA_qWCEAIoUFT.png -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Redecentralize podcast on the Cryptosphere
Ohai various lists. Here's what I've been working on. Hope you like it. If you want to chat and you happen to be coming to DEFCON, hit me up. https://www.youtube.com/watch?v=NjOqYZzWqI0 Links: - Cryptosphere: http://cryptosphere.org - Celluloid: http://celluloid.io/ - Oasis.js: http://oasisjs.com/ - Conductor.js: https://github.com/tildeio/conductor.js - Xanadu: https://en.wikipedia.org/wiki/Project_Xanadu - Tahoe-LAFS: https://tahoe-lafs.org/trac/tahoe-lafs -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Cypherpunks
On Mon, Jul 22, 2013 at 8:18 PM, Sean Beck wrote: > Does it look encrypted? > Encrypted with a virus -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] A secret sharing consensus protocol (or leader election protocol)
Has there been any work with combining Shamir-style secret sharing with consensus protocols like Paxos and Raft (or leader election protocols like Omega Meets Paxos)? The idea would be to have a network of n peers, who share a secret where t=2 shares are required to reassemble the original secret. This secret is used to sign new values when a group consensus is reached via a Paxos-like protocol. In this scheme, a "proposer" would give its secret share, along with a proposed new value, to "acceptor" nodes, who can reassemble the entire secret. If they accept the new value, they can sign it with the secret, then immediately erase it. If we use a deterministic signature algorithm like Ed25519, every acceptor taking part in the consensus protocol can produce the same signed version of the proposed new value. They can then continue with the consensus protocol's accept phase. The result will be a quorum on a signed value (or a consensus failure if quorum can't be reached, of course) Let's assume a malicious entity gains control of one and only one of the nodes. They are now able to propose new values, so they can manipulate the peer network by proposing malicious values which will get accepted by the rest of the group. However, they do not *immediately* learn the private key. They would only learn the private key if any other node were to propose a value which contained their secret share. -- alternatively -- Secret sharing could be combined with a leader election protocol. In this scheme, the leader and only the leader would learn the shared secret. All proposed values would have to be approved and signed by the leader. I'm not sure I like this as much though. The leader is a single point of failure, and an attacker could maliciously force a leader election through e.g. DoS, having compromised only one other host directly. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Message
Cool message bro On Tue, Jul 16, 2013 at 10:27 AM, John Young wrote: > -BEGIN PGP MESSAGE- > Version: PGP Desktop 9.6.3 (Build 3017) > > qANQR1DDDQQJAwIXvi8KsWclFpDScQ**E+4jMr/**vUA6S04zV34wNYWizM9us1RAST3 > sBEzlFcdRswogIGk52rTgpSi1gPQiO**OcHWLWxmbf4NENBkiW1SEtv1qEAG87**L+Ir > kLJbnxerzrQiRNbH06h6EwNzNDMvL8**/yjFdHaaf5P/JSR7JvHDys > =C7n+ > -END PGP MESSAGE- > > > __**_ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/**mailman/listinfo/cryptography<http://lists.randombit.net/mailman/listinfo/cryptography> > -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NSA "breakthrough"
On Fri, Jun 14, 2013 at 10:27 AM, Tony Arcieri wrote: > On Fri, Jun 14, 2013 at 8:25 AM, Noon Silk wrote: > >> there are no known quantum algorithms which offer any serious benefit in >> this arena. >> > > o_O > > http://en.wikipedia.org/wiki/Shor's_algorithm > Also note: not talking about D-Wave here, just quantum computers in general... -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NSA "breakthrough"
On Fri, Jun 14, 2013 at 8:25 AM, Noon Silk wrote: > there are no known quantum algorithms which offer any serious benefit in > this arena. > o_O http://en.wikipedia.org/wiki/Shor's_algorithm -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Looking for earlier proof: no secure channel without previous secure channel
That's a really interesting idea. I'd love to read your paper when it's available. On Thu, Jun 6, 2013 at 10:31 AM, Ralph Holz wrote: > Hi, > > I am currently doing a write-up that dives into some of the more formal > aspects of authentication. In particular, I am wondering when exactly it > was formally proved that two entities A and B cannot establish a secure > channel between them without such a secure channel having been available > to them at a previous point in time. Or, in other words, you cannot > authenticate without already having authenticated credentials for that > purpose. > > To the best of my knowledge, the earliest such proof is the one by Colin > Boyd: > > Colin Boyd. Security architecture using formal methods. IEEE Journal on > Selected Topics in Communications. 1993. > > Does anyone know of an earlier such (formal) proof? > > Ralph > > -- > Ralph Holz > I8 - Network Architectures and Services > Technische Universität München > http://www.net.in.tum.de/de/mitarbeiter/holz/ > Phone +49.89.289.18043 > PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Google "GO" & Differential Analysis
On Thu, May 30, 2013 at 8:20 AM, Givonne Cirkin wrote: > fyi: google has a programming language "GO". it is designed for parallel > processing > It's designed for concurrency. Concurrency is not parallelism: https://blog.heroku.com/archives/2013/2/24/concurrency_is_not_parallelism By default, Go does not execute any goroutines in parallel, because the multicore scheduler is experimental. If you want any parallelism at all you must explicitly enable the multicore scheduler. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Cypherpunks mailing list
The original Cypherpunks mailing list seems dead. Is there any list that it's successor? -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Keyspace: client-side encryption for key/value stores
Keyspace is a bit different from an OS "keychain" in that it's a networked system, designed to be centrally managed by the holders of a writecap, accessed by holders of the readcap, and with the verifycap on the server to determine the authenticity of values published by administrators with writecaps. My initial (and continued) goal is to use it to centrally manage secure configuration data, but again, I think it's generally applicable as client-side security for distributed key/value databases. That definitely transcends whatever secure key storage an OS provides for a single node. On Thu, Mar 21, 2013 at 12:07 AM, Jeffrey Walton wrote: > On Thu, Mar 21, 2013 at 2:52 AM, Tony Arcieri > wrote: > > https://github.com/livingsocial/keyspace > > > > tl;dr: Keyspace provides "least authority" client-side encryption for > > key/value stores using NaCl's crypto_secretbox (XSalsa20 + Poly1305) and > > Ed25519 as part of a capability-based security model. > > > > One problem I've dealt with quite frequently when deploying web > applications > > is how to keep sensitive configuration files (e.g. database credentials) > > secret. I've longed for a system that provides end-to-end confidentiality > > and data integrity. I think a reasonable goal is to never store secrets > on > > disk in plaintext form, and try to isolate all secret management to the > heap > > of the process in question. It's not perfect, and an attacker could still > > get keys out of RAM, but it's certainly better than plaintext on disk > > guarded by file permissions alone, which is the status quo as far as I > can > > tell. > On Windows and Apple platforms, one usually defers to the OS. For > Windows, you would use the Data Protection API (DPAPI) > (http://msdn.microsoft.com/en-us/library/ms995355.aspx). For Apple, > you would use a Keychain > ( > https://developer.apple.com/library/mac/#documentation/security/Reference/keychainservices/Reference/reference.html > ). > > Android 4.0 and above also offer a Keychain > (http://developer.android.com/reference/android/security/KeyChain.html). > If using a lesser version, use a Keystore > (http://developer.android.com/reference/java/security/KeyStore.html). > > Some of Apple's Keychains appear to be broken at the moment, so its > hit or miss whether the secret is actually protected. Confer: > http://lists.apple.com/archives/apple-cdsa/2013/Mar/msg00038.html and > http://lists.apple.com/archives/apple-cdsa/2013/Mar/index.html. > > Linux has not warmed up to the fact that userland needs help in > storing secrets from the OS. > > Jeff > -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Keyspace: client-side encryption for key/value stores
https://github.com/livingsocial/keyspace tl;dr: Keyspace provides "least authority" client-side encryption for key/value stores using NaCl's crypto_secretbox (XSalsa20 + Poly1305) and Ed25519 as part of a capability-based security model. One problem I've dealt with quite frequently when deploying web applications is how to keep sensitive configuration files (e.g. database credentials) secret. I've longed for a system that provides end-to-end confidentiality and data integrity. I think a reasonable goal is to never store secrets on disk in plaintext form, and try to isolate all secret management to the heap of the process in question. It's not perfect, and an attacker could still get keys out of RAM, but it's certainly better than plaintext on disk guarded by file permissions alone, which is the status quo as far as I can tell. I originally developed my project Keyspace as a sort of software key manager, an alternative to Chef's Encrypted Data Bags which were one of the few other solutions I knew of at the time except for Zookeeper .The Chef solution does not authenticate the ciphertexts, something I wasn't really happy with. Keyspace is also designed so that all encryption happens client-side. The server knows no keys except a public Ed25519 key which is tied to each "vault" and is used to verify that incoming ciphertexts are authentic. Each ciphertext is signed along with a plaintext timestamp which the server can use to prevent replays of old ciphertexts (coming soon! ;) If implemented correctly, an attacker can compromise the credential server and not be able to read the credentials or alter the system configuration. The more I hacked on Keyspace, the more I realized it's useful for more than just storing a handful of credentials. It provides a full-fledged "backend independent" client-side encryption model any key/value store which is supported by the underlying libraries. The storage backend is built on Moneta (https://github.com/minad/moneta), an abstract API for key/value stores, and therefore supports a number of SQL and NoSQL databases as backends, including all SQL databases supported by ActiveRecord, Redis, Riak, Cassandra, CouchDB, and MongoDB, among others. This should make it quite easy to persist encrypted data to whatever backend you wish, with minimal attack surface since the data being persisted is ciphertext before it even hits the wire. Keyspace borrows heavily on Tahoe-LAFS's idea of controlling access using crypto capabilities, and separates access into write capability (can publish new data), read capability (can read existing data), and verify capability (can determine ciphertexts are authentic, but can't read them). A question about crypto-capabilities is: how do you share them securely? Fortunately I think a system like Keyspace can bootstrap itself, providing a "vault" per user which stores the capabilities they have access to. NaCl's Crypto::Box can be used to allow users to publish public keys they can give to a system administrator who can then give them an encrypted capability to their user-specific capability vault. I'd also eventually like to implement a client-side cache which can be used to mitigate DoS attacks by taking the server down, and also identify replay attacks when an attacker in control of the Keyspace server attempts to publish a ciphertext older than what's in the local client cache. Anyway, have a look, I'd love some feedback ;) -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] SafetyLock™
Someone pasted this in #crypto on Freenode. It's rather hilarious: http://www.onyxscientificinc.com/SafetyLockEncryptionInfo.pdf I can't tell what my favorite feature is, the fact I can use up to 9,999 keys per "file", the fact that keys are minimum 1 megabit long, or the fact that it uses FRACTALS! (NOTE: I am using the word "fact" rather loosely here) -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Sodium. (Was: Re: NaCl Documentation?)
On Tue, Mar 12, 2013 at 12:53 AM, Joachim Strömbergson < joac...@strombergson.com> wrote: > There is a new implementation of NaCl by Frand Denis called Sodium that > tries to be more portable and user friendly. Just want to clarify one thing: Sodium isn't a "reimplementation" so much as a repacakging of the existing NaCl code, the most notable aspect being the removal of the assembly code which allows Sodium to be fully PIC. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton wrote: > The Web Cryptography Working Group looks well organized, provides a > very good roadmap, and offers good documentation. > http://www.w3.org/2012/webcrypto/. I have a blog post about it forthcoming, but I'd like to share the tl;dr version here: The normative parts of the specification seem mostly fine. The specification provides no normative advice about what algorithms to use, and worse, provides a non-normative listing of algorithms which are not authenticated encryption modes (for symmetric ciphers, the only mode listed in the spec is AES-GCM) At the very least, I'd like to see the non-normative examples section expanded to include a lot more authenticated encryption modes (EAX mode comes to mind, and seeing support for NaCl algorithms like crypto_box and crypto_secretbox would be super). Right now they give some rather poor recommendations, for example they recommend CBC mode which is fraught with problems. Finally, it'd be great to see someone like NIST or ECRYPT provide browser vendors with normative advice on algorithms to standardize on. The existing WebCrypto spec leaves browser vendors to their own devices, and in that eventuality, the browser venders will probably wind up implementing the W3C spec's (poorly chosen) non-normative recommendations. For an in-depth look at the problems, I'd recommend checking out Matt Green's blog post: http://blog.cryptographyengineering.com/2012/12/the-anatomy-of-bad-idea.html -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] [ANN] RbNaCl 1.0.0: Cryptography for Ruby that doesn't suck
I'm happy to announce the first public release of RbNaCl, a Ruby binding to the Networking and Cryptography library by Daniel J. Bernstein: https://github.com/cryptosphere/rbnacl RbNaCl is actually a Ruby FFI binding to the shared library provided by Sodium, a more portable repackaging of NaCl based entirely on the reference C code in NaCl with all assembly removed: http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-cryptographic-library/ NaCl itself has been designed to be relatively easy-to-use, with many common cryptographic user errors eliminated from its algorithms by design. It provides APIs which seek to eliminate mistakes, and therefore has relatively simple requirements in order for users to utilize it securely. RbNaCl is one of the few Ruby crypto libraries which provides authenticated encryption modes, and wraps both the "box" (public-key) and "secret_box" (secret-key) encryption functions provided by NaCl. In addition, RbNaCl also exposes the Ed25519 digital signature algorithm, a fast and deterministic alternative to algorithms like (EC)DSA. Finally, RbNaCl also wraps the hash functions and HMAC support found in NaCl. If you're looking to do cryptography in Ruby, RbNaCl is one of your best options. Enjoy! -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Sodium: NaCl repackaged for portability/ease-of-use
Hello crypto-people, Frank Denis just announced Sodium, a fork of NaCl containing only the reference C code, packaged using a standard autotools build system: http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-cryptographic-library/ NaCl has traditionally been hard to use because it targets *IX exclusively and the assembly versions of the various algorithms are not PIC yet. For this reason there are a lot of issues making NaCl work portably (e.g. across 32-bit/64-bit platforms, let alone Windows) Sodium is designed to be portable, easy to compile/package, and it even works on Windows! Some might think this undermines some of the original goals of NaCl, however djb has suggested it as an option in the past: On Sun, Dec 16, 2012 at 10:27 PM, D. J. Bernstein wrote: >* More language support. The real work here is making everything > PIC. Of course, if what matters is the API rather than speed, then > achieving PIC is easy: just remove the asm. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Client TLS Certificates - why not?
On Sun, Mar 3, 2013 at 11:22 PM, wrote: > Hi, > > Can anyone enlighten me why client TLS certificates are used so rarely? It > used to be a hassle in the past, but now at least the major browsers offer > quite decent client cert support, and seeing how most people struggle with > passwords, I don't see why client certs could not be beneficial even to > "ordinary users". Not sure what your idea of "quite decent client cert support" is, however I don't think this is the case: 1) It's not easy for users to use client certs instead of passwords. Try to build a demo of a site that makes use of client certs for logging in. I think you'll find it an exercise in frustration 2) It's not easy to move client certs around from browser-to-browser, e.g. if you want to log into the same site from multiple browsers (the sync features of Chrome and Firefox could potentially make this easier) 3) There's no uniform API for managing client certs from JavaScript -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
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
[cryptography] Zooko's semiprivate keys
I've been trying to implement semiprivate keys as described in the paper for Zooko's encrypted storage system Tahoe (see section 6.1: ECDSA and Semi-Private Keys): http://eprint.iacr.org/2012/524.pdf A more verbose description can be found in this email from Hal Finney: https://tahoe-lafs.org/pipermail/tahoe-dev/2009-July/002371.html The basic goals are: - An encryption system with N levels (or 3 levels, in the degenerate case) of keys, where any lower level key can be derived from any higher level key - The main case I care about would be separating the write key (or "writecap" in Tahoe parlance), "read key", and "verify key" - All keys are as small as possible (in the case of NaCl, 256-bits) -- I'm trying to implement them atop NaCl. Here's the design I thought would work, but at present, I'm doing something wrong: https://gist.github.com/tarcieri/4760215 Attempted an implementation here. The test I defined (producing a public key from the derived secret equals the derived public key) is failing: https://github.com/tarcieri/semiprivate/blob/master/lib/semiprivate/keys.rb Anyone with some knowledge of group theory who can help me out spotting the mistake? I'm also going to try to double check this with SAGE and make sure I can actually get things working there. Also if anyone has any ideas as to how I can describe the security properties of this system, I'd love some advice in that department. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] "Zero knowledge" as a term for end-to-end encryption
On Tue, Feb 12, 2013 at 10:27 PM, ianG wrote: > AFAIK, the term 'least authority' as used by Tahoe-LAFS folks does not > refer to 'zero knowledge' as per cryptographic protocols, but to the > concept of least authority as derived from the 'capabilities' school of > security thought. > I strongly agree that capabilities are quite important to the Tahoe-LAFS idea of least authority, and I have been following the project for many years. But I think the Tahoe style of least authority and end-to-end encryption go hand-in-hand. Tahoe's capabilities are crypto capabilities, a.k.a. "capabilities as keys". The capability tokens are the cryptographic keys themselves. This means the entire storage system is opaque to anyone who doesn't hold at least a readcap. The system, by design, deals only in ciphertext. It's ciphertext all the way down After the launch of MEGA, I've seen several sites (e.g. SpiderOak) trying to claim to be the first to have invented this concept. I don't know who did it first, but I'm pretty sure Tahoe was the first to actually get it right. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] "Zero knowledge" as a term for end-to-end encryption
I have seen several services/people using the phrase "zero knowledge" recently, e.g.: https://spideroak.com/ Based on my understanding of zero knowledge proofs and the traditional use of "zero knowledge" in cryptography, this usage seems... novel, to put it politely. In the case of SpiderOak, they're using it to mean "we never see plaintext and we hold no keys to your ciphertexts so there's no way we can read them" I've seen the Tahoe-LAFS folks, for example, attempt to use the phrase "least authority" to imply the same thing, which makes sense to me, but figuring out what "least authority" means in the context of a distributed filesystem may be a tad... indirect. Is there a better phrase to describe this? End-to-end encryption? Client-side encryption? Or is it okay to let people start using the phrase "zero knowledge" refer to this idea? How do people feel about "zero knowledge" being used in this way? -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
