In cryptography, encryption is the process of encoding messages or information in such a way that only authorized parties can read it.

Rbcafe » Security » Cryptography » Encryption

Crypter une vidéo

À tous les utilisateurs de Crypt.

Pour crypter une vidéo avec Crypt, c’est très simple.



  • Lancer Crypt.

    Ouvrir un fichier dans Crypt


  • Prendre une vidéo et la glisser sur le cadenas de Crypt.
  • Aller dans Préférences et rentrer un mot de passe.

    Rentrer un mot de passe dans Crypt


  • Aller dans Crypt et cliquer sur le bouton : Crypter.

    Crypter une vidéo


  • Choisir un chemin pour la sauvegarde.

    Choisir le nom du fichier


  • Résultat :


Résultat après le cryptage


Après quelques instants, le fichier crypté est généré. L’extension du fichier est cryw. Seul Crypt peut rouvrir ce document.




La vidéo utilisée dans cet article a été trouvée sur : https://vimeo.com/189787437 © PARALLEL STUDIO


Rbcafe » Security » Cryptography » Encryption

Rilascio di Cryptext 1.0.9

Rilascio di Cryptext 1.0.9


Cryptext 1.0.9


In questo aggiornamento :


  • requisiti minimi di sistema necessari.(10.8)
  • L’aggiunta di un aiuto completo.
  • L’aggiunta del supporto “Portachiavi” per password e chiavi.
  • L’aggiunta di “preferenze Block” per bloccare la preferenza in uno stato.
  • L’aggiunta di una casella di controllo per disabilitare il controllo ortografico.
  • Aggiunta di nuove icone retina.
  • Correzione della cifratura / decifratura.
  • Correzione della finestra “About”.
  • Correzione del menu di aiuto.
  • Correzione dei registri.
  • Correzione della barra dei menu.
  • Correzione delle traduzioni.
  • Correzione della barra degli strumenti.
  • Correzione del codice.

Rbcafe » Security » Cryptography » Encryption

Cryptext 1.0.9

Nuova versione di Cryptext


Una nuova versione del software Cryptext 1.0.9 è stata presentata oggi al Mac App Store :


Cryptext 1.0.9


In questo aggiornamento :


  • requisiti minimi di sistema necessari.(10.8)
  • L’aggiunta di un aiuto completo.
  • L’aggiunta del supporto “Portachiavi” per password e chiavi.
  • L’aggiunta di “preferenze Block” per bloccare la preferenza in uno stato.
  • L’aggiunta di una casella di controllo per disabilitare il controllo ortografico.
  • Aggiunta di nuove icone retina.
  • Correzione della cifratura / decifratura.
  • Correzione della finestra “About”.
  • Correzione del menu di aiuto.
  • Correzione dei registri.
  • Correzione della barra dei menu.
  • Correzione delle traduzioni.
  • Correzione della barra degli strumenti.
  • Correzione del codice.

Rbcafe » Security » Cryptography » Encryption


Wassenaar Arrangement / COCOM

1. Export/ import controls


COCOM (Coordinating Committee for Multilateral Export Controls) was an international organization for the mutual control of the export of strategic products and technical data from country members to proscribed destinations. It maintained, among others, the International Industrial List and the International Munitions List. In 1991, COCOM decided to allow export of mass-market cryptographic software (including public domain software). Most member countries of COCOM followed its regulations, but the United States maintained separate regulations.

Its 17 members were Australia, Belgium, Canada, Denmark, France, Germany, Greece, Italy, Japan, Luxemburg, The Netherlands, Norway, Portugal, Spain, Turkey, United Kingdom, and the United States. Cooperating members included Austria, Finland, Hungary, Ireland, New Zealand, Poland, Singapore, Slovakia, South Korea, Sweden, Switzerland, and Taiwan.

