Bonjour,

Réponse un peu tardive...

Pour commencer, il faudrait plutôt parler d'encodage/décodage d'URL, le but n'étant pas (forcément) de rendre indéchiffrable l'URL dans sa nouvelle forme.

Tu disposes de plusieurs techniques pour parvenir à tes fins

1. Si ton problème ne concerne que la construction d'URL valide, tu peux/dois échapper l'URL qui suit linker?url= avec la méthode CGI.escape. L'URL totale sera alors valide (pour le navigateur comme pour le serveur) et tu pourras retrouver l'ensemble des paramètres sans aucun effort additionnel car Rails te les aura décodés.

2. Si tu souhaites masquer l'URL, tu peux l'encoder en base 64 au moment où tu la contruis, puis la décoder en base 64 dans la méthode index de ton controller Linker. Pour la culture générale sur Base64, voir http://fr.wikipedia.org/wiki/Base64.

En Ruby, tu disposes dans la librairie standard de la classe Base64, qui porte les méthodes encode64 et decode64. Il te faut d'ailleurs peut-être combiner Base64 et CGI.(un)escape (à vérifier en ce qui concerne les caractères +, = ou / utilisés dans l'alphabet base 64).

L'inconvénient majeur de cette seconde solution, c'est la taille conséquente de la forme encodée de ton URL. Ta query string peut devenir énorme et toucher les limites autorisées. Par contre, cette solution ne requiert aucun stockage (voir la suite).

3. Si les URLs que tu souhaites masquer sont enregistrées dans ta base de données, tu peux leur associer un hash, MD5 ou SHA1 (http://fr.wikipedia.org/wiki/Md5, http://fr.wikipedia.org/wiki/Sha1).

Il s'agit d'une chaîne de 32 caractères quelle que soit la taille de l'URL, et dont tu peux te servir comme clé externe. Le risque que 2 URLs de ton système retourne le même hash est faible (c'est la théorie qui le dit, pas moi :) ). Pour ma part, j'utilise cette technique sur une base comprenant plus d'un million d'URLs et je n'ai jamais rencontré de problèmes (j'ai un index unique sur la colonne MD5).

En Ruby, tu disposes dans la librairie standard des classes Digest::MD5 et Digest::SHA1 qui portent toutes les 2 la méthode hexdigest.

En souhaitant que tout ceci te soit utile pour solutionner ton problème.

Tu n'as probablement pas envie de faire ça. Je te donne des pistes en bas de message, mais lis d'abord les quatre raisons qui font que ce n'est vraiment pas ce dont tu as besoin.

CLARTÉ
Une URL explicite est bien meilleure : plus jolie, rassurante, simple à bookmarker et aisément retrouvable dans une Awesome Bar telle que Firefox 3 ou Chrome.
Une URL propre se voit dans la statusbar quand on s'apprête à cliquer sur un lien. Une URL "moche" est un embêtement à tous niveaux : regarde les forums PHP, le CMS SPIP, ou YouTube.
Enfin, une URL "propre" est un énorme bonus en SEO.

SÉCURITÉ
La sécurité par l'obscurantisme n'est PAS une sécurité valide. Si tu veux protéger tes accès, fais-le correctement au niveau de ton code et avec une vraie politique d'authentification et de droits. Il y a de très bons plugins pour ça.
Une URL ça se balade, ça s'observe par man-in-the-middle, se copie, s'envoie par mail, ... pour une vraie sécurité de l'URL, passe par HTTPS : la connexion au domaine seule est en clair (normal) et les sous-domaines, routes et paramètres sont envoyés dans un deuxième temps, dans la connexion chiffrée !

DÉVELOPPEMENT
Modifier ainsi les URLS te prive de l'usage "normal" du routage de Rails : c'est un module plutôt complexe qui fait à la fois la détection et la répartition des requêtes mais surtout (et on a tendance à l'oublier) les écritures d'URL dans url_for (donc dans link_to).
Ton code sera plein de modifs perso, ou bien partout (ultra-pénible à maintenir), ou bien tu vas devoir bidouiller dans le code interne de Rails... tu introduirais un tel nombre d'effet de bord (comment trouver la page html.erb associée ?) que je n'ose même pas imaginer le temps et les efforts qu'il te faudra.
Et bien sûr, tu t'en mordras les doigts en changeant de version : pas de correction des bugs, des failles de sécu, pas de nouvelles fonctionnalités et d'amélioration des perfs...

PERFORMANCE
Car en prime, le routing prend du temps. Ajoute à cela un temps précieux de chiffrage/déchiffrage, un code pas forcément optimisé, et tu perdras un temps fou ! J'espère que tu fais ton appli pour un très petit public et une charge minimale...

SOLUTIONS
Enfin, si tu y tiens vraiment, je ferais un front-controller (soi-disant un avantage de MVC2, mais je n'approuve pas), soit en modifiant application_controller, mais plutôt en passant tout à un ocntrôleur "URL" qui n'aurait qu'une action ("url" par exemple) et qui ferait le déchiffrage et les appels d'action à la TinyURL.

Pour les params il y a le marshalling proposé par Ruby (voir la doc) : il "pack" tout objet dans une chaîne pour pouvoir stocker ou passer des objets complexes. Tu pourrais faire ça si ton but est seulement d'avoir une URL très moche, mais il faudrait aussi la chiffrer d'une manière ou d'une autre histoire que, si j'ai Ruby par exemple, un simple chargement par Marshall ne me donne pas tous tes params.

Sinon, regarde du côté de la réécriture d'URL fournie par ton serveur web. Le module d'Apache est pas mal et plutôt rapide je crois, mais assez pénible à faire. Je ne sais pas s'il gère bien le chiffrage.

MAIS CE N'EST PAS FINI !
Le vrai souci bien sur viendra au moment où tes utilisateurs remplissent des formulaires : ou bien ils passent en clair (ou sécurisés par HTTPS) ou bien tu dois les encoder avant avec un Javascript côté client... donc tu me donnes le code, et je te pirate quand je veux ;)

Seule solution dans ce cas, faire un chiffrage clé publique/clé privée. C'est vraiment beaucoup de travail pour un problème difficile certes mais classique, auquel il existe déjà des solutions toutes faites.

Dernier conseil : en français, on n'utilise la racine "crypt" que pour le nom des trois sciences (Cryptographie et Cryptanalyse, qui sont des branches de la Cryptologie). Tout le reste se dit avec la racine "chiffre".
http://fr.wikipedia.org/wiki/Cryptographie#Vocabulaire

C'est pas pour être pointilleux : c'est que, chez les gens qui sont vraiment forts en info, ils arrêtent aussitôt de prendre au sérieux les gens qui disent des trucs comme "encrypter".