gmane.network.curvecp

curveprotect-20130610

Jan Mojžíš — 2013-06-11T08:24:31

Hello hello,

curveprotect-20130610 available.
http://mojzis.com/software/curveprotect/install.html

important changes:

CurveCP/TCP
===========

- IPv6 support
  * added experimental IPv6 support
  * updated DNS library

- 'netclient' tool rework
  * netclient resolves DNS hostname and
    if it sees CurveCP key in hostname runs CurveCP client and
    if not runs TCP client
  * httpproxy/forwarders/VPN switched to using netclient
  * for more informations see 'netclient -h'

DNS
===

- added backup DNSCrypt resolver
  * based on dnscache
  * implemented DNSCrypt protocol
  * TCP 443 only at this time

- new debuging tool 'dq'
  * based on dnsq and dnsqr
  * added IPv6 support
  * added DNSCurve support streamlined/txt
  * added verbose mode
  * for more informations see 'dq -h'

- dnscache update
  * reworked DNSCurve layer
  * now has 3 modes 'Streamlined only', 'TXT only', 'Autodetected'
  * Autodetected means that cache tries for all DNScurve servers
    first streamlined queries and if it fails than tri

Re: Why doesn't CurveCP use LEDBAT?

David Anderson — 2013-04-05T04:57:03


I have no idea, I'm just the peanut gallery. I'm not involved in the
development of CurveCP.

- Dave

Re: Why doesn't CurveCP use LEDBAT?

Tony Arcieri — 2013-04-05T04:48:25


Specifically I'd call attention to this graph (p.15):

http://i.imgur.com/VMDdTQ3.png

Re: Why doesn't CurveCP use LEDBAT?

Tony Arcieri — 2013-04-05T04:40:45


Are there any plans to actually accomplish this, and if so, can you clue me
in? Per these benchmarks, CurveCP is doing a far worse job than LEDBAT at
accomplishing the goals you describe:
http://bittesehr.sowna.org/CurveCP_benchmarking.pdf

Re: Why doesn't CurveCP use LEDBAT?

David Anderson — 2013-04-05T04:18:40

LEDBAT is designed to aggressively collapse its congestion window in the
presence of competing flows. So, in the presence of any modern TCP flow,
CurveCP on LEDBAT would get approximately no share of the link.
Essentially, it has the same behavior as TCP Vegas in the presence of other
TCP flows.

The behavior is listed as Good/Good because, unlike TCP Vegas, LEDBAT's
behavior is by design: Bittorrent flows should aggressively yield to any
other flows, rather than wrestle a fair share of bandwidth and cause
chronic buffer bloating. Unfortunately, CurveCP *does* want to grab a fair
share of bandwidth from competing TCP flows, so LEDBAT doesn't fit.

- Dave



On Thu, Apr 4, 2013 at 8:33 PM, Tony Arcieri <tony.arcieri-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Why doesn't CurveCP use LEDBAT?

Tony Arcieri — 2013-04-05T03:33:42

I'm well aware CurveCP is a toy, but it seems like it's biting off more
than it can chew in terms of producing a performant network protocol:

http://bittesehr.sowna.org/CurveCP_benchmarking.pdf

In my opinion, CurveCP is reaching too far. It's trying to solve problems
already solved by LEDBAT.  djb even lists LEDBAT as Good/Good in his
decongestion algorithm evaluation:

http://curvecp.org/decongestion.html

If LEDBAT has a clean bill of health in this regard, why create another
decongestion algorithm? IMO, it complects the scope of the project, which
doesn't seem to have a great deal of forward momentum anyway.

It seems like CurveCP has the promise to be the TLS replacement I assume
everyone on this mailing list is looking for, but I feel like trying to
implement a decongestion algorithm in addition to a transport encryption
system makes the project a bit unrealistic from a practical perspective,
especially when the decongestion algorithm aspect is more or less a solved
problem.

Perhaps there are concern

Re: Chicago scheduling algorithm details?

Matthew Dempsky — 2013-01-29T16:29:39


I had not, but that looks like roughly the same description from
http://curvecp.org/decongestion.html, which is a rather high-level
description.  I'm hoping for a sufficiently detailed description of Chicago
that could allow someone to implement it themselves.

Re: Chicago scheduling algorithm details?

Peter Schwabe — 2013-01-29T11:11:26

Hi Matthew,


Did you see the description of Chicago scheduling in 
http://cryptojedi.org/peter/#caced25?

Cheers,

Peter

Re: Chicago scheduling algorithm details?

Matthew Dempsky — 2013-01-28T22:58:21


Since no more detailed description of Chicago is available, I started
writing http://shinobi.dempsky.org/~matthew/curvecp/chicago.html as a
collection of my notes on curvecpmessage.c's implementation.  It's pretty
rough, but maybe someone will find it interesting/useful.  (Feedback
welcome.)

A few things I've noticed while writing it though, that seem suboptimal to
me:


