Key features of Cryptix.fr :
- Cryptix.fr is the official page of the software Cryptix created by Rbcafe.
- Cryptix.fr is twitter ready https://twitter.com/cryptixOSX
- Cryptix.fr is also available on Cryptix.me
Cryptography (or cryptology; from Greek κρυπτός kryptós, “hidden, secret”; and γράφειν graphein, “writing”, or -λογία -logia, “study”, respectively) is the practice and study of techniques for secure communication in the presence of third parties (called adversaries). More generally, it is about constructing and analyzing protocols that block adversaries; various aspects in information security such as data confidentiality, data integrity, authentication, and non-repudiation are central to modern cryptography. Modern cryptography exists at the intersection of the disciplines of mathematics, computer science, and electrical engineering. Applications of cryptography include ATM cards, computer passwords, and electronic commerce.
securityd — Security context daemon for Authorization and cryptographic
securityd maintains security contexts and arbitrates cryptographic opera-
tions and Security Authorizations. Access to keychain items is routed
through securityd to enforce access controls and to keep private keys out
of user process address space. Authorization calls also communicate with
securityd to enforce rules contained in the /etc/authorization database.
All user interaction with securityd is mediated through the Security
This command is not intended to be invoked directly.
securityd was first introduced in Mac OS X version 10.0 (Cheetah) as the
“Security Server” and was renamed in 10.4 (Panther).
RC4_set_key, RC4 – RC4 encryption
void RC4_set_key(RC4_KEY *key, int len, const unsigned char *data);
void RC4(RC4_KEY *key, unsigned long len, const unsigned char *indata,
unsigned char *outdata);
This library implements the Alleged RC4 cipher, which is described for
example in Applied Cryptography. It is believed to be compatible with
RC4[TM], a proprietary cipher of RSA Security Inc.
RC4 is a stream cipher with variable key length. Typically, 128 bit
(16 byte) keys are used for strong encryption, but shorter insecure key
sizes have been widely used due to export restrictions.
RC4 consists of a key setup phase and the actual encryption or decryp-
RC4_set_key() sets up the RC4_KEY key using the len bytes long key at
RC4() encrypts or decrypts the len bytes of data at indata using key
and places the result at outdata. Repeated RC4() calls with the same
key yield a continuous key stream.
Since RC4 is a stream cipher (the input is XORed with a pseudo-random
key stream to produce the output), decryption uses the same function
calls as encryption.
Applications should use the higher level functions EVP_EncryptInit(3)
etc. instead of calling the RC4 functions directly.
RC4_set_key() and RC4() do not return values.
Certain conditions have to be observed to securely use stream ciphers.
It is not permissible to perform multiple encryptions using the same
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.
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.
The OECD released its Recommendation of the Council concerning Guidelines for Cryptography Policy on 27 March 1997. The guidelines are non-binding recommendations to Member governments, meaning that they will not be part of international law. The Guidelines provide principles which states should take into account and balance in developing a national crypto policy.
The principles are:
1) Trust in cryptographic methods
2) Choice of cryptographic methods
3) Market driven development of cryptographic methods
4) Standards for cryptographic methods
5) Protection of privacy and personal data
6) Lawful access
8) International co-operation
The principles should be seen as “interdependent and should be implemented as a whole so as to balance the various interests at stake. No principle should be implemented in isolation from the rest.”
Some have welcomed the OECD principles as a victory for privacy over US-pushed key recovery, while others object to certain points as being too inflexible or too vague. Although the guidelines do not endorse key recovery, they do not prohibit it either. In fact, the guidelines are vague enough to allow a broad range of interpretation, and states will be able to choose a privacy-oriented or a law-enforcement-driven policy line as they see fit. While the guidelines recommend states to cooperate to coordinate their crypto policies, one may be skeptical about the chances of governments coming to an agreement; after all, within the OECD, states have not been able to agree, and they have left the task of finding a balance between, roughly speaking, information security/ privacy and law-enforcement/ national security to individual states.
The process of discussing and drafting policy guidelines started with an Ad-hoc Meeting of Experts on Cryptography Policy on 18-19 December 1995, organized by the OECD Committee for Information, Computer and Communications Policy (ICCP). They proposed to make a study upon current Member Countries encryption policies, market for encryption, key escrow encryption, and to develop a cryptography policy guideline based on the following principles, among others: provides security with confidence, voluntary use, international perspective, recognise national responsibilities, legally effective. The Group of Experts on Security, Privacy and Intellectual Property Protection in the Global Information Infrastructure held subsequent meetings on 7-8 February 1996 in Canberra, on 8 May 1996 in Washington, DC, on 26-28 June in Paris, and on 26-27 September 1996, again in Paris. At the June 1996 meeting, according to one report, no agreement was established; the OECD was said to be split into two parties, one with countries favouring mandatory key escrow (notably the US, UK, and France), and one with countries opposing this approach (mainly Japan and the Scandinavian countries). See a 1 October 1996 press release.
One can compare the final version to an earlier draft of the Guidelines that was discussed at the December 1996 meeting (with rather optimistic personal comments by Robin Whittle). (Text between [square brackets] remained to be decided upon.) In January 1997, the OECD Group of Experts on Security. Privacy, and Intellectual Property Protection in the GII concluded the guidelines. The Guidelines were finally turned into a Council of the OECD resolution in March 1997.