Given an m x m image I and a smaller n x n image P, the computation of an (m

We investigate the outsourcing of numerical and scientific computations using the following framework: A customer who needs computations done but lacks the computational resources (computing power, appropriate software, or programming expertise) to do these locally, would like to use an external agent to perform these computations.  This currently arises in many practical situations, including the financial services and petroleum services industries.  The outsourcing is secure if it is done without revealing to the external agent either the actual data or the actual answer to the computations.  THe general idea is for the customer to do some carefully designed local preprocessing (disguising) of the problem and/or data before sending it to the agent, and also some local postprocessing of the answer returned to extract the truse answer.  The disguise process should be as lightweight as possible, e.g., take time proportional to the size of the input and answer.  The disguise preprocessing that that the customer performs locally to “hide” the real computation can change the numerical properties of the computational performanc.  We present a framewrok for disguising scientific copmutations and discuss their costs, numerical properties, and levels of security.  These disguise techniques can be embedded in a very high level, easy-to-use system (problem solving environment) that hides their complexity.

We give a Monte Carlo algorithm that computes an unbiased estimate of the convolution of two vectors. The variance of our estimate is small for entries of the convolution that are large; this corresponds to the situation in which convolution is used in pattern matching or template matching, where one is only interested in the largest entries of the resulting convolution vector. Experiments performed with our algorithm confirm the theory and suggest that, in contexts where one cares about only the large entries in the convolution, the algorithm can be a faster alternative to performing an FFT-based convolution.

The outsourcing of numerical and scientific computations, as introduced in (Atallah et al., 2001) uses the following framework: A customer needs computations done but lacks the computational resources (computing power, appropriate software, or programming expertise) to do these locally.  An external agent can do these computations.  The outsourcing is secure if it is done without revealing to the external agent either the actual data or the actual answer to the computations.  The idea is for the customer to do some carefully designed local preprocessing (disguising) of the problem and/or data before sending it to the agent, and also some local postprocessing (unveiling) of the answer returned to extract the true answer.  In this paper we extend this concept to the case of more than one customer, introducing the notion of mutually secure outsourcing where two or more parties contribute their private data into the (disguised) common computation performed through the external agent; the customers are to know the result but not each other’s private data, and the external agent should know neither the provate data nor the result.  We review the framework for disguising scientific computations and discuss their applicability, costs, and levels of security.  We also introduce techniques for the disguise of programs in general, not just those for scientific computations.

This paper describes our practical experiences in setting and working with requirements for a piece of security software.  Principally, it discusses the conflicts that occurred between the ease of putting the initial requirements on paper and the difficulty in applying them. The requirements were not formally specified, but the process of turning them into code followed our standard software development process.  However, the informality of the requirements was not the primary source of our conflicts; we believe that ambiguity always exists, ambiguity leads to assumptions, and assumptions are what lead to flaws—some of which may cause security vulnerabilities.

By explaining our journey through the software development process, we show how seemingly obvious and easily stated requirements lead to ambiguity, choices, and the need for revisiting specifications throughout the process.  We conclude with some recommendations from our experiences that we hope will be useful to other practitioners.