[Clips] "Right. What's a Cubit?" (was Re: Re: [Cocoa-students] Using various c libraries in Cocoa?)
--- begin forwarded text
Delivered-To: rah@shipwright.com
Date: Sun, 17 Dec 2006 21:21:38 -0500
To: "Cocoa Bootcamp"
If you need specific help, fire away!
Well, since you asked :-), I'm trying to do a quick-and dirty script-kiddy-crypto-wrapped-in-Cocoa version of a bearer underwriting scheme that I've been blathering on about for about the last 10 years or so. See the URL in my .sig, below for various messy details. [And, no, I can't, as yet, code my way out of a paper bag (two courses in Pascal in 1984 don't really count, trust me...), or wasn't able to, at least, until I went on the Callaway Gardens Death March week before last (I'm, um, large, with a bum knee, and someone, not me, noticed that from the dining room of the admirably-discovered new-and/or-temporary Big Nerd Ranch Bootcamp Bivouac to the second story of the no-tell-motel-esque "suite module" we were all in came to 6-plus stories of stairs, up, and back, three times a day... :-)).] My "company" itself, see .sig, below, is a partially ossified, completely dessicated, ostensibly estivating zombie -- at the moment -- so any claims to future attractions are, um, very future, shall we say. Which gives me, um, scope, to plink around with this stuff as I see fit. Which means -- at the moment -- a Chaumian blinded probably RSA (though I'm strangely attracted to elliptic curves :-), if the usual blind signature m-of-n where m and n = 2 Shamir secret-sharing double-spend protection works with those, which I think it should; note either way I'm trying to unencumber myself from the patent system as much as possible) bearer certificate representing whatever the underwriter says it is -- on behalf of the issuer, of course. In short, and quite hypothetically, send your financial asset to me by DTC or Fedwire, or equivalent, and I'll issue you a bearer certificate on the net, for a fee. :-), and anyone presenting me a bearer certificate later for the asset in question will be wired/cleared the asset through Fedwire or DTC, or equivalent for free. And, in the meantime, people can swap those bearer certificates representing their ultimate claims on their various assets, between each other, on the net, for free. :-). If it's still legal, under various once-and-future legal regimes, of course. Call it securities re-mobilization, as opposed to securities im-mobilization, which is what happened when share certificates were converted to book-entries decades ago, so guys with guns didn't have to deliver fancy pieces of paper to literal cages in operations departments in the basements of securities firms. Mostly, I'm just after transaction cost data using actual operating numbers, which you get by actually writing and running code, which nobody, except me, these days, is gonna do for free, and I'm going to be literally on a beach come April, so I've got nothing better to do... :-). The reason I want to do this on Apple hardware with Objective-C using Cocoa is because, like the proverbial dog, heh, I can, and, if it eventually works, the respective NeXT-finance and erst-BSD-cypherpunk-crypto angles should match up quite nicely, I figure. Someday, somebody, could be delivered a fully functional Macintosh workstation to either trade or underwrite these things, plug and play, and, given the (hypothetical) reduction in transaction costs, it won't matter to anyone, except me and people like me, what kind of machine it runs on, because it'll save them too much money to care, and it'll cost us too little money to set up for them :-). And, in the meantime, the whole idea is too wack-job for anyone in the business to actually care about until they actually see it work, so the only people who care is, well, me, and that's what I want to do. That's the idea, anyway. With that ASCII-tome out of the way as preamble, I present another one, half as long... At 5:01 PM -0500 12/17/06, Jonathan wrote:
If you need specific help, fire away!
Okay. First. To paraphrase Noah in the old Cosby comedy bit, "Right. What's
a Stub?"
It seems to me from my interrogatories with Messrs Google and Wikipedia
that I just bang out a .h file with all the objects and methods in it
matching all the functions and ?structs? that I find in the various .c
files I want to use.
Then, in my .m file, I write up Objective-C code that calls the various
c-bits that I need, thereby encapsulating them in objects, to, um,
objectify them with. (Can you tell I've watched too much 'Squidbillies',
yet?)
With the judicious use of the #import statement in both files, of course.
Am I close?
[BTW, googling something like "#import tomcrypt.h" makes Mssrs Google and
Wikipedia laugh, though there are plenty of "#include tomcrypt.h" links out
there. Which makes me understandably nervous. Points to a potentially
profitable market inefficiency, or absolute folly, one or the other, and I
expect it to be the other, frankly.]
Second, I'm pretty sure that I can just part-out (in the automobile sense)
the various crypto protocols I need, since they're all split up into .c
files, in their own directories, anyway, so you're right, I don't need to
wrap the whole Lamn Dibrary In The Interests of Science, and all that, just
yet.
Eventually, I'm looking at two kinds of apps (a trading app and and
underwriting app), and a maximum of four players (two traders, and one or
two underwriters) all talking to each other to execute, clear, and settle a
single transaction all at once, by swapping one kind of, (don't say it
fast) bearer asset, for another. :-).
I figure since the trading app is a kind of client, it can be a core data
app, like Mail with its mail, or iTunes with its tunes, or the AddressBook
with its addresses, or even Safari with its history and bookmark URL lists.
I also think, for a first pass, the underwriter can be a core data app too,
to keep things simple. [With some calls/transfers/etc. to a real-live
central data repository for intrafirm business, and/or web-server for
initial customer contact and/or "terminal" emulating scrape-ware for the
book-entry clearinghouse/wire bits to handle the back end... Um... Later.]
Underneath it all, I need CDSA and/or PGP, or something, to do the key
management stuff. I've got access to the PGP(.com) SDK, but what's Cocoa
there seems pretty limited, (or so powerful its scope eludes me :-)), and
what's Carbon there is, well obscured, in the name of some well-earned
profitability on their part, though the headers are all open-kimono. I
think. If I knew how to read them with a straight face.
For link-level stuff, I think that SSL/TLS or SSH will do, 'cause it's out
there already. But since the underwriters are their own kind of
"certificate authority", by definition, with their own webs of trust, etc.,
with their own certificate users, I'm not sure that the x.blabla hierarchy
stuff is all that's necessary, and, furthermore, the exchange protocol is
going to be its own kettle of fish, possibly, but hopefully not,
necessitating its own protocol, port number(s), and fun and games with the
IETF someday. Or not...
The point is, for a 0.X level pass at this, all this stuff is laying around
either in various Developer directories, or out on the net for free. Kewl.
Now if I can acquire enough clues to cobble it all together and keep
various people from busting out laughing at the same time.
There. That's what I'm trying to do. You had to ask, didn'tcha? :-)
Cheers,
RAH
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.5.2 (Build 4075)
wj8DBQFFhfrhw/EfyN/eiFoRAg7WAJ9ZGN7sEnzp6PowZPHtMM4Pexu0tgCfQ5rh
1Fu0NW+24DwvRbNrOEbk7dY=
=IEjY
-----END PGP SIGNATURE-----
--
-----------------
R. A. Hettinga
participants (1)
-
R.A. Hettinga