Skip to Content.
Sympa Menu

bluesky - RE: talked to ESR

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: "Josh" <josh AT mercuryfs.net>
  • To: "'Global-Scale Distributed Storage Systems'" <bluesky AT franklin.oit.unc.edu>
  • Subject: RE: talked to ESR
  • Date: Thu, 2 Aug 2001 20:28:06 -0700


If you want the patent figures, I'll email them to you. For legal reasons,
I'm not putting the entire patent online. If you want to see the details of
the design, read the design, not the patent. Sorry. This is just
provisional, and I'm simply following orders.

I thought I put the claims in it. Thanks for pointing that out. I just
scanned them, and can email to you directly. But first I ask what your
intention is. Why don't you read the design, then get back to me? If you
have no interest in my project, then I'd rather not give you the patent
claims at this point in time. First I want to know if you are interested or
not.

No, it's a read/write file system with integrated caching, which should be
able to transparently emulate other technologies such as CIFS and NFS. As
for the mac FS, the resource fork is not linked via cryptology, and its not
a very successful file system, nor is it a distributed file system. It's a
different way of doing a file allocation table. Novell calls it a name
space. Completely different comparison.

As for the IPsec issues, end point authentication is implied by the fact
that only the validator and uni id have the first part of the credit card
number, which is used to key the IPsec communication. Because the credit
card number isn't xferred in its normal form. Its assumed that your credit
card is kept confidential, that you use a paper shredder, and basic
knowledge. Remember, my argument is that a determined thief can break
anything.

As for UNI ID's security, the idea is to keep your PIN number secret. I
believe many of your arguments are based on the assumption that something
like this can be accomplished while being hack proof. I disagree. I believe
that any usable system can be hacked. Once combined with PGP, it will be
both central and distributed. Those together should make for the most usable
secure system.

The idea is that if the credit card is valid, and the provided PIN number
and stored (incomplete) credit card number hash to the ID which is claimed,
then assuming only the holder of the card has the pin number, they have been
authenticated and identified, in a basic sense. UNI ID will support the
changing of a pin number.

Whats important is that UNI ID doesn't store your private key, so
authenticating to be yourself and accessing your files are 2 different a
passwords. In my opinion, the security of such a design is acceptable, and
if anything can be improved.

Your cryptographic link that you refer to requires brute force to compute.
Remember, nothing is unbreakable. Also, there is nothing in the design to
keep the split point of the credit card number to be moved to the left, thus
UNI ID stores less of the credit card number, and the PIN number grows in
size. This would only serve to increase security.

Whats also important is that UNI ID is tied to MFS in a modular way, where a
local are network can emulate the UNI ID scheme, or ideally combine the two
together. This would be useful for telecommuters who whish to work from home
using MFS, but their work doesn't trust UNI ID. MFS can be successful
without UNI ID.

Also, the central service does not get involved in online e-commerce
purchases, UNI ID simply refers to your chosen online payment method. That
way, we don't get involved in anything but UNI ID charges. If a pin number
and credit card have been obtained, then by shutting off the credit card and
ordering a new one, you solve it. Because they wont be able to authenticate
using your UNI ID, because UNI ID cant do successful 5 cent charges. This is
when you login using your 3rd uni id password, your most secret one. You're
supposed to print a copy of your passwords when you setup a new uni id
account, and remember the first 2. the pin and private key. The third is
used to log into UNI ID and change over to a new credit card number. At
which point UNI ID (and therefore MFS) would update the ID's group
memberships to use the new ID.



-----Original Message-----
From: Richard Clayton [mailto:richard AT highwayman.com]
Sent: Thursday, August 02, 2001 8:08 PM
To: Global-Scale Distributed Storage Systems
Subject: Re: talked to ESR

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <>, Josh <josh AT mercuryfs.net> writes

>The patent is www.mercuryfs.net/patent.zip,

