Base64: Type 19 text files vs. Type 18 hashed files

[Scott Johnston]

I'm working on a little project to move base64 encrypted records from a type 19 to a type 18 for a variety of reasons. The original designer went with type 19 files because, he was wary the type 18 wouldn't work properly with type 18. I have tested type 18 again the type 19 in a one-to-one comparison and I do not see any issues. 

Has anyone ever encountered issues with encrypting type 18 file data?

[Kevin Powick]

Hi Scott,

On Thursday, 19 April 2012 16:20:22 UTC-4, Scott Johnston wrote:

 

Has anyone ever encountered issues with encrypting type 18 file data?

Base64 is not an encryption method.  It is an encoding method, most often used to represent binary data in an ASCII string. 

That may not really matter when it comes to your question, but do  not mistake data encoded as Base64 as having any cryptographically secure properties.  At best, it can be used as a form of obfuscation.

Further info: http://en.wikipedia.org/wiki/Base64

--

Kevin Powick 

[Symeon Breen]

Base64 is an encoding (not encryption) that represents data as basic a-z,A-Z,0-9,- and = characters so it should save well in any type of MV file.

--
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

---

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1424 / Virus Database: 2411/4946 - Release Date: 04/19/12

[Scott Johnston]

Tomato, ToMAAto...  the doc uses both terminologies..

ENCRYPT function

Syntax

ENCRYPT(algorithm, action, data, dataLoc,key, keyLoc, keyAction, salt, IV, result, resultLoc)

Description

The ENCRYPT() function performs symmetric encryption operations. Various block and stream symmetric ciphers can be called through this function. The supported ciphers are listed below.

Ciphers are specified by algorithm and are not case sensitive. Base64 encoding and decoding can be specified with the action parameter. If encoding is specified, the encrypted data is Base64 encoded before being entered into result. If decoding is specified, the data is Base64 decoded before being encrypted. The data and its location are specified by data and dataLoc, respectively. Key can be explicitly specified or read from a file, or, alternatively, derived on the fly, specified by keyAction, in which case the key string is used as a pass phrase to derive the actual key. The encrypted or decrypted data is put into the dynamic array result, or a file, as specified by resultLoc.

Either way, I have not found any reason why it has to be a type 19 sequential file as opposed to a type 18 hashed file.   I am asking if anyone has had any experience or issues doing this.  I am not worrying about semantics.

On Friday, April 20, 2012 5:29:24 AM UTC-4, Symeon Breen wrote:

Base64 is an encoding (not encryption) that represents data as basic a-z,A-Z,0-9,- and = characters so it should save well in any type of MV file.

 

 

 

 

From: mvd...@googlegroups.com [mailto:mvdbms@googlegroups.com] On Behalf Of Scott Johnston
Sent: 19 April 2012 21:20
To: mvd...@googlegroups.com
Subject: [mvdbms] Base64: Type 19 text files vs. Type 18 hashed files

 

I'm working on a little project to move base64 encrypted records from a type 19 to a type 18 for a variety of reasons. The original designer went with type 19 files because, he was wary the type 18 wouldn't work properly with type 18. I have tested type 18 again the type 19 in a one-to-one comparison and I do not see any issues. 

 

Has anyone ever encountered issues with encrypting type 18 file data?

--
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+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

[Dan McGrath]

Definitely not Tomato, ToMAAto. Encryption and encoding are not interchange terms (eg, ASCII is encoding, AES256 is encryption). Our ENCRYPT function just happens to also support an encoding scheme.

Is there a specific problem you have with Type 18 files? The reasons for using Type 18 vs Type 19 shouldn't have anything to do the encoding of the data, but rather with how it is accessed (access required externally? Type 19) and the size & count of records (small number of large files: type 19, large number of smaller records: type 18).

[Symeon Breen]

Bases64 encoding text is just pure text and will not affect any type of uv file in any way – just as you can store “hello world” in any type of uv file so you can also store base64 encoded text, it is just text and will never have any @vm, or other delimiters in it.

 

 

 

