headers
John Carlson | 1 Mar 2008 01:17
Picon
Favicon

Re: MacOSX Leopard e

$ ../rune macify-swt.e capDesk.e-swt ../../../Applications/capDesk.app
When I click on the capDesk.app icon, it launches an icon in the task  
bar, and then goes away.
$ ./macify-swt.e eChat.e-swt ../../../Applications/eChat.app
Same
When I'm in
/Users/johncarlson/Applications/eChat.app/Contents/MacOS
and type
$ ./run
the script returns with no output.

$ find Applications/
Applications/
Applications//capDesk.app
Applications//capDesk.app/Contents
Applications//capDesk.app/Contents/Info.plist
Applications//capDesk.app/Contents/MacOS
Applications//capDesk.app/Contents/MacOS/run
Applications//capDesk.app/Contents/MacOS/script.e-swt
Applications//eChat.app
Applications//eChat.app/Contents
Applications//eChat.app/Contents/Info.plist
Applications//eChat.app/Contents/MacOS
Applications//eChat.app/Contents/MacOS/run
Applications//eChat.app/Contents/MacOS/script.e-swt

Aren't users a b***h?

John
(Continue reading)

Permalink | Reply | 0 comments |
headers
Derick Eddington | 2 Mar 2008 08:01
Picon

Re: E language over I2P

On Fri, 2008-02-29 at 10:52 -0500, Kevin Reid wrote:
> My implementation will include the feature that CapTP can use  
> multiple secure transports (besides VatTP);

Cool.  Will this be modularized so that new transports can be used?
With I2P, I wasn't initially thinking of replacing the default transport
but being able to have I2P as an additional transport that works with
the others, but that sounds like it won't work, see below.

> However, to be able to have consistent vat identities so that 3-party  
> introduction always works, a vat must use the same VatID and  
> associated key-pair no matter what transports it is using.

Oh. Right.  I think this means I2P can't be a good fit with other
transports because it is its own entire secure transport, designation,
location, and authentication system.  However, if the transport and
URI/referencing/introducing stuff is modularized and abstracted right,
would it be possible to swap I2P in and use it only, so that there could
be only-I2P-transport E-users networks, where all 3rd party
introductions are fine?

> What advantages do you see of using I2P instead of VatTP?

Privacy.  I2P is an anonymizing network.  Otherwise, participants can be
linked because someone can see 1.2.3.4 is connected to 6.7.8.9.  This is
my main interest and why "I think the potential [of E over I2P] is
awesome".

Also, I2P's base protocol is datagram based, which I thought could
eliminate having to do your own packet format over bytestreams for CapTP
(Continue reading)

Permalink | Reply | 6 comments |
headers
Mark Miller | 2 Mar 2008 08:08
Picon
Gravatar

Re: E language over I2P

On Sat, Mar 1, 2008 at 11:01 PM, Derick Eddington
<derick.eddington@...> wrote:
>  I2P provides destination (Vat) location resolving using a distributed
>  hashtable.

How do you resist Sybil attacks?

--

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM
Permalink | Reply | 1 comment |
headers
David Wagner | 2 Mar 2008 08:38
Picon
Favicon

A broken brand?

I've been reading the Caja spec.  It includes an example of a brand
implemented in Caja, using an implementation technique attributed to
Marc Stiegler.  I think I may have found an attack on it, and I was
curious whether this was well-known.  I'll re-print the Caja code:

