Numeric (0-9)
The Numeric token type tokenizes digits from 0 to 9.
Table: Numeric Tokenization Type properties
| Tokenization Type Properties | Settings | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Name | Numeric | |||||||||||||||
Token type and Format | Digits 0 through 9 | |||||||||||||||
| Tokenizer | Length Preservation | Allow Short Data | Minimum Length | Maximum Length | ||||||||||||
SLT_1_3 SLT_2_3 | Yes | Yes | 1 | 4096 | ||||||||||||
No, return input as it is | 3 | |||||||||||||||
No, generate error | ||||||||||||||||
No | NA | 1 | 3933 | |||||||||||||
SLT_1_6 SLT_2_6 | Yes | Yes | 1 | 4096 | ||||||||||||
No, return input as it is | 6 | |||||||||||||||
No, generate error | ||||||||||||||||
No | NA | 1 | 3933 | |||||||||||||
Possibility to set Minimum/ maximum length | No | |||||||||||||||
Left/Right settings | Yes | |||||||||||||||
Internal IV | Yes, if Left/Right settings are non-zero | |||||||||||||||
External IV | Yes | |||||||||||||||
Return of Protected value | Yes | |||||||||||||||
Token specific properties | None | |||||||||||||||
The following table lists the examples of numeric tokenization values.
Table: Examples of Numeric tokenization values
| Input Value | Tokenized Value | Comments |
|---|---|---|
| 123 | 977 | Numeric, SLT_1_3, Left=0, Right=0, Length Preservation=Yes The value has minimum length for SLT_1_3 tokenizer. |
| 1 | 555241 | Numeric, SLT_1_6, Left=0, Right=0, Length Preservation=No The value is padded up to 6 characters which is minimum length for SLT_1_6 tokenizer. |
| -7634.119 | -4306.861 | Numeric, SLT_1_3, Left=0, Right=0, Length Preservation=Yes Decimal point and sign are treated as delimiters and not tokenized. |
| 12+38=50 | 98+24=62 | Numeric, SLT_2_6, Left=0, Right=0, Length Preservation=Yes Arithmetic signs are treated as delimiters and not tokenized. |
| 704-BBJ | 134-BBJ | Numeric, SLT_1_3, Left=0, Right=0, Length Preservation=Yes Alpha characters are treated as delimiters and not tokenized. |
| 704-BBJ | Error. Input too short. | Numeric, SLT_2_6, Left=0, Right=0, Length Preservation=Yes, Allow Short Data=No, generate error Input value has only three numeric characters to tokenize, which is short for SLT_2_6 tokenizer when Length Preservation=Yes and Allow Short Data=No, generate error. |
| 704-BBJ 704356 | 704-BBJ 134432 | Numeric, SLT_2_6, Left=0, Right=0, Length Preservation=Yes, Allow Short Data=No, return input as it is If the input value has less than six characters to tokenize, then it is returned as is else it is tokenized. |
| 704-BBJ | 134-BBJ | Numeric, SLT_2_6, Left=0, Right=0, Length Preservation=Yes, Allow Short Data=Yes Input value has three numeric characters to tokenize, which meets minimum length requirement for SLT_2_6 tokenizer when Length Preservation=Yes and Allow Short Data=Yes. |
| 704 | 134 | Numeric, SLT_1_3, Left=0, Right=0, Length Preservation=Yes, Allow Short Data=No, return input as it is If the input value has less than three characters to tokenize, then it is returned as is else it is tokenized. |
| 704-BBJ | 669-BBJ642 | Numeric, SLT_1_6, Left=0, Right=0, Length Preservation=No Input value is padded up to 6 characters because Length Preservation=No. Alpha characters are treated as delimiters and not tokenized. |
| 704-BBJ | 764-6BBJ | Numeric, SLT_2_3, Left=1, Right=3, Length Preservation=No 1 character from left and 3 from right are left in clear. Two numeric characters left for tokenization “04” were padded and tokenized as “646”. |
Numeric Tokenization Properties for different protectors
Application Protector
The following table shows supported input data types for Application protectors with the Numeric token.
Table: Supported input data types for Application protectors with Numeric token
| Application Protectors*2 | AP Java*1 | AP Python |
|---|---|---|
| Supported input data types | STRING CHAR[] BYTE[] | STRING BYTES |
*1 - The API accepts and returns data in BYTE[] format. The customer application needs to convert the input into byte arrays before calling the API, and similarly, convert the output from byte arrays after receiving the response from the API.
*2 - The Protegrity Application Protector only supports bytes converted from the string data type. If any other data type is directly converted to bytes and passed as input to the Application Protectors APIs that support byte as input and provide byte as output, then data corruption might occur.
For more information about Application protectors, refer to Application Protector.
Big Data Protector
Protegrity supports MapReduce, Hive, Pig, HBase, Spark, and Impala, which utilizes Hadoop Distributed File System (HDFS) or Ozone as the data storage layer. The data is protected from internal and external threats, and users and business processes can continue to utilize the secured data. Protegrity protects data inside the files using tokenization and strong encryption protection methods.
The following table shows supported input data types for Big Data protectors with the Numeric token.
Table: Supported input data types for Big Data protectors with Numeric token
| Big Data Protectors | MapReduce*2 | Hive | Pig | HBase*2 | Impala | Spark*2 | Spark SQL | Trino |
|---|---|---|---|---|---|---|---|---|
| Supported input data types*1 | BYTE[] | CHAR*3 STRING | CHARARRAY | BYTE[] | STRING | BYTE[] STRING | STRING | VARCHAR |
*1 – If the input and output types of the API are BYTE[], then the customer application should convert the input to and output from the byte array, before calling the API.
*2 – The Protegrity MapReduce protector, HBase coprocessor, and Spark protector only support bytes converted from the string data type. Data types that are not bytes converted from the string data type might cause data corruption to occur when:
- Any other data type is directly converted to bytes and passed as input to the MapReduce or Spark API that supports byte as input and provides byte as output.
- Any other data type is directly converted to bytes and inserted in an HBase table. Where the HBase table is configured with the Protegrity HBase coprocessor.
*3 – If you are using the Char tokenization UDFs in Hive, then ensure that the data elements have length preservation selected. In Char tokenization UDFs, using data elements without length preservation selected, is not supported.
For more information about Big Data protectors, refer to Big Data Protector.
Data Warehouse Protector
The Protegrity Data Warehouse Protector is an advanced security solution designed to protect sensitive data at the column level. This enables you to secure your data, while still permitting access to authorized users. Additionally, the Data Warehouse Protector integrates seamlessly with existing database systems using the User-Defined Functions for an enhanced security. Protegrity protects data inside the data warehouses using various tokenization and encryption methods.
The following table shows the supported input data types for the Teradata protector with the Numeric token.
Table: Supported input data types for Data Warehouse protectors with Numeric token
| Data Warehouse Protectors | Teradata |
|---|---|
| Supported input data types | VARCHAR LATIN |
For more information about Data Warehouse protectors, refer to Data Warehouse Protector.
Database Protectors
The following table shows supported input data types for Database protectors with the Numeric token.
Table: Supported input data types for Database protectors with Numeric token
| Protector | Oracle | MSSQL |
|---|---|---|
| Supported Input Data Types | VARCHAR2 CHAR | VARCHAR CHAR |
Note: For numeric data elements where length preservation is not enabled, the maximum supported length is 3,842 characters. Data up to this length can be tokenized and de-tokenized without errors.
For more information about Database protectors, refer to Database Protectors
Feedback
Was this page helpful?