The main goal of the COCOM regulations was to prevent cryptography from being exported to “dangerous” countries – usually, the countries thought to maintain friendly ties with terrorist organizations, such as Libya, Iraq, Iran, and North Korea. Exporting to other countries is usually allowed, although states often require a license to be granted.

COCOM was dissolved in March 1994. Pending the signing of a new treaty, most members of COCOM agreed in principle to maintain the status quo, and cryptography remained on export control lists.
Wassenaar Arrangement

The Wassenaar Arrangement controls the export of weapons and of dual-use goods, that is, goods that can be used both for a military and for a civil purpose; cryptography is such a dual-use good.

In 1995, 28 countries decided to establish a follow-up to COCOM, the Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies. The negotiations on the Arrangement were finished in July 1996, and the agreement was signed by 31 countries (Argentina, Australia, Austria, Belgium, Canada, the Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, the Netherlands, New Zealand, Norway, Poland, Portugal, the Republic of Korea, Romania, the Russian Federation, the Slovak Republic, Spain, Sweden, Switzerland, Turkey, the United Kingdom and the United States). Later, Bulgaria and Ukraine also became a participating state to the Arrangement.

The initial provisions were largely the same as old COCOM regulations. The General Software Note (applicable until the December 1998 revision) excepted mass-market and public-domain crypto software from the controls. Australia, France, New Zealand, Russia, and the US deviated from the GSN and controlled the export of mass-market and public-domain crypto software. Export via the Internet did not seem to be covered by the regulations.

There is a personal-use exemption, allowing export of products “accompanying their user for the user’s personal use” (e.g., on a laptop).

In September 1998, Wassenaar negotiations in Vienna did not lead to changes in the crypto controls, although it was apparently considered to restrict the GSN (see an article in German) and possibly also to ease controls for key-recovery crypto. (Compare an article in Swedish of March 1998.)

The Wassenaar Arrangement was revised in December 1998. Negotiations were held on 2 and 3 December 1998 in Vienna, which resulted in restrictions on the General Software Note and in some relexations:

free for export are: all symmetric crypto products of up to 56 bits, all asymmetric crypto products of up to 512 bits, and all subgroup-based crypto products (including elliptic curve) of up to 112 bits;
mass-market symmetric crypto software and hardware of up to 64 bits are free for export (the 64-bit limit was deleted on 1 December 2000, see below);
the export of products that use encryption to protect intellectual property (such as DVDs) is relaxed;
export of all other crypto still requires a license.
There was no change in the provisions on public-domain crypto, so that all public-domain crypto software is still free for export. Nothing was said about electronic exports (e.g., via the Internet), which consequently remain unclear.

In its meeting of 30 November-1 December 2000, the Wassenaar states lifted the 64-bit limit for export controls on mass-market crypto software and hardware (in the Cryptography Note, clause d. (the 64-bit limit) was deleted in its reference to category 5A2, as well as the related Validity Note, see the summary). The public statement of the meeting mentioned that “Participating States recognised that it is important to continue deepening Wassenaar Arrangement understanding of how and how much to control” intangible transfers.

The Wassenaar provisions are not directly applicable: each member state has to implement them in national legislation for them to have effect. (In the entries below, I have included mention of the pre-December 1998 regulations, which will stay into effect until the government enacts new legislation to implement the Wassenaar changes.)

See the Wassenaar List (crypto is in category 5 part 2). See further the Wassenaar Arrangement page (includes contact information for various national export control authorities), a Wassenaar FAQ (by US BIS), Greg Broiles’ page on the Wassenaar Arrangement, which includes links to John Young’s pages on the Wassenaar Arrangement and comments on the December 1998 changes, and the GILC Wassenaar page. See also Chapter 3 of Simo-Pekka Parviainen’s thesis on Cryptographic Software Export Controls in the EU. Cf. an April 1996 article on the Wassenaar Arrangement.


Rbcafe » Security » Cryptography » Encryption



