<@CIPHER ACTION=action
TYPE=type STR=string
[KEY=key]
[ENCODING=encoding]>
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.
Note: There is a special case
in which TYPE is not required. This occurs when the ACTION is
Hash, and this is because Tango supports only one type of Hash.
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
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.
Type |
Action |
Key Restrictions |
Short Description |
optional, integer (positive and negative) values only, use "3" as default |
|||
rotate characters by x positions, x being successive case-insensitive characters of key, |
|||
MD51 one way hash. Produces a 32 character string. |
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 |
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.
Copyright © 1999, Pervasive Software. All rights reserved.