encryption function in version 5.6 on SCO OSR5

Bruce Easton bruce at stn.com
Wed Dec 22 16:49:11 PST 2010


I have been trying out the encryption functions in version 5.6.  Using a
couple of screens, a small customer file, a control file (to simulate 
access
to key values), and an input table of about 30 lines for the customer file,
I've created a small application that will capture amongst other things,
SS# and CC#.  For these two fields I encrypt, then store them when
adding a record.  For viewing the record from clerk these fields can only
be viewed in a masked unencrypted form (using dummy fields).  I also
provided a way for the operator to update these fields, but they must
enter the correct admin password via inputpw popup to switch screens
and gain access to these fields again for update.

All of this works fine I think.  Well, I should say that the interface is
working the way I had intended. What I am curious about is the
use and results of the encryption function.  Here is what I don't
understand:

If I follow the example in the online manual, but substitute the method
with "AES" and use a constant 16-char key, and do not supply a
nonce value, and after F8 is pressed show also the value of the
nonce supplied by clerk via getnonce(), I get a different nonce value
each time I press F8 - and this it while I am in update mode in the
field to be encrypted - all on the same record during the same
update session.  This did not surprise me as the documentation
states  [under "GETNONCE()"]:
---
     After a call to ENCRYPT(), you can call GETNONCE() to get
     the "nonce" that was used.[..]

     If "nonce" is not specified, filePro generates one.
---
What surprised me was when I called encrypt() and then getnonce()
twice while saving a record (when operator keys ESC ESC):

Then 6=encrypt(ea,"AES",kkk(1)); 4=getnonce()
Then 7=encrypt(eb,"AES",kkk(2)); 5=getnonce()

(to encrypt both SS & CC numbers).  In this case,
the nonce values generated and stored into fields 4 and 5
were identical.  I'm sure if I need to I can use various things
to further randomize subsequent nonces, but is this
correct behavior for filepro to generate only one nonce
value here after another encrypt function has been called?

The documentation goes on to say that "Many consider it
important to use a unique nonce with each piece of data
encrypted."  I've not done this, so with regard to that
statement and in consideration of the latter behavior I
described above, I'm wondering if it sufficient to use
a single nonce value for all fields to be encrypted
within one record, or if you should have a separate
nonce value for each field.

Maybe some clarity would help others trying to use these
functions.  That is:

1.  exactly what conditions trigger a new nonce
value to be created by clerk, and

2.  is it recommended that a new nonce
value be used with each field in each record that
is to be encrypted or is it sufficient to just get a
new value for each record.

Bruce

Bruce Easton
STN, Inc.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20101222/291e3350/attachment.html 


More information about the Filepro-list mailing list