HMAC, HMAC_Init, HMAC_Update, HMAC_Final, HMAC_cleanup – HMAC message
authentication code


#include (openssl/hmac.h)

unsigned char *HMAC(const EVP_MD *evp_md, const void *key,
int key_len, const unsigned char *d, int n,
unsigned char *md, unsigned int *md_len);

void HMAC_CTX_init(HMAC_CTX *ctx);

void HMAC_Init(HMAC_CTX *ctx, const void *key, int key_len,
const EVP_MD *md);
void HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int key_len,
const EVP_MD *md);
void HMAC_Update(HMAC_CTX *ctx, const unsigned char *data, int len);
void HMAC_Final(HMAC_CTX *ctx, unsigned char *md, unsigned int *len);

void HMAC_CTX_cleanup(HMAC_CTX *ctx);
void HMAC_cleanup(HMAC_CTX *ctx);


HMAC is a MAC (message authentication code), i.e. a keyed hash function
used for message authentication, which is based on a hash function.

HMAC() computes the message authentication code of the n bytes at d
using the hash function evp_md and the key key which is key_len bytes

It places the result in md (which must have space for the output of the
hash function, which is no more than EVP_MAX_MD_SIZE bytes). If md is
NULL, the digest is placed in a static array. The size of the output
is placed in md_len, unless it is NULL.

evp_md can be EVP_sha1(), EVP_ripemd160() etc. key and evp_md may be
NULL if a key and hash function have been set in a previous call to
HMAC_Init() for that HMAC_CTX.

HMAC_CTX_init() initialises a HMAC_CTX before first use. It must be

HMAC_CTX_cleanup() erases the key and other data from the HMAC_CTX and
releases any associated resources. It must be called when an HMAC_CTX
is no longer required.

HMAC_cleanup() is an alias for HMAC_CTX_cleanup() included for back
compatibility with 0.9.6b, it is deprecated.

The following functions may be used if the message is not completely
stored in memory:

HMAC_Init() initializes a HMAC_CTX structure to use the hash function
evp_md and the key key which is key_len bytes long. It is deprecated
and only included for backward compatibility with OpenSSL 0.9.6b.

HMAC_Init_ex() initializes or reuses a HMAC_CTX structure to use the
function evp_md and key key. Either can be NULL, in which case the
existing one will be reused. HMAC_CTX_init() must have been called
before the first use of an HMAC_CTX in this function. N.B. HHMMAACC_IInniitt(())
had this undocumented behaviour in previous versions of OpenSSL – fail-
ure to switch to HHMMAACC_IInniitt_eexx(()) in programs that expect it will cause
them to stop working.

HMAC_Update() can be called repeatedly with chunks of the message to be
authenticated (len bytes at data).

HMAC_Final() places the message authentication code in md, which must
have space for the hash function output.


HMAC() returns a pointer to the message authentication code.
HMAC_CTX_init(), HMAC_Init_ex(), HMAC_Update(), HMAC_Final() and
HMAC_CTX_cleanup() do not return values.


Rbcafe » Security » Cryptography » Encryption

EVP digest


EVP_MD_CTX_init, EVP_MD_CTX_create, EVP_DigestInit_ex, EVP_DigestUp-
date, EVP_DigestFinal_ex, EVP_MD_CTX_cleanup, EVP_MD_CTX_destroy,
EVP_MD_pkey_type, EVP_MD_size, EVP_MD_block_size, EVP_MD_CTX_md,
EVP_MD_CTX_size, EVP_MD_CTX_block_size, EVP_MD_CTX_type, EVP_md_null,
EVP_md2, EVP_md5, EVP_sha, EVP_sha1, EVP_dss, EVP_dss1, EVP_mdc2,
EVP_ripemd160, EVP_get_digestbyname, EVP_get_digestbynid,
EVP_get_digestbyobj – EVP digest routines


#include (openssl/evp.h)

