Re: [cryptography] Open Whisper Systems intellectual property dispute

[Tony Arcieri]

On Tue, May 10, 2016 at 8:35 PM, Mansour Moufid <mansourmou...@gmail.com>
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

[Tony Arcieri]

On Thu, May 5, 2016 at 2:40 AM, shawn wilson <ag4ve...@gmail.com> 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

[Tony Arcieri]

On Wed, Apr 13, 2016 at 10:14 AM, Ron Garret <r...@flownet.com> 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

[Tony Arcieri]

On Wed, Apr 13, 2016 at 9:40 AM, Ron Garret <r...@flownet.com> 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

[Tony Arcieri]

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

[Tony Arcieri]

On Tue, Apr 12, 2016 at 7:26 PM, Ron Garret <r...@flownet.com> 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

[Tony Arcieri]

On Tue, Apr 12, 2016 at 8:28 AM, Ron Garret <r...@flownet.com> 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

[Tony Arcieri]

On Sun, Jan 17, 2016 at 2:13 AM, <travis+ml-rbcryptogra...@subspacefield.org
> 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."

[Tony Arcieri]

On Fri, Nov 27, 2015 at 3:47 PM, Greg <g...@kinostudios.com> 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] "There is something Google can do. So they should do it."

[Tony Arcieri]

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] NIST Workshop on Elliptic Curve Cryptography Standards

[Tony Arcieri]

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] NIST Workshop on Elliptic Curve Cryptography Standards

[Tony Arcieri]

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] Introducing SC4 -- feedback appreciated

[Tony Arcieri]

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

[Tony Arcieri]

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] Unbreakable crypto?

[Tony Arcieri]

On Fri, Mar 20, 2015 at 4:02 AM, Enrique Soriano esori...@lsub.org 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?

[Tony Arcieri]

On Wed, Feb 4, 2015 at 5:22 AM, Thor Lancelot Simon t...@panix.com 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

[Tony Arcieri]

On Wed, Jan 7, 2015 at 6:24 PM, listo factor listofac...@mail.ru 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?

[Tony Arcieri]

On Mon, Oct 13, 2014 at 7:51 AM, Derek Miller dreemkil...@gmail.com 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] What's the point of using non-NIST ECC Curves?

[Tony Arcieri]

On Mon, Oct 13, 2014 at 9:19 AM, Derek Miller dreemkil...@gmail.com 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] Weak random data XOR good enough random data = better random data?

[Tony Arcieri]

On Mon, Jul 28, 2014 at 9:23 AM, Lodewijk andré de la porte l...@odewijk.nl
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

[cryptography] STARTTLS for HTTP

[Tony Arcieri]

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

[Tony Arcieri]

On Fri, Aug 15, 2014 at 9:05 PM, Mark Thomas mark00tho...@gmail.com 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

[Tony Arcieri]

On Tue, Jul 29, 2014 at 6:53 AM, Lodewijk andré de la porte l...@odewijk.nl
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

[Tony Arcieri]

On Sat, Jul 26, 2014 at 8:03 AM, Lodewijk andré de la porte l...@odewijk.nl
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

[Tony Arcieri]

On Thu, Jul 10, 2014 at 4:45 PM, John Young j...@pipeline.com 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

[Tony Arcieri]

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?

[Tony Arcieri]

On Tue, May 13, 2014 at 4:23 PM, Phillip Hallam-Baker hal...@gmail.comwrote:

 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

Re: [cryptography] [Cryptography] Is it time for a revolution to replace TLS?

[Tony Arcieri]

On Thu, May 15, 2014 at 1:26 PM, Phillip Hallam-Baker hal...@gmail.comwrote:

 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

[cryptography] Best practices for paranoid secret buffers

[Tony Arcieri]

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

[cryptography] Announcing ClearCrypt: a new transport encryption library

[Tony Arcieri]

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] [Cryptography] Announcing ClearCrypt: a new transport encryption library

[Tony Arcieri]

On Sun, May 4, 2014 at 6:38 PM, Greg g...@kinostudios.com 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

Re: [cryptography] Request - PKI/CA History Lesson

[Tony Arcieri]

On Tue, Apr 29, 2014 at 7:10 PM, tpb-cry...@laposte.net wrote:

  Or Certificate Transparency. :-)

 And how is that supposed to work?


Here, let me help you out:

http://lmgtfy.com/?q=certificate+transparencyl=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?

[Tony Arcieri]