erm... the file I've just fetched and skip read only has pages 1..32 and
stops when it was about to get interesting by enumerating the claims

I'm not a patent expert, but I know that bit matters :-(

>and it exists to thwart
>Microsoft.
>
>The UNI ID design URL you already have. When setting up a new ID, it first
>scans for a collision, if there is one, it requires you to change your
>completion password (see the design). When multiple people use the same
>card, they each use a different PIN number (as does every individual). An
>example PIN is "3400ok", 34 is the last 2 digits of the credit card, 00 is
>from 0-99, because multiple people can use the same card, and OK is the
used
>chosen "completion" password. The first 4 digits of all UNI ID passwords
are
>assigned. UNI ID stores the credit card in an incomplete manner, only
>reassembling the full card number when the pin number is (securely)
>transferred. Just as ATM machines would have to remember your password,

actually they don't ... there is a cryptographic link between your
account number and your PIN ((and when you "change your PIN" all you
actually do is to change an offset value)).

>so
>would a thief for UNI ID, but this applies to all password based
>technologies. You cannot do a man in the middle attack between the
validator
>and uni-id. To see why, go here: http://www.mercuryfs.net/design/fig_96.pdf

which shows that you're assuming that IPSec will prevent the man in the
middle from existing ... you're doing no end point authentication (that
I can detect) at your level

>Only universal-id.net is to charge the credit card to prove its
>authenticity.

that merely demonstrates that it is a valid credit card number; it does
nothing to link that number to an individual (which the true owner might
see as a reasonable test of "authenticity")

>The validator does not make money by doing this, they merely
>accept your id and password, and turn to universal-id to authenticate it.
If
>somebody is using your UNI ID , that authentication charge is a timestamped
>record in the credit card log.

without further details (such as IP address) this will be useless in
tracking down an abuser - so that would predicate the central service
becoming involved in every disputed transaction.

This involvement in traceability has proved problematic for ISPs already
- -- and it seems unwise to build that in from day one (mind you, for this
amount of money it's unclear to me that anyone would try to chase things
up -- leaving a nice little earner for someone who can skim from many
many accounts -- bad system design again, to have such a possibility).

>If the credit card companies don't like 5
>cents, then I can make it 10 cents, or 25 cents, and instead of refunding
it
>all at the end of the year (less 10 dollars), it can be quarterly. If we
>get volume, we can throw it into a money market account and get a bit of
>interest of it for a few months, thus reducing our total rate, since UNI ID
>isn't out to be the next Microsoft, or verisign, etc. UNI ID will become a
>non profit foundation, ideally.
>
>The MFS design is at my site, www.mercuryfs.net. If you all want me to, and
>I'll gladly cut and paste from it, but I don't think I should fill up
>everybody's inbox. In fact, I already tried to send attachments to all of
>you, but the email list wont allow it. So you have to visit the site I
>guess?

I think what people are looking for is not replication of the same
material but expansion of the bits that confuse them - plus some
indication of the answers to the complicated questions.

>Once again: MFS is the first to separate a file into 2 fundamental units:
>information and data.

I thought the Mac filing system did that :)

>This applies to all files, and can be implemented as a
>transparent caching mechanism on all the other technologies (but that's not
>my intention). It allows true location independence that appears to beat
all
>the others, including coda.
>
>Any other questions?

this looks like a cache design to me (with some "push" as well as "pull"
features) - rather than a filing system per se. Would that be a fair
description ?

- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBO2oVnxfnRQV/feRLEQKdxACglS3A+tQC+wuzEgBjoz3ZKK3o31AAn0Lf
zsIaUSlfUuUCIaK6u+Z03wyu
=emie
-----END PGP SIGNATURE-----

---
You are currently subscribed to bluesky as: josh AT mercuryfs.net
For list information visit http://www.transarc.ibm.com/~ota/bluesky/





Archive powered by MHonArc 2.6.24.

Top of Page