From: mvd...@googlegroups.com [mailto:mvd...@googlegroups.com] On Behalf Of Scott Johnston
Sent: 23 April 2012 13:54
To: mvd...@googlegroups.com
Subject: Re: [mvdbms] Base64: Type 19 text files vs. Type 18 hashed files

 

Tomato, ToMAAto...  the doc uses both terminologies..

 

 

ENCRYPT function

Syntax

ENCRYPT(algorithm, action, data, dataLoc,key, keyLoc, keyAction, salt, IV, result, resultLoc)

Description

The ENCRYPT() function performs symmetric encryption operations. Various block and stream symmetric ciphers can be called through this function. The supported ciphers are listed below.

Ciphers are specified by algorithm and are not case sensitive. Base64 encoding and decoding can be specified with the action parameter. If encoding is specified, the encrypted data is Base64 encoded before being entered into result. If decoding is specified, the data is Base64 decoded before being encrypted. The data and its location are specified by data and dataLoc, respectively. Key can be explicitly specified or read from a file, or, alternatively, derived on the fly, specified by keyAction, in which case the key string is used as a pass phrase to derive the actual key. The encrypted or decrypted data is put into the dynamic array result, or a file, as specified by resultLoc.

 

 

Either way, I have not found any reason why it has to be a type 19 sequential file as opposed to a type 18 hashed file.   I am asking if anyone has had any experience or issues doing this.  I am not worrying about semantics.

On Friday, April 20, 2012 5:29:24 AM UTC-4, Symeon Breen wrote:

Base64 is an encoding (not encryption) that represents data as basic a-z,A-Z,0-9,- and = characters so it should save well in any type of MV file.

 

 

 

 

From: mvd...@googlegroups.com [mailto:mvd...@googlegroups.com] On Behalf Of Scott Johnston
Sent: 19 April 2012 21:20
To: mvd...@googlegroups.com
Subject: [mvdbms] Base64: Type 19 text files vs. Type 18 hashed files

 

I'm working on a little project to move base64 encrypted records from a type 19 to a type 18 for a variety of reasons. The original designer went with type 19 files because, he was wary the type 18 wouldn't work properly with type 18. I have tested type 18 again the type 19 in a one-to-one comparison and I do not see any issues. 

 

Has anyone ever encountered issues with encrypting type 18 file data?

--
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

---

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1424 / Virus Database: 2411/4946 - Release Date: 04/19/12

--

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

No virus found in this message.
Checked by AVG - www.avg.com

Version: 10.0.1424 / Virus Database: 2411/4953 - Release Date: 04/22/12

[Symeon Breen]

The reason ENCRYPT also includes a base64 encoding is because most encrypted text becomes a byte stream, and so it would be very dangerous to store the subsequent stream in a uv file as it would most certainly contain odd characters that are used as delimiters in uv files. If you base64 encode the encrypted string it is just plain ascii text and so can be safely stored as per any other string.

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

---

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1424 / Virus Database: 2411/4946 - Release Date: 04/19/12

--

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

No virus found in this message.
Checked by AVG - www.avg.com

[Scott Johnston]

That' exactly what my testing has supported.  This all came about because of PCI requirements. We are converting from a base64 type19 to a "token" type 18.  But in the scenarios where the tokenization system fails, we need a temporary place to store data.  But using a type19 has proved problematic during backups and restores.  While over file is admittedly to large from processes that I've looking into, we are not just "free to delete" any record as we deem necessary. Long story behind that.  

So the type19 has proven to take over 9 hours, (Yes, 9 hours) to restore.  We want to put the new temp file to a type18 but the original designer was reluctant to do that for whatever reason and made other paranoid about using an 18.  I'm looking to change that.  

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

---

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1424 / Virus Database: 2411/4946 - Release Date: 04/19/12

--
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+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

[Scott Johnston]

OH BTW thanks! :)