[cap-talk] Last Call for ref_send API 1.0

[Bill Frantz]

daw at cs.berkeley.edu (David Wagner) on Wednesday, April 4, 2007 wrote:

>Tyler Close writes:
>>> Record: The Javadoc calls this "A pass-by-construction object.", but
>>> I think you mean "An allegedly pass-by-construction object."
>>
>>The above statements are correct, but they're also correct for all
>>interfaces that are not the special org.joe_e.* verified interfaces.
>>Do we want to adopt the "allegedly" convention when documenting all
>>Joe-E interfaces?
>
>Oh.  Good question.  I don't know.  Now that you mention it, of course
>it has to be implicit that they can only be "alleged", given that they
>are interfaces which anyone can implement.  Duh.  I don't know how I
>missed that.  Is it worthwhile to remind people of this explicitly?
>I don't know and I don't have any strong opinions.

In KeyKOS, we used "alleged type", rather than "type" to emphasize that
what was being returned was not authoritative.  Does the JoeE verifier
verify "pass-by-construction"?  If there is no verification, then
including alleged might be useful.


>>> I don't understand what ready() is doing, or what is meant by
>>> "the underlying reference implementation".  What is a "reference
>>> implementation"?  Does it mean some sample implementation that the
>>> ref-send library provides?
>>
>>Yes. An eventual reference is just a Java proxy wrapped around one of
>>the reference implementations documented in org.ref_send.promise. To
>>register a when block on the reference, you need to peel off the Java
>>proxy to get at the underlying reference implementation. The ready()
>>method implements this peeling. The return is guaranteed to be
>>anything. I named this method "ready" so that the line:
>>
>>    x = foo_.bar();
>>    _.when(ready(x), new Do...
>>
>>would read as "when x is ready, do ...", meaning when the bar()
>>invocation has been completed, do the following on its return value.
>>I'll try to come up with better Javadoc for this method.
>
>Ok.  Got it.
>
>The phrase "reference implementation" could also be parsed as
>"an implementation of a reference (e.g., a reference to an object)";
>given that Promises are kinda like references, there may be a potential

When I hear "reference implementation", I think of an implementation
which isn't suited to real work, but may be useful as a worked example
for standardizers or implementors.  For example, the first reference
implementation of Ada was implemented in one of the Lisp family of
languages.  It was updated after every standards meeting to include the
results of that meeting.  As such, it was quite useful to the standards
process, but as a friend who worked on it said, "As an interpreter
running an interpreter, it's only suitable for real-time simulation of
paper and pencil calculations."


>>If you've got a pure Joe-E implementation of AES, I'll gladly use it
>>and deprecate this API. Otherwise, I need this API to safely wrap the
>>javax.crypto implementation.
>
>Not laying around, but there are pure-Java implementations of AES,
>and I'd expect they ought to be easy to make Joe-E compliant, but I'm
>too lazy to do it myself.  I don't know how well they perform.  I don't
>see any problem with having this interface.  I guess if I don't care
>enough to spend the hour to download and build a pure Joe-E implementation,
>obviously I must not care very much at all!

One of the items NIST required from each AES candidate was a Java
implementation.  I found a zip file of an implementation designed to
work with Cryptix on this page:
<http://www.iaik.tu-graz.ac.at/research/krypto/AES/old/%7Erijmen/
rijndael/>.

Cheers - Bill



-------------------------------------------------------------------------
Bill Frantz        | The first thing you need when  | Periwinkle
(408)356-8506      | using a perimeter defense is a | 16345 Englewood Ave
www.pwpconsult.com | perimeter.                     | Los Gatos, CA 95032