void EVP_MD_CTX_init(EVP_MD_CTX *ctx);
EVP_MD_CTX *EVP_MD_CTX_create(void);

int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl);
int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *d, unsigned int cnt);
int EVP_DigestFinal_ex(EVP_MD_CTX *ctx, unsigned char *md,
unsigned int *s);

int EVP_MD_CTX_cleanup(EVP_MD_CTX *ctx);
void EVP_MD_CTX_destroy(EVP_MD_CTX *ctx);

int EVP_MD_CTX_copy_ex(EVP_MD_CTX *out,const EVP_MD_CTX *in);

int EVP_DigestInit(EVP_MD_CTX *ctx, const EVP_MD *type);
int EVP_DigestFinal(EVP_MD_CTX *ctx, unsigned char *md,
unsigned int *s);

int EVP_MD_CTX_copy(EVP_MD_CTX *out,EVP_MD_CTX *in);

#define EVP_MAX_MD_SIZE (16+20) /* The SSLv3 md5+sha1 type */

#define EVP_MD_type(e) ((e)->type)
#define EVP_MD_pkey_type(e) ((e)->pkey_type)
#define EVP_MD_size(e) ((e)->md_size)
#define EVP_MD_block_size(e) ((e)->block_size)

#define EVP_MD_CTX_md(e) (e)->digest)
#define EVP_MD_CTX_size(e) EVP_MD_size((e)->digest)
#define EVP_MD_CTX_block_size(e) EVP_MD_block_size((e)->digest)
#define EVP_MD_CTX_type(e) EVP_MD_type((e)->digest)

const EVP_MD *EVP_md_null(void);
const EVP_MD *EVP_md2(void);
const EVP_MD *EVP_md5(void);
const EVP_MD *EVP_sha(void);
const EVP_MD *EVP_sha1(void);
const EVP_MD *EVP_dss(void);
const EVP_MD *EVP_dss1(void);
const EVP_MD *EVP_mdc2(void);
const EVP_MD *EVP_ripemd160(void);

const EVP_MD *EVP_get_digestbyname(const char *name);
#define EVP_get_digestbynid(a) EVP_get_digestbyname(OBJ_nid2sn(a))
#define EVP_get_digestbyobj(a) EVP_get_digestbynid(OBJ_obj2nid(a))


The EVP digest routines are a high level interface to message digests.

EVP_MD_CTX_init() initializes digest contet ctx.

EVP_MD_CTX_create() allocates, initializes and returns a digest contet.

EVP_DigestInit_ex() sets up digest context ctx to use a digest type
from ENGINE impl. ctx must be initialized before calling this function.
type will typically be supplied by a functionsuch as EVP_sha1(). If
impl is NULL then the default implementation of digest type is used.

EVP_DigestUpdate() hashes cnt bytes of data at d into the digest con-
text ctx. This function can be called several times on the same ctx to
hash additional data.

EVP_DigestFinal_ex() retrieves the digest value from ctx and places it
in md. If the s parameter is not NULL then the number of bytes of data
written (i.e. the length of the digest) will be written to the integer
at s, at most EVP_MAX_MD_SIZE bytes will be written. After calling
EVP_DigestFinal_ex() no additional calls to EVP_DigestUpdate() can be
made, but EVP_DigestInit_ex() can be called to initialize a new digest

EVP_MD_CTX_cleanup() cleans up digest context ctx, it should be called
after a digest context is no longer needed.

EVP_MD_CTX_destroy() cleans up digest context ctx and frees up the
space allocated to it, it should be called only on a context created
using EVP_MD_CTX_create().

EVP_MD_CTX_copy_ex() can be used to copy the message digest state from
in to out. This is useful if large amounts of data are to be hashed
which only differ in the last few bytes. out must be initialized before
calling this function.

EVP_DigestInit() behaves in the same way as EVP_DigestInit_ex() except
the passed context ctx does not have to be initialized, and it always
uses the default digest implementation.

