Operating System - OpenVMS
1748232 Members
3521 Online
108759 Solutions
New Discussion юеВ

Re: RMS field encryption

 
SOLVED
Go to solution
Kelly Cox
Frequent Advisor

RMS field encryption

Can I call any of the VMS DES encryption routines from within VMS C programming just to encrypt/decrypt a single field in an RMS file?

Or does anyone have a better suggestion for strong encryption at the field level?

I've tried searching ITRC and not found anything yet.
9 REPLIES 9
Hoff
Honored Contributor

Re: RMS field encryption

I don't know how much you know about this topic, and I do know that it's wicked easy to get encryption wrong.

The OpenVMS encryption software doesn't particularly care what sort of data you hand it, and RMS doesn't care what's in an individual record. It's all a wad of bytes.

You probably won't want to encrypt the key field if this is an indexed file, obviously. That Would Be Bad.

Encrypted data can also vary in length, depending on exactly what you're up to; I would plan on eventually encountering records of different lengths. If not sooner.

DES has been supplanted by AES (or better), and both DES and AES are available in current OpenVMS releases. For the current stuff, see:

http://h71000.www7.hp.com/doc/83final/ba554_90006/ch05s04.html#aesexample

I'm professionally skeptical around encryption implemented within most applications; all too often it's added into an application like magic pixie dust or an RFC checkbox requirement. It's present, but the implementation can be somewhere between problematic and leaky and easily compromised and entirely wrong.

Some folks that created AES-encrypted keydisks had an implementation bug that completely subverted their entire design, for instance.

So. What are you storing? Some sort of password? If so, that's usually not encrypted.
Kelly Cox
Frequent Advisor

Re: RMS field encryption

I don't know much about encryption, except that I want to use a stable library. I've used a simple replacement and hash in the past. This is not a key field and is only stored for a short time, usually less than 24 hours. If it goes overnight though it will be backed up and is then VERY suspect and needs better encryption.

It can't be permanently hashed as it must be easily readable.

I 'think' i'm looking for a PKE library that is available on VMS or easily adapted to VMS. I primarly use standard VMS C compiler.

If I can call the current AES routines for encrypt and decrypt that should work.
Jim_McKinney
Honored Contributor
Solution

Re: RMS field encryption

Take a look at SYS$COMMON:[SYSHLP.EXAMPLES.SSL]SSL$AES.C - it should get you started.
Robert Gezelter
Honored Contributor

Re: RMS field encryption

Kelly,

The encryption algorithm is only half the battle. It is also critical to use a good key that is properly controlled and changed appropriately.

I agree with Hoff. Encryption is far from "magic pixie dust". It takes little in errors and mistakes to render the best encryption useless.

As an example, there are some entertaining published reports on early web browsers that used the process ID as part of the "random" key. Unfortunately, these desktop systems had very short uptimes, so there were large numbers of high-order zero bits in the process ID and other predictable fields (see "Randomness and the Netscape Browser" by Ian Goldberg and David Wagner from the January 1996 Dr. Dobb's Journal; available at: http://www.eecs.berkeley.edu/~daw/papers/ddj-netscape.html ).

Encryption is only as good as the weakest of all of its parts.

- Bob Gezelter, http://www.rlgsc.com
Hoff
Honored Contributor

Re: RMS field encryption

The NIST web page for AES has a pointer over to some of the Rijndael source code in C. I haven't reviewed the code, but I'd tend to expect it is solid given it's being linked from the NIST site.

Without a systematic approach around the attackers and the defenses and key management and the whole rest of the chain that gets involved here and not the least of which is the value of the target, even the best brute-force encryption tends to fail.

Data security is completely flipped around from the usual software design and coding requirements and practices, too; the code is often a target of review and of intentional attacks, and various of these attacks are incredibly clever.
Guy Peleg
Respected Contributor

Re: RMS field encryption

I think encryption is easy to do.

Either encrypt record by record or create
the file and then use the OpenVMS encrypt
utility to encrypt the entire file.

Guy Peleg
Maklee Engineering
www.maklee.com

Hoff
Honored Contributor

Re: RMS field encryption

Yes. In isolation, encryption is easy. Trivial, even. Correct and reliable encryption for a particular case or a particular task? Not so much. The case that Mr Cox is working with? Definitely not easy.

That this stuff is so easy to implement and so easy to get wrong is how it so often ends up implemented like magic pixie dust, and (if the vendor is particularly unlucky) with the vendor then featured on the front page of FailBlog.
Robert Gezelter
Honored Contributor

Re: RMS field encryption

With all due respect, I must wholeheartedly concur with Hoff's last comment.

The analysis of the Netscape incident that I cited in my earlier posting in this thread is a good read.

Encryption is not merely the process of calling a routine to "encrypt/decrypt" a buffer. Design of cryptographic algorithms is a very technical affair, so the algorithms are generally standardized.

This leaves the choice of keys. No matter how good your algorithm, if the keys are predictable (or parts of the key are predictable, as in the Netscape case from 1996), then the encrypted text can be decoded by a brute force attack.

- Bob Gezelter, http://www.rlgsc.com
Kelly Cox
Frequent Advisor

Re: RMS field encryption

Thanks for all the advice, I was able to accomplish my goals without using local storage.