On Fri, Apr 25, 2014 at 1:42 AM, Peter Gutmann pgut...@cs.auckland.ac.nzwrote:

 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

Re: [cryptography] Request - PKI/CA History Lesson

[Tony Arcieri]

On Fri, Apr 25, 2014 at 3:10 AM, ianG i...@iang.org 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?

[Tony Arcieri]

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

[cryptography] Is it time for a revolution to replace TLS?

[Tony Arcieri]

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

[Tony Arcieri]

On Thu, Jan 9, 2014 at 7:51 AM, Thierry Moreau thierry.mor...@connotech.com
 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] Techniques for protecting CA Root certificate Secret Key

[Tony Arcieri]

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] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)

[Tony Arcieri]

On Tue, Oct 1, 2013 at 3:08 AM, Adam Back a...@cypherspace.org 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] [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)

[Tony Arcieri]

On Tue, Oct 1, 2013 at 9:51 AM, Adam Back a...@cypherspace.org 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)

[Tony Arcieri]

On Tue, Oct 1, 2013 at 12:00 PM, Jeffrey Goldberg jeff...@goldmark.orgwrote:

 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?


tinfoilhatThey 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/tinfoilhat

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] The Compromised Internet

[Tony Arcieri]

On Wed, Sep 25, 2013 at 1:07 PM, John Young j...@pipeline.com 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?

[Tony Arcieri]

On Sun, Sep 22, 2013 at 7:05 AM, Ed Stone t...@synernet.com 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

[Tony Arcieri]

On Mon, Sep 16, 2013 at 4:45 AM, Marco Pozzato mpodr...@gmail.com 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] Asynchronous forward secrecy encryption

[Tony Arcieri]

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] Compositing Ciphers?

[Tony Arcieri]

On Fri, Sep 6, 2013 at 5:53 PM, Natanael natanae...@gmail.com 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] urandom vs random

[Tony Arcieri]

On Fri, Aug 16, 2013 at 6:32 AM, shawn wilson ag4ve...@gmail.com 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] urandom vs random

[Tony Arcieri]

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=1post=25102733#comment-25102733

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] urandom vs random

[Tony Arcieri]

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

[Tony Arcieri]

On Fri, Aug 16, 2013 at 12:55 PM, Tony Arcieri basc...@gmail.com 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

[cryptography] OpenPGP adoption post-PRISM

[Tony Arcieri]

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

Re: [cryptography] Cypherpunks

[Tony Arcieri]

On Mon, Jul 22, 2013 at 8:18 PM, Sean Beck seanmckayb...@lavabit.comwrote:

 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)

[Tony Arcieri]

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

[Tony Arcieri]

Cool message bro


On Tue, Jul 16, 2013 at 10:27 AM, John Young j...@pipeline.com 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/cryptographyhttp://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

[Tony Arcieri]

On Fri, Jun 14, 2013 at 8:25 AM, Noon Silk noonsli...@gmail.com 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] NSA breakthrough

[Tony Arcieri]

On Fri, Jun 14, 2013 at 10:27 AM, Tony Arcieri tony.arci...@gmail.comwrote:

 On Fri, Jun 14, 2013 at 8:25 AM, Noon Silk noonsli...@gmail.com 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] Looking for earlier proof: no secure channel without previous secure channel

[Tony Arcieri]

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 h...@net.in.tum.de 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

[cryptography] Cypherpunks mailing list

[Tony Arcieri]

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

[cryptography] Keyspace: client-side encryption for key/value stores

[Tony Arcieri]

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

Re: [cryptography] Keyspace: client-side encryption for key/value stores

[Tony Arcieri]

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 noloa...@gmail.com wrote:

 On Thu, Mar 21, 2013 at 2:52 AM, Tony Arcieri tony.arci...@gmail.com
 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

Re: [cryptography] Sodium. (Was: Re: NaCl Documentation?)

[Tony Arcieri]

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

[cryptography] SafetyLock™

[Tony Arcieri]

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] Web Cryptography API (W3C Working Draft 8 January 2013)

[Tony Arcieri]

On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton noloa...@gmail.com 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

[Tony Arcieri]

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

[Tony Arcieri]

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 d...@cr.yp.to 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?

[Tony Arcieri]

On Sun, Mar 3, 2013 at 11:22 PM, str...@riseup.net 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

[Tony Arcieri]

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

[Tony Arcieri]

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

[Tony Arcieri]

On Tue, Feb 12, 2013 at 10:27 PM, ianG i...@iang.org 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

[Tony Arcieri]

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