ripem frequently noted vulnerabilities archive name ripem attacks last update mar some possible attacks on ripem this is a living list of potential weaknesses to keep your eyes open for when using ripem for secure electronic mail it does not go into great detail and is almost certainly not exhaustive obviously many of the weaknesses are weaknesses of cryptographically secured mail in general and will pertain to secure mail programs other than ripem it is maintained by marc vanheyningen mvanheyn cs indiana edu it is posted monthly to a variety of news groups followups pertaining specifically to ripem should go to alt security ripem cryptanalysis attacks breaking rsa would allow an attacker to find out your private key in which case he could read any mail encrypted to you and sign messages with your private key rsa is generally believed to be resistant to all standard cryptanalytic techniques even a standard key about bits with ripem is long enough to render this impractical barring a huge investment in hardware or a breakthrough in factoring breaking des would allow an attacker to read any given message since the message itself is encrypted with des it would not allow an attacker to claim to be you des has only bits in its key and thus could conceivably be compromised by brute force with sufficient hardware but few agencies have such money to devote to simply read one message since each message has a different des key the work for each message would remain high key management attacks stealing your private key would allow the same benefits as breaking rsa to safeguard it it is encrypted with a des key which is derived from a passphrase you type in however if an attacker can get a copy of your private keyfile and your passphrase by snooping network packets tapping lines or whatever he could break the whole scheme the main risk is that of transferring either the passphrase or the private key file across an untrusted link so don t do that run ripem on a trusted machine preferably one sitting right in front of you ideally your own machine in your own home or maybe office which nobody else has physical access to fooling you into accepting a bogus public key for someone else could allow an opponent to deceive you into sending secret messages to him rather than to the real recipient if the enemy can fool your intended recipient as well he could re encrypt the messages with the other bogus public key and pass them along it is important to get the proper public keys of other people the most common mechanism for this is finger assuming the opponent has not compromised routers or daemons or such finger can be given a fair amount of trust the strongest method of key authentication is to exchange keys in person however this is not always practical having other people vouch for you by signing a statement containing your key is possible although ripem doesn t have features for doing this as automatically as pgp ripem does generate and check md fingerprints of public keys in the key files they may be exchanged via a separate channel for authentication playback attacks even if an opponent cannot break the cryptography an opponent could still cause difficulties for example suppose you send a message with mic only a pem mode which does not provide disclosure protection to alice which says ok let s do that your opponent intercepts it and now resends it to bob who now has a message which is authenticated as from you telling him to do that of course he may interpret it in an entirely different context or your opponent could transmit the same message to the same recipient much later figuring it would be seen differently at a later time or the opponent could change the originator name to himself register your public key as his and send a message hoping the recipient will send him return mail indicating perhaps even quoting the unknown message to defeat playback attacks the plaintext of each message should include some indication of the sender and recipient and a unique identifier typically the date a good front end script for ripem should do this automatically imho as a recipient you should be sure that the originator name header and the sender indicated within the plaintext are the same that you really are a recipient and that the message is not an old one some this also can and should be automated the author of this faq has made a modest attempt at automating the process of generating and checking encapsulated headers the programs are included in the standard distribution in the utils directory local attacks clearly the security of ripem cannot be greater than the security of the machine where the encryption is performed for example under unix a super user could manage to get at your encrypted mail although it would take some planning and effort to do something like replace the ripem executable with a trojan horse or to get a copy of the plaintext depending how it s stored in addition the link between you and the machine running ripem is an extension of that if you decrypt with ripem on a remote machine which you are connected to via network or worse yet modem an eavesdropper could see the plaintext and probably also your passphrase ripem should only be executed on systems you trust obviously in the extreme case ripem should only be used on your own machine which you have total control over and which nobody else has access to which has only carefully examined software known to be free of viruses and so on however there s a very real trade off between convenience and security here a more moderately cautious user might use ripem on a unix workstation where other people have access even root access but increase security by keeping private keys and the statically linked of course executable on a floppy disk some people will keep ripem on a multi user system but when dialing in over an insecure line they will download the message to their own system and perform the ripem decryption there however the security provided by such a mechanism is somewhat illusory since you presumably type your cleartext password to log in you ve just given away the store since the attacker can now log in as you and install traps in your account to steal your private key next time you use it from a less insecure line this will likely remain the situation as long as most systems use the rather quaint mechanism of cleartext password authentication i find it nice to put a brief statement of how carefully i manage my security arrangement in my plan next to my public key so that potential correspondents can be aware what level of precautions are in place some people use two keys a short one which is not carefully managed for ordinary use and a longer one which is treated with greater care for critical correspondence untrusted partner attacks ripem s encryption will ensure that only a person with the private key corresponding to the public key used to encrypt the data may read the traffic however once someone with that key gets the message she may always make whatever kind of transformations she wishes there exist no cryptographic barriers to a recipient say taking an encrypted message and converting it to a mic only message signed by you and readable by anyone although ripem does not provide this functionality indeed the latest pem draft i have seen specifically states that such transformations should be possible to allow forwarding functions to work including the recipients in the plaintext as mentioned above will make it possible for recipients of a redistributed message to be aware of its original nature naturally the security of the cryptography can never be greater than the security of the people using it
