There are small algorithms if you dont want to spend half you life making foolproof code. If your concerned with the average person, they'll probably try little more than an XOR to unencrypt the code. If you're concerned with hackers, you'd be better off using a well known (but complex) algorithm Here is a small one. http://www.ecst.csuchico.edu/~atman/Crypto/code/tea-encryption.alg.html W. -----Original Message----- From: jonathan [mailto:jonnnathan@...] Sent: Friday, October 26, 2001 6:23 AM To: futurebasic@... Subject: Re: [FB] Arithmetic Encoding Compression le 2001/10/26 10:16, Heather Donahue à heatherd@... a écrit : > The Applied Crypto book has all the major algorithms but I wonder if there are > any open-source ones on the internet? most valuable algorithms tend to be open source as peer review is the best way of ensuring the degree of 'unbreakability' of a crypto solution. the most basic rule is: don't rely on an algorithm being secret to ensure its strength and inviolability. the more others can pick and hack at it, the stronger it will be... you only have to look at how all the 'attempts' to keep so-called 'customer-management' developments around digital music 'secret' leads to weak crypto. and making reverse engineering, or research into cracking these 'locks' illegal in the us [CDMA] will not make the problem go away either. the other factor that is often overlooked in crypto is 'time'. if your crypted communication only needs live for a very short time, you can use weaker crypto provided that: - current methods cannot break it in real time [or in the time that it will live] - current methods do not allow the creation of a spoof method in real time and provided that you survey 'current methods' very closely and increase strength as techniques [and machines] improve [which is what the french credit card cartel didn't do, thus allowing one level of crypto on the cards to be cracked a while back*]. most 'brute strength' methods [ie, script-kiddie level] assume that there is plaintext encoded. the 'cracked' text is then analysed [quickly] to see if the letter frequency distribution corresponds to the supposed target language [ie, more 'e's than 'z's in english - think scrabble!]. i remember reading of a cryptographer cracking a code but not realising that this was so as the plaintext was in turkish! thus a scrambling algorithm prior to encrypting removes the easy letter-frequency method of determining that the cracking was successful. remember also that the shorter the text, the harder it is to crack, and, as a corollary to the before, the fewer 'obvious' words/letters in a crypted stream [ie, even if it is crypted you can probably recognise 'AZGS-SCHS-SHCY-HHYS' as credit card quads], the harder it will be to crack. ´:-j * the guy who cracked this was a bit of a nutter, but that doesn't matter. he contacted the group of card issuers telling them he had cracked it, but they didn't believe him; they said 'send us proof'. so he carried out a transaction, in the presence of a public notary as an independant witness. they got him jailed on this basis of this! and then hummed and hawed about the cost of upgrading the system. meanwhiles others have discovered his crack, and the system won't be upgraded entirely before next year... however the courts have changed their jurisprudence following this and now if you contest a transaction, the onus is on the banks to prove that that it was not fraudulent, rather than before when the card holder had to prove her innocence... -- To unsubscribe, send ANY message to <futurebasic-unsubscribe@...>