ARGON cryptography (by alaric)

I thought I'd like to discuss the design decisions behind the rather brief description of the "security levels" mentioned on the MERCURY page. Don't worry, you don't need to go and read it first - I'll duplicate everything in this post.

To summarise, my design requirement was to implement a cryptograhic architecture for both communications and storage of sensitive data, which allows for:

1. Both parties in a communication may have differing security requirements; the maximum of both need to be met
2. Security levels need to be specified in a way that is future proof; eg, DES would have been unbreakable in World War II, but nowadays it should only be considered suitable for relatively unimportant data
3. Physical communications links may have a certain element of external protection, rendering encryption an unnecessary burden; a cluster of servers locked in a highly screened server room together should be able to communicate sensitive data between each other in the clear, or with a fast lightweight encryption algorithm - after all, an assailant in the room with them could easily interfere with the machines themselves to get them to divulge their keys. However, the same information being shared across the public Internet would need heavy encryption, or be banned altogether.

4. Communications links and data storage devices might have a maximum security level of information they can be trusted to at all, no matter how heavily encrypted it is, because any crypto algorithm is potentially breakable.

   Read more »

Protocol agnostic middleware (by alaric)

It strikes me that perhaps one of the reasons that middleware hasn't taken the world by storm is that middleware tends to require some inconvenient protocol to access it.

Even the Web Services folks with SOAP and friends don't seem to have changed the world much, for all the effort of choosing a protocol that clients can be knocked up for easily from scratch in most environments.

However, in my work for Frontwire, I've ended up creating a server that does things in response to:

• Java RMI calls
• Work for it to do being directly inserted into an SQL database
• Scheduled events
• HTTP requests
• Incoming emails
• FTP uploads

What does that tell us about currently available middleware "solutions"? Read more »

CPU scheduling (by alaric)

I came across the original paper on Lottery Scheduling.

What was all the fuss about? All it boils down to is using a weighting assigned to each process to divide time between CPU-bound processes at the same priority level. Back when I was a kid and wrote my first preemptive multitasking kernel, that's what I did, because being a lame MS-DOS programmer I hadn't thought of blocked processes being removed from the run queue, and I thought that 'priority' must be such a weighting.

Anyway, it got me thinking. Lottery scheduling is fine for long-running non-real-time processes at the same priority. A user running a few background computational tools such as distributed.net and SETI@Home would benefit from being able to choose the balance between the two at will, sure. But for event-driven tasks like a GUI frontend, a classic priority scheme would still win, if people bothered to set the priorities correctly. As it stands, unless they explicitly make a process 'nice', they usually just leave it to the OS to dynamically assign priority based upon the processes' I/O behaviour, using adaptive heuristics that take a while to respond to changes in the behaviour anyway.

And the inefficincies of this approach are often seen when some heavyweight background computation causes your GUI to become unresponsive... Read more »

plasticbag.org | weblog | The New Musical Functionality: Portability and access (by alaric)

plasticbag.org | weblog | The New Musical Functionality: Portability and access

My take on all this is that portable music, mobile phones, and PDAs and so on will inevitably converge into a general purpose portable computer.

On the desktop, general purpose PCs do everything; even the humble desk telephone is finally being subsumed by the PC with VoIP, a process that started in the 1990s but was somewhat humbled by the cost of a voice modem on every machine over a standard telephone not being sufficiently counterbalanced by advantages.

And I hate having too many pocket gadgets to carry around that (shudder) all need plugging in to recharge. Now that people are used to mastering the complexities of a general purpose computer on their desktop, I don't see any reason why a general purpose pocket computer, that (via some combination of inbuilt facilities and tiny plugin modules) can contact a mobile telecommunications network, send digital audio to your ear, and store lots of data. Read more »