EVP_DigestFinal() is similar to EVP_DigestFinal_ex() except the digest
contet ctx is automatically cleaned up.

EVP_MD_CTX_copy() is similar to EVP_MD_CTX_copy_ex() except the desti-
nation out does not have to be initialized.

EVP_MD_size() and EVP_MD_CTX_size() return the size of the message
digest when passed an EVP_MD or an EVP_MD_CTX structure, i.e. the size
of the hash.

EVP_MD_block_size() and EVP_MD_CTX_block_size() return the block size
of the message digest when passed an EVP_MD or an EVP_MD_CTX structure.

EVP_MD_type() and EVP_MD_CTX_type() return the NID of the OBJECT IDEN-
TIFIER representing the given message digest when passed an EVP_MD
structure. For example EVP_MD_type(EVP_sha1()) returns NID_sha1. This
function is normally used when setting ASN1 OIDs.

EVP_MD_CTX_md() returns the EVP_MD structure corresponding to the
passed EVP_MD_CTX.

EVP_MD_pkey_type() returns the NID of the public key signing algorithm
associated with this digest. For example EVP_sha1() is associated with
RSA so this will return NID_sha1WithRSAEncryption. This “link” between
digests and signature algorithms may not be retained in future versions
of OpenSSL.

EVP_md2(), EVP_md5(), EVP_sha(), EVP_sha1(), EVP_mdc2() and
EVP_ripemd160() return EVP_MD structures for the MD2, MD5, SHA, SHA1,
MDC2 and RIPEMD160 digest algorithms respectively. The associated sig-
nature algorithm is RSA in each case.

EVP_dss() and EVP_dss1() return EVP_MD structures for SHA and SHA1
digest algorithms but using DSS (DSA) for the signature algorithm.

EVP_md_null() is a “null” message digest that does nothing: i.e. the
hash it returns is of zero length.

EVP_get_digestbyname(), EVP_get_digestbynid() and EVP_get_digestbyobj()
return an EVP_MD structure when passed a digest name, a digest NID or
an ASN1_OBJECT structure respectively. The digest table must be ini-
tialized using, for example, OpenSSL_add_all_digests() for these func-
tions to work.


EVP_DigestInit_ex(), EVP_DigestUpdate() and EVP_DigestFinal_ex() return
1 for success and 0 for failure.

EVP_MD_CTX_copy_ex() returns 1 if successful or 0 for failure.

EVP_MD_type(), EVP_MD_pkey_type() and EVP_MD_type() return the NID of
the corresponding OBJECT IDENTIFIER or NID_undef if none exists.

EVP_MD_size(), EVP_MD_block_size(), EVP_MD_CTX_size(e), EVP_MD_size(),
EVP_MD_CTX_block_size() and EVP_MD_block_size() return the digest or
block size in bytes.

EVP_md_null(), EVP_md2(), EVP_md5(), EVP_sha(), EVP_sha1(), EVP_dss(),
EVP_dss1(), EVP_mdc2() and EVP_ripemd160() return pointers to the cor-
responding EVP_MD structures.

EVP_get_digestbyname(), EVP_get_digestbynid() and EVP_get_digestbyobj()
return either an EVP_MD structure or NULL if an error occurs.


The EVP interface to message digests should almost always be used in
preference to the low level interfaces. This is because the code then
becomes transparent to the digest used and much more flexible.

SHA1 is the digest of choice for new applications. The other digest
algorithms are still in common use.

For most applications the impl parameter to EVP_DigestInit_ex() will be
set to NULL to use the default digest implementation.

The functions EVP_DigestInit(), EVP_DigestFinal() and EVP_MD_CTX_copy()
are obsolete but are retained to maintain compatibility with existing
code. New applications should use EVP_DigestInit_ex(), EVP_DigestFi-
nal_ex() and EVP_MD_CTX_copy_ex() because they can efficiently reuse a
digest context instead of initializing and cleaning it up on each call
and allow non default implementations of digests to be specified.