1. curvecpmessage.c has a "slow restart" phase that seems to be meant for
when it hasn't successfully transmitted in a while, and it should reset to
~1 block/second and ramp up again.  But a slow restart isn't triggered
until an ACK packet is actually received, which might not happen until
after we've just injected a bunch of packets.

E.g., suppose a pipelined HTTP connection.  The first request triggers a
large response that allows the transmission rate to grow to capacity.

Now the client keeps the connection alive for 10 seconds, and sends another
request triggering another large response.  The server still has its high
data rate from

Re: Nonce clarification: curvecpserver.c vs curvecp.org

Matthew Dempsky — 2013-01-27T11:21:36


Doh, nevermind!  Reading this again, it's actually pretty clear that the
counter bytes always have to monotonically increase.  So it's invalid to
use "CurveCP-client-M\0\0\0\0\0\0\0\0" after
"CurveCP-client-I\7\7\7\7\7\7\7\7", because although the first 16 bytes are
larger in lexicographical order, the second 8 bytes still need to be larger
in reverse lexicographical order as well.

The first time I read those sentences, I must have assumed that there was a
total lexicographical ordering on nonces defined by the orderings of the
first 16 and last 8 bytes, but in fact nonces are only partially ordered.

Problem solved. :)

Nonce clarification: curvecpserver.c vs curvecp.org

Matthew Dempsky — 2013-01-27T07:30:59

According to http://curvecp.org/nonces.html:

"""Each nonce used by the short-term client secret key c' is strictly
larger than all nonces previously used by c'. ("Larger" means that the
first 16 bytes are larger or equal in lexicographic order and that the
remaining 8 bytes are larger in reverse lexicographic order.)"""

By that definition, the nonce "CurveCP-client-M\0\0\0\0\0\0\0\0" is larger
than "CurveCP-client-I\7\7\7\7\7\7\7\7".  But curvecpserver.c only keeps a
single 64-bit receivednonce counter, and expects the nonce counters in both
"Initiate" and "Message" packets to be monotonically increasing.

This doesn't cause any interoperability problems with curvecpclient.c,
because curvecpclient.c uses a monotonically increasing counter across all
three nonce types.  But there doesn't seem to be anything on
curvecp.orgthat indicates this is actually required.

In fact, the closest thing I can find is this sentence:

