> For the complete documentation index, see [llms.txt](https://docs.editran.onesait.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.editran.onesait.com/documentacion-editran/ibm-editran-v5.3-cics-en/utilities-and-codes/appendix-d.-cryptography-system-in-onesait-editran/types-of-keys.-cryptographic-version-and-key-change.md).
# Types of keys. Cryptographic version and key change
The values of the CRYPTOGRAPHIC VERSION field are:
1. Version 3.00 and 4.00 with DES or RSA authentication. The exchange is not automatic like cryptography 2.20. This mode uses cryptographic keys that users must have previously exchanged by the method they consider convenient: email, mail, telephone, editran, or however the two involved entities deem appropriate (with the Key Exchange Management module, this exchange can be carried out securely, without any of the participants knowing the actual value of the exchanged key). When cryptography 3.00 or 4.00 is used, there are 2 types of keys:
> * Exchange or transport keys (the ones exchanged by the 2 entities). These keys can be DES, RSA. With them, the authentication algorithm is referred to, with possible values: DES, RSA
> * If they are DES (DES authentication algorithm), the entities can exchange:
> * Simple DES keys (8 bytes). Any editran machine can exchange these keys
> * Double DES keys (16 bytes). Depending on the operating system and the installed editran version, it is or is not possible (open environments v.editran > 5.0, zos environments, all versions, i-series environment not yet available). If either of the 2 environments is not compatible, but you want to work with double keys, the first 8 bytes of the key must have the same value as the last 8. If, for example, a UNIX generates a SIMPLE DES transport key and sends it to a zos, this could include it as a DOUBLE DES IMPORTER transport key (16 bytes), simply by repeating the 8 bytes that were sent with the SIMPLE DES KEY (8 BYTES). Likewise, if a zos generates a DOUBLE DES EXPORTER transport key and the value of its first 8 bytes is identical to the value of its last 8 bytes, UNIX can include it as a SIMPLE DES KEY by using the first 8 bytes that arrive. In both cases, the process works well. However, with double keys what is done are encryption processes (with first 8), decryption (with second 8) and re-encryption (with first 8), so repeating the first 8 and the second 8 bytes in a double key triples the operations to be performed (compared with simple keys), obtaining the same result in the end. Therefore, it is recommended not to use identical doubles.
> * Triple DES keys (24 octets). Neither end generates them.
> * If they are RSA, (RSA authentication algorithm) the entities exchange the public part of the key, as explained above.
> * Operational keys. These keys are always DES (simple, double or triple). With them, the confidentiality algorithm is referred to, with possible values: DES (8 bytes or simple DES), TD2C (16 bytes, or double DES) and TD3C (24 bytes or triple DES). These are the keys that will encrypt the editran data (as stated earlier). Do not confuse them with exchange keys. All editran environments can generate triple DES operational keys, and yet none generates triple exchange keys.
In cryptography 3.0 or 4.0: Thus, for example, if we exchange an RSA key (exchange or transport key, RSA authentication), we send the remote side the public part of our key and the remote side sends us theirs. At the start of each transmission, an operational DES key is generated, (for example, triple, of 24 octets, if we have indicated confidentiality TD3C). On one hand, that DES operational key is stored encrypted under the RSA public key that remote gave us. On the other hand, editran encrypts the data with the operational key (encryption-decryption-encryption). Finally, editran sends the encrypted DES operational key and the encrypted data. That remote side, has the private one, so it decrypts the encrypted operational key with it and obtains as a result the clear operational key (with which we encrypt the data ourselves). Next, it decrypts the data with that operational key (decryption-encryption-decryption). In the previous example, when encryption-decryption-encryption or decryption-encryption-decryption is indicated, what it really means is that the operational key is triple, 24 bytes. The data is encrypted with the first 8 bytes of the operational key. The result is decrypted with the second 8. The result is encrypted with the last 8. The result is sent to the remote side. That side decrypts the operational key (as explained before) and then decrypts the data that arrives with the last 8 bytes of the operational key. The result is encrypted with the middle 8 and the result is decrypted with the first 8 bytes of the operational key. The final result is the clear data.
In cryptography 3.0: Thus, for example, if we exchange a DES key (simple with any environment or double between 2 zos) (exchange or transport key, DES authentication), we send the same one to the remote side. At the start of each transmission, a DES operational key is generated, (for example, triple, if we have indicated confidentiality TD3C). The process is the same as in the previous example. On one hand, the generated operational key is encrypted under the exchanged remote DES and on the other the data is encrypted under the generated operational key.
As seen, the 3.00 encryption of the operational key is DES or RSA. RSA is more secure.
Example of a DES key exchange and use of TDES to encrypt data:
| Entity A | Action | Entity B |
| ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| 1.- Generates a DES key x’AAA…’
(external process to editran)
| 2.- A communicates DES key x’AAA…’ to B
(external process to editran)
| 3.- Incorporates DES key x’AAA…’
(external process to editran)
|
| 6.- Incorporates DES key x’BBB…’
(external process to editran)
| 5.- B communicates DES key x’AAA…’ to A
(external process to editran)
| 4.- Generates a DES key x’BBB…’
(external process to editran)
|
| 7.- Editran A, on each transmission generates a TRIPLE DES OPERATIONAL key x’CCC…’ | 8.- Editran A sends to editran B the key x’CCC..’ encrypted under x’BBB..’
Also signs under x’AAA..’
| 9.- Editran B decrypts x’CCC…’ under x’BBB..’ and obtains x’CCC..’ in clear |
| 10.- Editran A encrypts DATA under x’CCC’ | 10.- Editran A sends to editran B DATA encrypted under x’CCC’ | 11.- Editran B decrypts data under x’CCC..’ and outputs them in clear
Verifies the signature of x’AAA..’
|
Example of an RSA key exchange and use of TDES to encrypt data:
| | |
|---|
| Entity A | Action | Entity B |
1.- Generates an RSA key, with 2 parts: private x’AAA…’ and public x’YYY’ (external or automated process with GC) | 2.- A communicates RSA public key x’YYY…’ to B (external or automated process with GC) | 3.- Incorporates RSA key x’YYY…’ (external or automated process with GC) |
6.- Incorporates RSA key x’ZZZ…’ (external or automated process with GC) | 5.- B communicates RSA public key x’ZZZ…’ to A (external or automated process with GC) | 4.- Generates an RSA key, with 2 parts: private x’BBB…’ and public x’ZZZ’ (external or automated process with GC) |
| 7.- Editran A, on each transmission generates a TRIPLE DES OPERATIONAL key x’CCC…’ | 8.- Editran A sends to editran B the key x’CCC.’ encrypted under x’ZZZ..’ Also signs under x’AAA..’ | 9.- B decrypts x’CCC…’ under x’ZZZ..’ (and x’YYY) and obtains x’CCC..’ in clear |
| 10.- Editran A encrypts DATA under x’CCC’ | 10.- Editran A sends to editran B DATA encrypted under x’CCC’ | 11.- Editran B decrypts data under x’CCC.’ and outputs them in clear Verifies the signature of x’AAA..’ (because it has x’YYY..’) |
Do not confuse TRIPLE DES – DES - RSA, TRIPLE DES or DES is the way to encrypt the data, it is the way to generate the OPERATIONAL KEY.
DES or RSA is the way to exchange the key, it is the way to exchange the EXCHANGE KEY.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.editran.onesait.com/documentacion-editran/ibm-editran-v5.3-cics-en/utilities-and-codes/appendix-d.-cryptography-system-in-onesait-editran/types-of-keys.-cryptographic-version-and-key-change.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.