In OpenSSL 0.9.7 and later if digest contexts are not cleaned up after
use memory leaks will occur.


This example digests the data “Test Message\n” and “Hello World\n”,
using the digest name passed on the command line.

#include (stdio .h)
#include (openssl/evp.h)

main(int argc, char *argv[])
EVP_MD_CTX mdctx;
const EVP_MD *md;
char mess1[] = “Test Message\n”;
char mess2[] = “Hello World\n”;
unsigned char md_value[EVP_MAX_MD_SIZE];
int md_len, i;


if(!argv[1]) {
printf(“Usage: mdtest digestname\n”);

md = EVP_get_digestbyname(argv[1]);

if(!md) {
printf(“Unknown message digest %s\n”, argv[1]);

EVP_DigestInit_ex(&mdctx, md, NULL);
EVP_DigestUpdate(&mdctx, mess1, strlen(mess1));
EVP_DigestUpdate(&mdctx, mess2, strlen(mess2));
EVP_DigestFinal_ex(&mdctx, md_value, &md_len);

printf(“Digest is: “);
for(i = 0; i < md_len; i++) printf("%02x", md_value[i]); printf("\n"); } BUGS The link between digests and signing algorithms results in a situation where EVP_sha1() must be used with RSA and EVP_dss1() must be used with DSS even though they are identical digests. EOF

Rbcafe » Security » Cryptography » Encryption



evp – high-level cryptographic functions


#include (openssl/evp.h)


The EVP library provides a high-level interface to cryptographic func-

EVP_Seal… and EVP_Open… provide public key encryption and decryp-
tion to implement digital “envelopes”.

The EVP_Sign… and EVP_Verify… functions implement digital signa-

Symmetric encryption is available with the EVP_Encrypt… functions.
The EVP_Digest… functions provide message digests.

Algorithms are loaded with OpenSSL_add_all_algorithms(3).

All the symmetric algorithms (ciphers) and digests can be replaced by
ENGINE modules providing alternative implementations. If ENGINE imple-
mentations of ciphers or digests are registered as defaults, then the
various EVP functions will automatically use those implementations
automatically in preference to built in software implementations. For
more information, consult the engine(3) man page.


Rbcafe » Security » Cryptography » Encryption



dynamic_pager — dynamic pager external storage manager


dynamic_pager [-E] [-F filename] [-S filesize] [-H high-water-trigger]
[-L low-water-trigger] [-P priority]


The dynamic_pager daemon manages a pool of external swap files which the
kernel uses to support demand paging. This pool is expanded with new
swap files as load on the system increases, and contracted when the swap-
ping resources are no longer needed. The dynamic_pager daemon also pro-
vides a notification service for those applications which wish to receive
notices when the external paging pool expands or contracts.


-E Encrypt the data in the swap files.

-F The base name of the filename to use for the external paging
files. By default this is /private/var/vm/swapfile.

-S The fixed filesize [in bytes] to use for the paging files. By
default dynamic_pager uses variable sized paging files, using
larger sized files as paging demands increase. The -S, -H and -L
options disable that default and cause dynamic_pager to use a
series of fixed sized external paging files.

-H If there are less than high-water-trigger bytes free in the
external paging files, the kernel will signal dynamic_pager to
add a new external paging file.

-L If there are more than low-water-trigger bytes free in the exter-
nal paging files, the kernel will coalese in-use pages and signal
dynamic_pager to discard an external paging file.
Low-water-trigger must be greater than high-water-trigger +

-P This option is currently unimplemented.


/private/var/vm/swapfile* Default external paging files.


Rbcafe » Security » Cryptography » Encryption



crypt, setkey, encrypt, des_setkey, des_cipher, — DES encryption



*crypt(const char *key, const char *setting);

setkey(char *key);

encrypt(char *block, int flag);

des_setkey(const char *key);

des_cipher(const char *in, char *out, long salt, int count);


The crypt() function performs password encryption, based on the NBS Data
Encryption Standard (DES). Additional code has been added to deter key
search attempts. The first argument to crypt() is a null-terminated
string, typically a user’s typed password. The second is in one of two
forms: if it begins with an underscore (“_”) then an extended format is
used in interpreting both the key and the setting, as outlined below.

Extended crypt:

The key is divided into groups of 8 characters (the last group is null-
padded) and the low-order 7 bits of each each character (56 bits per
group) are used to form the DES key as follows: the first group of 56
bits becomes the initial DES key. For each additional group, the XOR of
the encryption of the current DES key with itself and the group bits
becomes the next DES key.

The setting is a 9-character array consisting of an underscore followed
by 4 bytes of iteration count and 4 bytes of salt. These are encoded as
printable characters, 6 bits per character, least significant character
first. The values 0 to 63 are encoded as “./0-9A-Za-z”. This allows
24 bits for both count and salt.

Traditional crypt:

The first 8 bytes of the key are null-padded, and the low-order 7 bits of
each character is used to form the 56-bit DES key.

The setting is a 2-character array of the ASCII-encoded salt. Thus only
12 bits of salt are used. count is set to 25.


The salt introduces disorder in the DES algorithm in one of 16777216 or
4096 possible ways (ie. with 24 or 12 bits: if bit i of the salt is set,
then bits i and i+24 are swapped in the DES E-box output).

The DES key is used to encrypt a 64-bit constant using count iterations
of DES. The value returned is a null-terminated string, 20 or 13 bytes
(plus null) in length, consisting of the setting followed by the encoded
64-bit encryption.

The functions, encrypt(), setkey(), des_setkey() and des_cipher() provide
access to the DES algorithm itself. setkey() is passed a 64-byte array
of binary values (numeric 0 or 1). A 56-bit key is extracted from this
array by dividing the array into groups of 8, and ignoring the last bit
in each group. That bit is reserved for a byte parity check by DES, but
is ignored by these functions.

The block argument to encrypt() is also a 64-byte array of binary values.
If the value of flag is 0, block is encrypted otherwise it is decrypted.
The result is returned in the original array block after using the key
specified by setkey() to process it.

The argument to des_setkey() is a character array of length 8. The least
significant bit (the parity bit) in each character is ignored, and the
remaining bits are concatenated to form a 56-bit key. The function
des_cipher() encrypts (or decrypts if count is negative) the 64-bits
stored in the 8 characters at in using abs(3) of count iterations of DES
and stores the 64-bit result in the 8 characters at out (which may be the
same as in ). The salt specifies perturbations to the DES E-box output
as described above.

The function crypt() returns a pointer to the encrypted value on success,
and NULL on failure. The functions setkey(), encrypt(), des_setkey(),
and des_cipher() return 0 on success and 1 on failure.

The crypt(), setkey() and des_setkey() functions all manipulate the same
key space.


Rbcafe » Security » Cryptography » Encryption



blowfish, BF_set_key, BF_encrypt, BF_decrypt, BF_ecb_encrypt,
BF_cbc_encrypt, BF_cfb64_encrypt, BF_ofb64_encrypt, BF_options – Blow-
fish encryption


#include (openssl/blowfish.h)

void BF_set_key(BF_KEY *key, int len, const unsigned char *data);

void BF_ecb_encrypt(const unsigned char *in, unsigned char *out,
BF_KEY *key, int enc);
void BF_cbc_encrypt(const unsigned char *in, unsigned char *out,
long length, BF_KEY *schedule, unsigned char *ivec, int enc);
void BF_cfb64_encrypt(const unsigned char *in, unsigned char *out,
long length, BF_KEY *schedule, unsigned char *ivec, int *num,
int enc);
void BF_ofb64_encrypt(const unsigned char *in, unsigned char *out,
long length, BF_KEY *schedule, unsigned char *ivec, int *num);
const char *BF_options(void);

void BF_encrypt(BF_LONG *data,const BF_KEY *key);
void BF_decrypt(BF_LONG *data,const BF_KEY *key);


This library implements the Blowfish cipher, which was invented and
described by Counterpane.

Blowfish is a block cipher that operates on 64 bit (8 byte) blocks of
data. It uses a variable size key, but typically, 128 bit (16 byte)
keys are a considered good for strong encryption. Blowfish can be used
in the same modes as DES (see des_modes(7)). Blowfish is currently one
of the faster block ciphers. It is quite a bit faster than DES, and
much faster than IDEA or RC2.

Blowfish consists of a key setup phase and the actual encryption or
decryption phase.

BF_set_key() sets up the BF_KEY key using the len bytes long key at

BF_ecb_encrypt() is the basic Blowfish encryption and decryption func-
tion. It encrypts or decrypts the first 64 bits of in using the key
key, putting the result in out. enc decides if encryption (BF_ENCRYPT)
or decryption (BF_DECRYPT) shall be performed. The vector pointed at
by in and out must be 64 bits in length, no less. If they are larger,
everything after the first 64 bits is ignored.

The mode functions BF_cbc_encrypt(), BF_cfb64_encrypt() and
BF_ofb64_encrypt() all operate on variable length data. They all take
an initialization vector ivec which needs to be passed along into the
next call of the same function for the same message. ivec may be ini-
tialized with anything, but the recipient needs to know what it was
initialized with, or it won’t be able to decrypt. Some programs and
protocols simplify this, like SSH, where ivec is simply initialized to
zero. BF_cbc_encrypt() operates on data that is a multiple of 8 bytes
long, while BF_cfb64_encrypt() and BF_ofb64_encrypt() are used to
encrypt an variable number of bytes (the amount does not have to be an
exact multiple of 8 ). The purpose of the latter two is to simulate
stream ciphers, and therefore, they need the parameter num, which is a
pointer to an integer where the current offset in ivec is stored
between calls. This integer must be initialized to zero when ivec is

BF_cbc_encrypt() is the Cipher Block Chaining function for Blowfish.
It encrypts or decrypts the 64 bits chunks of in using the key sched-
ule, putting the result in out. enc decides if encryption (BF_ENCRYPT)
or decryption (BF_DECRYPT) shall be performed. ivec must point at an 8
byte long initialization vector.

BF_cfb64_encrypt() is the CFB mode for Blowfish with 64 bit feedback.
It encrypts or decrypts the bytes in in using the key schedule, putting
the result in out. enc decides if encryption (BF_ENCRYPT) or decryp-
tion (BF_DECRYPT) shall be performed. ivec must point at an 8 byte
long initialization vector. num must point at an integer which must be
initially zero.

BF_ofb64_encrypt() is the OFB mode for Blowfish with 64 bit feedback.
It uses the same parameters as BF_cfb64_encrypt(), which must be ini-
tialized the same way.

BF_encrypt() and BF_decrypt() are the lowest level functions for Blow-
fish encryption. They encrypt/decrypt the first 64 bits of the vector
pointed by data, using the key key. These functions should not be used
unless you implement ‘modes’ of Blowfish. The alternative is to use
BF_ecb_encrypt(). If you still want to use these functions, you should
be aware that they take each 32-bit chunk in host-byte order, which is
little-endian on little-endian platforms and big-endian on big-endian


None of the functions presented here return any value.


Applications should use the higher level functions EVP_EncryptInit(3)
etc. instead of calling the blowfish functions directly.


Rbcafe © 2004- | Rb Cafe 1.3 | Contatto Rbcafe | Rbcafe su Twitter | Rbcafe su Facebook | Politica sulla riservatezza