kamagra how much to take

Native Cryptography in SP Doc Libs and Lists (RSA WebPart Test)

Privacy is important, especially in a collaborative environment such as SharePoint where users are heavily empowered with actions that can directly effect sensitive files and file containers. The most typical way to protect privacy for file types is to implement a form of Multi-Level Access Control, and/or native encryption components that are easy for users to understand, ones that are perferably built directly into familiar toolsets such as Office (as is the case with IRM).

End to end encryption solutions aren’t a native thing to SharePoint (outside of WRM / IRM, which aren’t “native” in the sense in that they aren’t outright built into the product COTS, they require further configuration). Furthermore, there are a lot of side effects of going down a standard encryption road when examining a collaborative cryptographic solution, most we see when using IRM encryption envelopes. When I say standard road, I mean just using a client level encryption solution (something running on a user desktop), an arbitrary scramble method / encryption algorithm, by which I mean something like:

Symmetric Encryption

(Block and Stream Ciphers)

Asymmetric Encryption






Elliptic Curve Techniques


Paillier Cryptosystem




Vectors and Salts

and then re-upload the document to a document library whereby you are responsible for key maintenance between an unknown amount of parties. The most obvious problem that is spawned is encrypted content cannot be read by the SharePoint gatherer since it does not sponsor anything besides plain-text reads.

For my final paper for my Masters (I am doing my degree in Applied Mathematics / Cryptography) I received approval from my professor to move forward with creating /verifying an end-to-end cryptography solution that solves all these issues and stays within the native SharePoint framework. I am not sure how / what it will look like yet, how it will be invoked, or any of the architectural considerations of it yet. My only stipulation is that it is easy, and directly available from within the SharePoint interface.

The aggregate objective of the solution, eventually (this is probably down the road a little bit), is to exhibit the feasibility of extending a native Microsoft Windows Server operating system and Microsoft Office SharePoint Server (MOSS) environment such that it enhances global security of federal Multi-Level Security (MLS) systems which are historically built on the Bell-LaPueda model. This technique should eventually leverage a lattice MAC (Mandatory Access Control) based Multi-Policy Access Control (MACM) object labeling controls regulated by comprehensive security policy implementation. The standard notion of Discretionary Access Controls (DAC) that the Microsoft Server System currently provides are incontestably bound to native Windows Identities, allowing users management of individual objects, expressed as P=SxOxA where s translates to the subject, O to an arbitrary set of objects, and A to access modes. Use MAC MACM this instead promotes M=(S,O,A,SA,f,R), such that S is the set of subjects, O is the set of objects, A is the access mode set when a subject accesses object: SxO {, {r},{w},{e},{a},…..}, SA is the security attribute, f is the security functions, R is the set of security rules that prescribe the constraints conditions of how subjects access objects. Using this model, it is possible to procure the federal notion of no-read-up and no-write-down.

The security attribute can be defined in tuple format: SA={L,A} such that: L is the security level of an entity, denoting the security right of the entity. Different security levels are comparable. Defining “” is a partially ordered on the set of the security level, if the security level of entity i ()

This promotes a new-read-up rule denoting that a subject s S is granted read access to object o iff f(o) f(s). No write-down rule denotes that a subject s S is granted write access to object o iff f(s) (f(o)

I started toying with the idea last night, just working with getting an RSA encryption engine to take a sample plain text string in a TextBox child control. Most importantly I spent some time building some foundational abstract base classes to provide a Multiple-precision shared library (for for multiple-precision floating-point computations) and a Barrett modular reduction library to implement Barrett’s Modular Reduction Method for RSA . Although the encryption exponent is pretty tiny for the test, the plain text conversion for my shared components was successful, however this is only 10% of the battle obviously (I was mainly interested in the web basd encryption performance, I would like to eventually integrate instruction level parallelism). What I plan on ultimately doing is building this concept into a complete multi-level system with the native encryption components. In aggregate, the solution should facilitate Enterprise Content Management (ECM) and Team Virtualization (eTV) using Microsoft technologies as the institutional foundation using partitioned layers of classification as well as native encryption features. The purpose of the encryption functions with Microsoft Office Server System will be to provide practical applied cryptographic functions (again, taking into account instruction level parallelism and memory bandwidth) while maintaining the two most important concepts to cryptography, privacy and correctness. Below is my example SharePoint WebPart that I have been playing around with.

(Select Image To Expand)

I started to push the data back and forth between list items and as I expected, the universal issue of not gathering encrypted items was encountered. I am pretty sure I can get around this with floated carrying key tokens however, so that the gatherer will basically have a Skelton key to the documents that it wishes to implement full-text indexing against, which although will need to be looked at for security vulnerabilities, is really the only feasible solution that comes to mind. I think for most organizations, this will be a good solution. Although I was just pushing the data back and further programmatically, I plan on making the encryption option a item-level context menu or something along those lines.

As always, good security software is always open-source. When this project (which, for the paper / research thesis is taking on the name CryptoCollaboration) becomes production and has been somewhat tested for my grading, it will be released to the public open at no cost, probably under a GNU license.



  1. Andy says:

    Interesting. I’d been kicking around a similar idea for a brief while for a tender I’d been asked to look at. The problem that I saw was, though, if you let your document be indexed, then it can leak information through that index. For example, if I searched for “Andy redundancy” and found an encrypted document, well, I might have an idea what this was about…

    Now, SharePoint 2007 does have search result trimming – but you’re then back to relying on SharePoints ACLs. Compromise of those, and then you might leak data through your search index. Obviously, less than the unencrypted document – but it does reduce the benefits.

    Unless I’ve misunderstood the whole thing, and am talking out my ass.

  2. Adam Buenz says:

    No, you got the basic idea I think of what I am trying to do, and the difficulties of what I am facing. The problem that you are describing in terms of search is one that I haven’t totally got the idea for tackling yet, and it is indeed very conceptual. “I want to search on such parameter, and I want parameters to populate that return, but people can’t know about it”. It is quite contrary, no? It gets even worse when you consider exposing things like the description managed property in the results.

    I will continue to post updates of how the solution is going to work as I make more progress on my research!

  3. Saravanan says:

    hi Adam,
    I like your thought and i am also looking for the same set of solution.
    I am also using SP to upload the documents, but we need some set of encription on the doc before it get upload.

  4. Craig Mankiewicz says:

    Hello, the article looks to be dated back in 2007. Did anything get finished on this project by chance?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>