Both of those have different security concerns. I personally use the
temp file approach.
-Nathan
--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms
-- Glen B
Hi all,
Since QM got mentioned in an early posting on this thread, let me answer the question as it applies to QM even though the thread seems to be more concerned with D3.
QM provides three levels of AES 128, 192 or 256 bit encryption; entire record, selected fields and ad-hoc data items.
Record level encryption, used only internally in hashed files, may result in any character values. Since you can never see the encrypted form, nothing should care about the fact that this might contain characters outside the first 251.
Field level encryption, also only used internally, performs an additional data transformation to ensure that the encrypted values can never contain characters from the C0 set ( 0 to 31) or the mark characters. The latter rule is required so that we can still find the marks when extracting fields, values or subvalues.
Ad-hoc encryption, probably closest to what this thread seems to be discussing, uses the ENCRYPT() and DECRYPT() functions which allow encryption to be applied to any desired piece of data, whether or not it is part of a data record. This uses the same additional transformation as field level encryption and it is here that elimination of the C0 characters becomes important as it allows the data to be written into files that use, for example, newlines.
Incidentally, since the topic came up, QM also has Base64 encoding as a built-in conversion code.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200
It encrypts whatever you give it: field or record and protects the integrity of the segment mark. everything else comes back in the decrypt.
If I told you the algorithm, it wouldn't be much of a secret, would it.
I added this to Pick back when it WAS Pick, but it was never advertised. While with Pick, I published a list of these "hidden" features on CDP. If anyone has a copy feel free to re-post.
Mark Brown
It encrypts whatever you give it: field or record and protects the integrity of the segment mark. everything else comes back in the decrypt.
If I told you the algorithm, it wouldn't be much of a secret, would it.
With all due respect – I’m sure your algorithm is great – this might be a problem for the OP. Auditors, clients ..etc may require that data encryption be done using a known mechanism (eg AES ..etc), where the algorithm has been published, and subjected to significant analysis. The notion of ‘security through obscurity’ might be a difficult sell. I do understand that this might not be a released/public feature.
Mark Brown wrote:If I told you the algorithm, it wouldn't be much of a secret, would it.
...this might be a problem for the OP. Auditors, clients ..etc may require ...
Well, excuse me.
>
>
> Well, excuse me.
>
No, no, no. It goes, "Well excuuuuuuuuuse me!"
*laughs*
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
Buying desktop hardware and installing a server OS doesn't make a
server-class system any more than sitting in a puddle makes you a duck.
[Cipher in a.s.r]