"""The short-term client secret key c' uses nonces
"CurveCP-client-H\0\0\0\0\0\0\0\0" (co

Bug: curvecpmessage nextaction scheduling

Matthew Dempsky — 2013-01-25T17:24:27

I think there's a bug in the curvecpmessage nextaction scheduler that can
result in curvecpmessage pausing for up to 60s instead of resending old
blocks.  In particular, I think this block:

    if (earliestblocktime)
      if (earliestblocktime + rtt_timeout > lastblocktime + nsecperblock)
        if (earliestblocktime + rtt_timeout < nextaction)
          nextaction = earliestblocktime + rtt_timeout;

should actually be something like this:

    if (earliestblocktime) {
      long long nextretry = earliestblocktime + rtt_timeout;
      if (nextretry < lastblocktime + nsecperblock) nextretry =
lastblocktime + nsecperblock
      if (nextretry < nextaction) nextaction = nextretry;
    }

Otherwise if we want to resend a block prior to when the scheduler has
decided we're allowed to normally transmit next, we end up ignoring
altogether that there's a pending resend.

Example scenario:  Just to keep numbers simple, suppose we have a 10s
rtt_timeout and a 2s nsecperblock.  Also, that we sent a block at time T,
a

Bug: curvecpmessage.c doesn't correctly limit connections to 2^60-1 bytes

Matthew Dempsky — 2013-01-25T00:42:02

In curvecpmessage.c from nacl-20110221, there's this line:

      if (sendbytes >= 1152921504606846976LL) die_internalerror();

I believe the intention here is to give up if the child writes more than
2^60-1 bytes to the byte stream, but sendbytes is only the count of the
number of bytes in flight.  I think this line should actually be:

      if (sendacked + sendbytes >= 1152921504606846976LL)
die_internalerror();

to check if the *total* number of sent bytes exceeds 2^60-1.

Even better would be to limit the read(fromchild[0]) call to not read more
than (1ULL << 60) - 1 - sendacked - sendbytes bytes in the first place, and
to simply close fromchild[0] once that limit has been reached.

(Of course, this is generally moot since the byte limit is unlikely to be
reached in practice.)

Typo on "message-handling programs" page?

Matthew Dempsky — 2013-01-23T09:50:55

"As a client, do not use length bytes above 40 until a message has arrived
from the server. (The messages inside CurveCP Initiate packets are limited
to 640 bytes.)"

I think "above 40" should be "above 640"?  E.g., curvecpmessage defaults to
using 512 byte messages on the client-side until it sees a message from the
server.

LEDBAT congestion control

Tony Arcieri — 2013-01-21T22:29:26

I am most definitely looking for an encrypted UDP-based transport for use
for bulk transfers where congestion control is an issue. My main use case
for UDP is STUN/ICE-style firewall traversal. BitTorrent faced all these
same problems and produced uTP/LEDBAT, which have a congestion control
algorithm which is (arguably) fairly good:

http://tools.ietf.org/html/draft-ietf-ledbat-congestion-09

It seems like there are ideas in both CurveCP and uTP/LEDBAT which need to
cross-pollenate. I wish I could have CurveCP's security model and LEDBAT's
congestion control.

Has anyone tried to combine these ideas in any shape or form, and if so,
how did that turn out?Honestly I think the most practical thing to do is
layer the CurveCP encrypted transport design onto LEDBAT and allow that to
handle the congestion control. The resulting protocol would, of course, not
be CurveCP...

Anyone else been thinking along similar lines and if so, how do you feel
about this?

Embedding CurveCP in 3rd party applications

Tony Arcieri — 2013-01-08T22:39:21

It seems that CurveCP is primarily implemented as a set of executables as
opposed to a (shared or static) library.

Are there any plans to change this? It seems like it would be helpful if
CurveCP were a library instead of programs. Or is the expected usage
supposed to be talking to these programs over pipes?

Re: Long-term client keys and digital signatures

CodesInChaos — 2013-01-08T08:56:57

I looked a bit into using a single key for both signing and key-exchange a
few months ago.

My findings were:

1. It works. You can use the same private scalar for both, and there is a
simple formula
    to convert an Edwards form (used for signing) public key to a
Montgomery form(used for key-exchange)
    public key.

    montgomeryX = (edwardsY + 1)*(1 - edwardsY)^(-1) mod q

    Converting in the opposite direction isn't directly possible, because
Ed25519 cares about
    the (sign of) the second coordinate, but Curve25519 doesn't. So I
recommend using the Ed25519 public
    key as your main public key, and convert to Montgomery where needed.

2. I don't know if it's secure. But I found a security proof for ECIES +
EC-Schnorr,
    which is a quite similar combination to EC-DH + EdDSA. So I'm hopeful
that it's secure.

    > In the random oracle model ECIES-KEM and EC-Schnorr are jointly secure
    > if the gap-DLP problem and gap-DH problem are both hard
    http://www.zurich.ibm.com/~anj/publications/EMV

Long-term client keys and digital signatures

Tony Arcieri — 2013-01-08T07:25:50

I'm looking for a way to unify the identities of people who converse over a
transport protocol with the data they sign. That is to say, I'm trying to
build a system where I can safely say "I am actually talking to the guy who
signed this data over a secure channel"

I'd also like for people to develop these identities over time, signing
lots of objects, and in a conversation have a peer able to prove they were
the signer. (This is for a distributed web-of-trust type of system if you
haven't guessed it already)

Reading about CurveCP, it talks about long-term server keys and short-term
client keys. I haven't been able to figure out if there's a problem with
long-term client keys. I'm working on a peer-to-peer system where nodes can
act in both a client or server capacity depending on the context, and I
would like to have a unified sense of identity in both of those roles.

Is there a particular problem with long-term client keys?

Likewise, is it possible to combine the identity of someone creating
digital si

backup tool for CurveCP keys

Jan Mojžíš — 2012-12-17T08:31:47

Hello,
I'm working on backup-tool for my CurveCP keys and
have two questions.

CurveCP key consist from files:
.expertsonly/lock
.expertsonly/noncecounter
.expertsonly/noncekey
.expertsonly/secretkey
publickey

So for minimal backup I should: 
backup .expertsonly/noncekey
backup .expertsonly/secretkey

And in case of recovery I should:
recover .expertsonly/noncekey
recover .expertsonly/secretkey
compute publickey 
create .expertsonly/lock
create .expertsonly/noncecounter, for example as 'nanoseconds from C epoch' stored in 8-bytes little-endian

I'm I right?

And second question.
What is the best choice for file encryption/authentication using NaCL and secret password?
I'm actualy using classic tarball encrypted/authenticated using crypto_secretbox and
secondary encrypted using crypto_stream_aes128ctr, but I'm not sure, if it is best
available solution.


Thanks
Jan

Re: Is CurveCP still being worked on?

D. J. Bernstein — 2012-12-17T06:27:12

Certainly. Major NaCl tasks at the moment:

   * NEON speed. The Curve25519 NEON code is in SUPERCOP but the
     Ed25519 NEON code still needs cleanups. Of course, applications
     focusing on x86/amd64 won't care about this.

   * 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.

   * More formal verification; in particular, guaranteeing that the
     intermediate variables never overflow. There's already extensive
     review of the crypto_box() code in the current NaCl release but
     further automation would build confidence and save time.

CurveCP is only in prototype form and has more to do; main recent work
is in congestion control.

---Dan

Re: Is CurveCP still being worked on?

Tony Arcieri — 2012-12-08T03:08:25

I've actually done a Ruby binding to the Ed25519 implementation from SUPERCOP:

https://github.com/tarcieri/red25519

and am presently working on a NaCl binding for Ruby:

https://github.com/tarcieri/rbnacl

That said, the last release of NaCl was February of 2011. While
updates to the project web site show it's not a complete ghost town,
they don't instill as much confidence as updates to the software
itself.

--
Tony Arcieri