<@CIPHER>
Syntax
<@CIPHER ACTION=action TYPE=type STR=string [KEY=key][ENCODING=encoding]>
Description
Performs encryption, decryption, and hashes on strings using various algorithms and keys.
<@CIPHER> provides the Tango user with access to various encryption algorithms. The user may specify different keys, if required.
Three attributes are required: ACTION, TYPE, and STR.
- ACTION is the action you want to perform, for example, encrypt or decrypt.
- TYPE is the type of action you want to perform, for example, BitRoll.
- STR is the string upon which you want to execute the action, for example, a social security number. A zero length STR is processed by the underlying cipher routines.
Note:
KEY may be required or prohibited depending on the TYPE of cipher requested. Keys may be case sensitive.
Warning messages are logged if attributes needed are missing:
[Warning] CIPHER: no action specified
[Warning] CIPHER: type not specified or unknown
[Warning] CIPHER: specified key not valid for this cipher
Ciphers Supported
Each type of cipher has at least one operation permitted. Each may accept a key, may provide a default one if none is given, or may reject any key and use a predetermined value, or none, as appropriate.
Cipher names are case insensitive. The following table lists types of ciphers, their actions, their key restrictions, and a short description of each cipher.
* ©RSA Data Security Inc. MD5 Message-Digest Algorithm
The ACTION has two directions, forward and reverse. This means that you can take a string and encrypt, encipher or hash it in the forward direction, and, for the reverse direction, you can decrypt or decipher.
Hash is a one-way cipher: it works only in the forward position. An example use for this would be a passwords for a UNIX system. One-way hash functions are handled as encipher operations with no corresponding decipher operation. The keyword HASH is accepted as an ACTION for this purpose.
Certain synonyms for the two ciphering operations are supported:
plaintext -> ciphertext |
ciphertext -> plaintext |
Security Issues
It is up to the user to guarantee the security of their information. BitRoll, Caesar, and Rot13 are not secure at all, and OneTimePad is only as secure as the keys are managed and generated.
Submitting a key through a form may be insecure, especially because the HTTP request could be viewed in transit. The key and algorithm--and anything else as part of the request--can be viewed in transit. Secure channels must be used to hide text in-transit, and very strong ciphers must be used to guarantee security.