Re: "Information-Hiding" in Crypto Programs
Tim about raising the programming language level for crypto applications. He Orients toward Objects...
I'm not saying _how_ they would help, just that my intuition is that the crypto community could make new strides if the imperative style of programming ("do this," "now do this," etc.) were to be supplemented with the descriptive style ("this is a digital cash object and these are the messages it understands") and even the logical style (of Prolog, for example).
There are a couple different issues you could hide in a language for crypto. Obviously you can abstract bignums, numbers with a modulus, matrices, ...mathematical objects, and that would get a lot of cobwebs out of the way in many crypto algorithms. Even a Bignum Basic that could do fast modmult would be nice. Or you could make objects out of the data structures, like keys, message blocks, key rings, etc., and their operations. That would be nice because you could separate the layer of calculation from the layer of protocol. But the protocol programming would still be in an imperative style. Which has its good points. I do a lot of work in a scripting language that has procedures and lists and strings and that's about it. But the rules are understandable and it ends up the language is *readable* in the sense that you can look at a procedure and get a good idea of what it's doing without stretching your concepts too much. Which I think would be a good feature for a crypto language, especially one for experimentation, teaching and tossing ideas around. I think the language I work in gets readability by its plodding, structured-programming, imperative style (it also uses plodding long names for things). But of course protocols and transactions are big things in crypto, and they take place in time, which leads to thoughts about special control structures to handle them. Structures in time are actually one of the nifty things to implement with objects. You can have an object that stands for a whole conversation in a protocol--sort of like a file handle. So you have operations like (in no particular language): conversation = Protocol.new( some parameters ); conversation.send( message ); conversation.receive( message ); conversation.end(); You can also use objects to implement protocol layers, like: conversation0 = Protocol0.new( ... ); conversation1 = Protocol1.new( conversation0, ... ); conversation1.send( message ); ... (Some amazing things can be done with operations on objects that represent sequences in time. In the book _The Structure and Interpretation of Computer Programs_, one chapter develops a Prolog interpreter as a bunch of layered stream filters. Oops, I digress.) Another area you might want to separate out of the heart of crypto programs is I/O, both with the user and with the rest of the system--the mail system, for instance. -fnerd - - - - - - - - - - - - - - - Gradually, I become aware of a presence. Between me and sustenance stands a woman in a suit. --Michael Swaine -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----
participants (1)
-
fnerd@smds.com