function Brand() {
  var flag = false;
  var squirrel = null;

  return caja.freeze({
    seal: function(payload) {
      function box() {
         squirrel = payload;
         flag = true;
      }
      box.toString = function() {
        return "(box)";
      }
    unseal: function(box) {
      flag = false; squirrel = null;
      box();
      if (!flag) {
        throw ...;
      }
      return squirrel;
    }
  });
}

Now for the attack.  Let Br be some brand.  Let Bx be some sealed that
(Continue reading)

Permalink | Reply | 19 comments |
headers
Bill Frantz | 2 Mar 2008 08:47
Favicon

Re: E language over I2P

derick.eddington@... (Derick Eddington) on Saturday, March
1, 2008 wrote:

>> However, to be able to have consistent vat identities so that 3-party  
>> introduction always works, a vat must use the same VatID and  
>> associated key-pair no matter what transports it is using.
>
>Oh. Right.  I think this means I2P can't be a good fit with other
>transports because it is its own entire secure transport, designation,
>location, and authentication system.  However, if the transport and
>URI/referencing/introducing stuff is modularized and abstracted right,
>would it be possible to swap I2P in and use it only, so that there could
>be only-I2P-transport E-users networks, where all 3rd party
>introductions are fine?

One could imagine some certificates which said the vatID x on
network a is the same as vatID y on network b. If these
certificates were signed with the private keys which generated the
two vatIDs, this assertion could be believed, although the
resulting system is somewhat more complex.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said users haven't
www.periwinkle.com | learned anything about security?" -- Bruce Schneier
Permalink | Reply | 0 comments |
headers
Derick Eddington | 2 Mar 2008 10:08
Picon

Re: E language over I2P


On Sat, 2008-03-01 at 23:08 -0800, Mark Miller wrote:
> On Sat, Mar 1, 2008 at 11:01 PM, Derick Eddington
> <derick.eddington@...> wrote:
> >  I2P provides destination (Vat) location resolving using a distributed
> >  hashtable.
> 
> How do you resist Sybil attacks?

>From http://www.i2p2.de/how_threatmodel#sybil :

        We currently have not implemented any particular technique to
        address Sybil, but do include placeholder certificates in the
        router's and destination's data structures which can contain a
        HashCash certificate of appropriate value when necessary (or
        some other certificate proving scarcity).

And http://www.i2p2.de/techintro.html :

        To take into account Sybil attacks on the netDb, the Kademlia
        routing location used for any given key varies over time. For
        instance, rather than storing a routerInfo on the peers closest
        to SHA256(routerInfo.identity), they are stored on the peers
        closest to SHA256(routerInfo.identity + YYYYMMDD), requiring an
        adversary to remount the attack again daily so as to maintain
        their closeness to the current routing key.

As I mentioned, I'm out of the loop about I2P, and I was never fully
familiar with it all.  I brought it up because I have always hoped to be
able to do E over an anonymizing network so that linkability of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Reid | 2 Mar 2008 13:49
Picon
Gravatar

Re: E language over I2P

On Mar 2, 2008, at 2:01, Derick Eddington wrote:
> On Fri, 2008-02-29 at 10:52 -0500, Kevin Reid wrote:
>> My implementation will include the feature that CapTP can use  
>> multiple secure transports (besides VatTP);
>
> Cool.  Will this be modularized so that new transports can be used?

Yes.

To add a transport, you just write a maker of objects which connect  
over that transport (when given the local vat key and the desired  
remote VatID) and return message streams, define a syntax for  
serializing its ID/lookup/location information in CapTP URL search- 
paths, and tell the creator of your vat's CapTP subsystem to trust it.

Approximately. I haven't actually implemented this yet, so I can't  
say this will be *exactly* how it works.

> However, if the transport and URI/referencing/introducing stuff is  
> modularized and abstracted right, would it be possible to swap I2P  
> in and use it only, so that there could be only-I2P-transport E- 
> users networks, where all 3rd party introductions are fine?

Yes. I'd prefer to avoid that situation though.

Also, as Bill Frantz said:
> One could imagine some certificates which said the vatID x on  
> network a is the same as vatID y on network b. If these  
> certificates were signed with the private keys which generated the  
> two vatIDs, this assertion could be believed, although the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tyler Close | 2 Mar 2008 18:17
Picon

Re: A broken brand?

On Sat, Mar 1, 2008 at 11:38 PM, David Wagner <daw@...> wrote:
>  Does this attack look correct to you?  Is it well-known?

Yes and I don't know.

>  P.S. How did I find the attack?  I used trust analysis (aka taint
>  analysis).  For each security perimeter (e.g., each function), you treat
>  the data flowing across that security parameter (e.g., the arguments to
>  that function) as untrusted.  All of the fields/properties of an untrusted
>  object are themselves untrusted.  Invoking an untrusted object gives the
>  attacker a chance to run code; the return value from such an invocation
>  is itself untrusted.

If I understand this methodology correctly, then wouldn't it still
flag this code as suspicious even after your proposed fix is applied?

--Tyler
Permalink | Reply | 0 comments |
headers
Bill Frantz | 2 Mar 2008 21:20
Favicon

Re: E language over I2P

kpreid@... (Kevin Reid) on Sunday, March 2, 2008 wrote:

>Also, as Bill Frantz said:
>> One could imagine some certificates which said the vatID x on  
>> network a is the same as vatID y on network b. If these  
>> certificates were signed with the private keys which generated the  
>> two vatIDs, this assertion could be believed, although the  
>> resulting system is somewhat more complex.
>
>The way I see this working is that there is One True Vat Identity  
>(key-pair), which is used to sign statements (certificates?) of the  
>equivalence of a given other-transport-identifier.

Yes. It is interesting that this approach is also the correct
approach for a pet name system to use with TLS. In the TLS case we
have an entranched business model, that results in poorer security,
and prevents this use of a certificate chain. (Because CAs will not
issue certificates to keys which can be used to sign other
certificates, an organization can't have a single signing key
certified by a CA and then sign separate machine keys for each of
their servers.)

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said users haven't
www.periwinkle.com | learned anything about security?" -- Bruce Schneier
Permalink | Reply | 0 comments |
headers
David Wagner | 2 Mar 2008 21:40
Picon
Favicon

A broken brand?

Tyler Close writes:
>If I understand this methodology correctly, then wouldn't it still
>flag this code as suspicious even after your proposed fix is applied?

Yup.  It may be useful as a heuristic for identifying places in the
code that would benefit from careful thought, but it's not going to
give us a proof or disproof of security/correctness.
Permalink | Reply | 0 comments |

Gmane