Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.

Sunday, January 05, 2020

 

Introducing geewallet

Version 0.4.2.187 of geewallet has just been published to the snap store! You can install it by looking for its name in the store or by installing it from the command line with `snap install geewallet`. It features a very simplistic and minimalistic UI/UX. Nothing very fancy, especially because it has a single codebase that targets many (potential) platforms, e.g. you can also find it in the Android App Store.

What was my motivation to create geewallet in the first place, around 2 years ago? Well, I was very excited about the “global computing platform” that Ethereum was promising. At the time, I thought it would be like the best replacement of Namecoin: decentralised naming system, but not just focusing on this aspect, but just bringing Turing-completeness so that you can build whatever you want on top of it, not just a key-value store. So then, I got ahold of some ethers to play with the platform. But by then, I didn’t find any wallet that I liked, especially when considering security. Most people were copy+pasting their private keys into a website (!) called MyEtherWallet. Not only this idea was terrifying (since you had to trust not just the security skills of the sysadmin who was in charge of the domain&server, but also that the developers of the software don’t turn rogue…), it was even worse than that, it was worse than using a normal hot wallet. And what I wanted was actually a cold wallet, a wallet that could run in an offline device, to make sure hacking it would be impossible (not faraday-cage-impossible, but reasonably impossible).

So there I did it, I created my own wallet.

After some weeks, I added bitcoin support on it thanks to the library NBitcoin (good work Nicholas!). After some months, I added a cross-platform UI besides the first archaic command-line frontend. These days it looks like this:



What was my motivation to make geewallet a brain wallet? Well, at the time (and maybe nowadays too, before I unveil this project at least), the only decent brain wallet out there that seemed sufficiently secure (against brute force attacks) was WarpWallet, from the Keybase company. If you don’t believe in their approach, they even have placed a bounty in a decently small passphrase (so if you ever think that this kind of wallet would be hacked, you would be certainly safe to think that any cracker would target this bounty first, before thinking of you). The worst of it, again, was that to be able to use it you had again to use a web interface, so you had the double-trust problem again. Now geewallet brings the same WarpWallet seed generation algorithm (backed by unit tests of course) but on a desktop/mobile approach, so that you can own the hardware where the seed is generated. No need to write anymore long seeds of random words in pieces of paper: your mind is the limit! (And of course geewallet will warn the user in case the passphrase is too short and simple: it even detects if all the words belong to the dictionary, to deter low entropy, from the human perspective.)

Why did I add support for Litecoin and Ethereum Classic to the wallet? First, let me tell you that bitcoin and ethereum, as technological innovations and network effects, are very difficult to beat. And in fact, I’m not a fan of the proliferation of dubious portrayed awesome new coins/tokens that claim to be as efficient and scalable as these first two. They would need not only to beat the network effect when it comes to users, but also developers (all the best cryptographers are working in Bitcoin and Ethereum technologies). However, Litecoin and Ethereum-Classic are so similar to Bitcoin and Ethereum, respectively, that adding support for them was less than a day’s work. And they are not completely irrelevant: Litecoin may bring zero-knowledge proofs in an upcoming update soon (plus, its fees are lower today, so it’s an alternative cheaper testnet with real value); and Ethereum-Classic has some inherent characteristics that may make it more decentralised than Ethereum in the long run (governance not following any cult of personality, plus it will remain as a Turing-complete platform on top of Proof Of Work, instead of switching to Proof of Stake; to understand why this is important, I recommend you to watch this video).

Another good reason of why I started something like this from scratch is because I wanted to use F# in a real open source project. I had been playing with it for a personal (private) project 2 years before starting this one, so I wanted to show the world that you can build a decent desktop app with simple and not too opinionated/academic functional programming. It reuses all the power of the .NET platform: you get debuggers, you can target mobile devices, you get immutability by default; all three in one, in this decade, at last. (BTW, everything is written in F#, even the build scripts.)

What’s the roadmap of geewallet? The most important topics I want to cover shortly are three:
With less priority:

Areas where I would love contributions from the community:

And just in case I wasn't clear:

I'm excited about the world of private-key management. I think we can do much better than what we have today: most people think of hardware wallets to be unhackable or cold storage, but most of them are used via USB or Bluetooth! Which means they are not actually cold storage, so software wallets with offline-support (also called air-gapped) are more secure! I think that eventually these tools will even merge with other ubiquitous tools with which we’re more familiar today: password managers!

You can follow the project on twitter (yes I promise I will start using this platform to publish updates).

PS: If you're still not convinced about these technologies or if you didn't understand that PoW video I posted earlier, I recommend you to go back to basics by watching this other video produced by a mathematician educator which explains it really well.

PS II: Apologies if this blogpost shows up in planets again, as it might be a side-effect of updating it to fix broken links or typos.

Labels: , , , , , , , , ,


# posted by knocte @ 5:31 pm 0 comments

Sunday, September 07, 2008

 

Hackweeks

I'm going to give a brief summary of what I've done in the past weeks (and specially previous week (last one in August), sponsored by Novell as The Hackweek - a form of ITO, in which you can hack at working hours and not only spare time!

I was not so lucky as most of my teammates, who spent the week on the wonderful offices (as they say) of Novell Utah. Maybe if I was in the states already... but well, I had recently an interview in the US Embassy which was the last step of my visa process, so I hope that at least I can make it for the Gnome Boston Summit!

So, firstly I thought of dedicating my week to this task that I submitted to the ideas website, but in the end realized it would be a ton of work to complete without help, and nobody joined me so I decided to learn to use OpenSuseBuildService in order to package Bugzilla, a pretty complex server side software.

Fortunately, I've learnt a lot this week, especially thanks to all the people in irc://irc.freenode.net/#openSUSE-buildservice (above all, darix) and some people from my team (Ray Wang and Stephen Shaw). I could also contact the author of the RPM file for Fedora (who was formerly working for Red Hat), and he's willing to help on joining efforts, as OBS is cross-distribution.

Unfortunately, packaging is a complex task and I didn't finish the package. The documentation is a bit incomplete and having past experience in packaging is a plus that I didn't have. It's awesome that inside our UIA Team we have exclusive resources dedicate to this, because it would be impossible to do from just the developer side.

One of the difficulties I found is finding packages I needed. I could find some of them (BTW, using Webpin is cool for searching on SUSE software repositories, including Packman; except for the fact that doesn't enhance one-click-install) but not all so then I'll have to help on providing packages for some CPAN Perl modules, contributing to the devel:languages:perl official repo.

On the way of learning OBS, I also filed bugs and feature requests (not only to OBS, but also to Banshee! as I have been using it a lot lately at the same time I hack and I even cooked some small patches):

OBS:
Usability issues in project creation page
Link to "My projects" fails if no home:login project has been created yet
New option for uploading the tarball
ChangeLogs parsing is too strict: lines beginning with tab are not recognized, only one date format is accepted
OBS should not allow to create a package named "packageand"
The spec parser should detect the use of a miscplaced packageand(_:_) keyword

Banshee:
No such file or directory errors while importing
Cannot empty some ID3 tag fields
Importing songs without album metadata breaks artist navigation on the iPod
Banshee inserts deduced fictional text on metadata
Should try to locate correct album (and download its cover) in case no album is supplied on metadata


The patches are quite simple so I hope they get committed soon! Clearly Banshee devs and contributors are doing an amazing work, I'm specially amazed by the Moonlight effects, the Muinshee front-end and the effort that it seems is being dedicated to bring Library Sync & Refresh for 1.4. I wish them all the best success.

So let's get back to packaging. Firstly I thought I had found some limitations in OBS or rpm systems because the lack of proper "dual dependency" support. In the past when I installed Bugzilla manually (and updated it to newer versions) I found it a bit hard to do it, specially to deal with DB creation and upgrade. I wanted to make this process easier for the potential rpm user, but without limiting the choice of the DB engine used (as now Bugzilla supports MySQL, PostgreSQL, and Oracle, although the latter was not on my scope). It turns out that it's really hard to apply virtual-provides rules for these cases, as we should stablish more sub-dependencies depending on the db engine you choose, such as perl-DBD-mysql or perl-DBD-Pg, and because it would cause inconsistent situations in case someone in the future replaces his DB-engine with the alternative one (as in theory it should work at the dependencies-level without warning). For references, you may be interested in reading the whole thread about it in the BuildService mailing-list, whose last message includes a possible hack to workaround these problems using patterns (although I don't like to use patterns for solving something like this).

Even discarding the dream about solving this at a package level, it's difficult to solve it at an app level that wouldn't involve reading manuals. My idea was to modify Bugzilla upstream in order to avoid running manually a local script for its initialization, and replace it with a nice web front-end (even if it's only allowed to be run locally). That would cause problems because normally the webserver user doesn't have enough permissions to create files and the database tables and initial data (I'm sure there's always a solution that also doesn't expose security problems, but it's hard to find it as it's noticed in this thread in bugzilla devel newsgroup; so, help is truly welcome).

Maybe the easier and fastest solution is a mixture of both worlds, that is, having a web front-end that asks you the initial configuration, and the form submission process just writes it in a local XML and tells the admin to open a console and run a script as root to finish the process. But even with this solution I guess we should need something to detect at runtime (which should be cross distribution) if some package is installed (which also checks the version). I guess there's already some of that capabilities used in the bugzilla's script checksetup.pl, so I would reuse them. However, in case it finds a problem, there's no way for the application to request installation of a package directly to your OS (but I've attended to a PackageKit conference in last Guadec in which I heard something about this possibility in the future!).

Labels: , , , , , , ,


# posted by knocte @ 10:22 pm 1 comments

Sunday, May 28, 2006

 

Man-in-the-middle authentication

Con este concepto tan psicódelico he querido describir la típica situación que se da cuando quieres que un conocido mire algo por ti en un sistema en el que necesitas autenticarte pero al que no tienes acceso físicamente, y por el contrario el conocido sí tiene. Lo ideal para este tipo de cosas son las "OnceTimePassword", pero si no te has preparado el tinglado para esto, ¿le dirías tu contraseña?

Esto precisamente me pasó ayer, cuando necesitaba mirar mi correo electrónico pero el ADSL no me funcionaba en casa. La solución pasaba por hacerlo a través de mi hermano, mediante llamada teléfonica. Siempre da un poco de reparo decir tu contraseña a alguien, aunque sea un familiar, y sobre todo cuando puede ser fácil de recordar y, por más que esta persona no quisiera, nunca podría evitar acordarse. Además a mí me ocurre que me caso con las contraseñas, tengo tres o cuatro que uso en bastantes sitios, por lo que no me sería nada fácil deshacerme de una de ellas.

Dándole vueltas y más vueltas, encontré una especie de solución. Pero sólo funciona si confías lo suficientemente en la persona para saber que no te engañaría, porque has de confiar en que al dictársela mediante el método que te voy a exponer, él no la estará escribiendo en un lugar intermedio para poder acceder a ella posteriormente (normalmente usará la casilla ofuscada donde meter la contraseña).

Y lo describiré con un breve ejemplo. Podrías dictárle tu contraseña de este modo:

¿Habrías deducido que este conjunto de instrucciones dan como resultado la contraseña 'pepito'?

Jejeje, hombre, es un trabajo un poco engorroso, pero podríamos programar una pequeña aplicación que generase aleatoriamente toda esta basurilla para una contraseña determinada, y así ahorrarnos el trabajo de inventarnos todos esos rodeos para evitar que el "hombre de en medio" descubra el término que le estamos indicando.





Al hilo de este tema, muchas veces me pongo a pensar sobre los típicos problemas de seguridad que puede suponer usar contraseñas desde ordenadores ajenos o públicos. Son ordenadores a los que no tenemos acceso y que perfectamente pueden tener instalados los siguientes mecanismos para la captura de contraseñas:
  1. Sistemas espía, que envían lo que estás viendo por la pantalla a un buffer o a otra entidad de la red que puede estar observando.
  2. Key loggers, que monitorizan todo lo que tecleamos y lo deja registrado.
  3. Sniffers, que monitorizan todo el tráfico de la red.


Contra los primeros, nos sirve lo que ya actualmente tenemos en la mayoría de los sitios: las casillas ofuscadas para contraseñas, que colocan asteriscos o puntos en lugar de la contraseña, a medida que la escribimos.

Contra los segundos, empiezan a aparecer sistemas, como el de CajaMadrid, que te obliga a meter tu código con el ratón en lugar de con el teclado. Esta técnica puede estar bien pero lleva asociados otros problemas:


Los del tercer tipo se suele proteger uno de ellos mediante el cifrado (usando HTTPS en lugar de HTTP, por ejemplo). El problema es que quien tiene que implementar esta protección es el administrador del servicio, y no el usuario (a no ser que seamos lo suficientemente avispados y no acomodaticios como para usar una de estas técnicas).

Pensando un poquito sobre todo esto, se me ha ocurrido otro sistema que podría emplearse para protegerse de los tres mecanismos a la vez, pero tendría que implementarse desde el servidor/administrador, no desde la parte cliente. El sistema consistiría en, cada vez que se va a realizar el desafío (preguntar el secreto compartido, la contraseña) al usuario, preguntarle únicamente una parte de la contraseña, por ejemplo: las tres primeras letras, las dos últimas, y el número de letras en total que tiene la contraseña. En cada autenticación se tendrían que preguntar cosas distintas sobre la contraseña, y para que el sistema fuera absolutamente óptimo, debería garantizarse que, aunque se tuviera acceso a todas las preguntas y respuestas que hubiera hecho un usuario en la autenticación, no pudiera deducirse ni calcularse el secreto compartido en la práctica.

Así se evitan ataques man-in-the-middle, key-loggers, y demás. El único inconveniente que tiene es, como es habitual, que el proceso de autenticación se vuelve ligeramente más complejo.

Labels: ,


# posted by knocte @ 10:36 pm 2 comments

Wednesday, February 22, 2006

 

SAML, SSO, FOSDEM

Bueno, pues acabo de llegar de unas conferencias en la UEM, patrocinadas por Hazent Systems, que han sido muy interesantes. Bueno, a la primera he llegado tarde, la segunda no me ha gustado demasiado (la tecnología VoIP no es una cosa que me entusiasme, de momento) pero la tercera ha estado bastante bien, porque desconocía que hubiera un equivalente en el software libre a la tecnología Passport de Microsoft (que se engloba como una técnica de S.S.O.: Single Sign-On), y menos que estuviera tan evolucionada como al parecer ocurre, ya que incluso hay estándares que ya van por la version 2.0, como SAML, promocionados por la iniciativa Oasis (los mismos que especificaron el estándar OpenDocument usado por OpenOffice).

La verdad es que aún no he tenido ocasión de idear la arquitectura de una solución web que permitiese el registro de usuarios (sí he tenido que mantener muchas ya desarrolladas en el pasado, y también he utilizado autenticación de usuarios en web, pero a modo de BackOffice), pero si lo hago a partir de ahora, utilizaré Liberty (Liberty Alliance), ya que es el Identity Provider por excelencia que actualmente implementa estas tecnologías.

Aprovechando mi hambre de conferencias/charlas, y aprovechando también, válgame la redundancia, que la Fundación Mozilla ha decidido financiarme el viaje a Bruselas, al igual que a (casi) todos los colaboradores/localizadores europeos, me pasaré por el FOSDEM este fin de semana. Promete ser super-interesante, sobre todo porque tendré la oportunidad de refrescar mi inglés, porque estaré de nuevo con la gente de NAVE, y porque seguro conoceré otra gente muy interesante (de Mozilla/Mozilla-Europe, de Gnome, de Softcatalá... ¡incluso de Mono!, pues me he enterado por Monologue que el creador de Beagle va a estar allí).

Actualización sobre Single-Sign-On [30-AGO-2006]: Parece que Sun ha publicado un framework basado en esta tecnología, llamado OpenSSO, bajo una licencia semi-libre.

Labels: , , , ,


# posted by knocte @ 10:18 pm 0 comments

Monday, January 16, 2006

 

Otro proyecto: DUM

¿Usas algún servicio gratuito de hospedaje de zonas DNS? Yo uso EveryDNS.net, que es gratuito, fácil de administrar, y aporta más de dos servidores DNS. Los cambios que hagas se actualizan automáticamente en los cuatro servidores.

El problema viene a la hora de utilizar IP dinámica. Yo estaba utilizando DynDNS.org (también gratuito para subdominios) para hospedar dos dominios dinámicos para dos servidores con IP's públicas que tengo escuchando en internet. Si necesitaba asociar un dominio de primer nivel (no subdominio de dyndns) a alguno de ellos, aplicaba un campo CNAME en las zonas DNS correspondientes del servicio EveryDNS.net.

Pero recientemente la gente de EveryDNS.net descubrió que esta posibilidad rompía con el estándar DNS de los RFC's que dice que si un dominio es un CNAME de otro, éste debe contener los mismos campos, exactamente igual que el otro, es decir, incluso los campos NS. Esto significa que tendría que dejar de poder utilizar dos servicios distintos para el alojamiento de DNS dinámico (DynDNS y EveryDNS.net) conjuntamente y empezar a utilizar el propio servicio de EveryDNS.net para dominio dinámico.

La ventaja que yo tenía con DynDNS es que estaba usando un paquete de software muy conocido en el mundo del software libre para estos menesteres, como intermediario entre mis equipos y el servicio DynDNS. Este software es tan maduro y conocido hasta el punto de que creo que está incluido en la mayoría de las distribuciones: ddclient, aunque hay otros muchos que cumplen la misma función. Es muy sencillo de usar, tiene soporte para muchos servicios, para muchos modos de detección de IP pública (para esta funcionalidad, soporta muchos routers, aunque yo en realidad usaba la sencilla técnica de la web de chequeo para no complicarme la vida, aunque claro, tiene el inconveniente de que se depende de un servicio de un tercero), se instala como servicio del sistema y su periodo de chequeo es configurable.

Con EveryDNS.net sin embargo no se puede utilizar ddclient, pero sí un script muy sencillo hecho en Perl que es anunciado por el propio servicio en su página. El inconveniente es que este software no es tan extensible y no tiene tantas funcionalidades. Por ejemplo, no chequea que el dominio DNS tenga la IP correcta y así no actualizar el campo de la zona (con el consiguiente ahorro de tráfico y la reducción de riesgo de que un tercero obtenga la contraseña mediante un análisis de tráfico). Además, al estar hecho en Perl, soy muy reticente a la hora de hackear el código por mí mismo, porque no tengo una devoción muy grande por este lenguaje (he pasado muchos malos ratos con él).

Por eso, decidí crear mi propia herramienta de actualización de DNS. La he llamado DUM, abreviatura de DNS Update Manager o DNS Updates with Mono, porque, efectivamente, lo he hecho en C# con Mono, claro. Esta vez he decidido probar el gestor de proyectos Novell Forge, que también tiene soporte para Subversion como Berlios.

Si alguien está interesado en probar DUM, sólo tiene que bajarse el EXE o las fuentes para probarlo. Es una herramienta de consola, que usa la librería de Mono.GetOptions (gracias Rafael Teixeira ;) y es muy fácil de utilizar.

Lamentablemente, yo no lo puedo probar aún muy extensivamente porque estoy afectado por un bug que hay en el paquete de Mono de Mandriva que aún no he tenido tiempo de tracear (investigar); y que hace que el nivel de recursos del sistema crezca de una manera desmesurada si se usa cron para lanzar DUM. Así que los beta-testers son bienvenidos.

Labels: , , ,


# posted by knocte @ 12:51 am 1 comments

Tuesday, October 18, 2005

 

¿¿Tú te metes dentro de los ordenadores??

Bueno, esa es la típica frase que todos los que nos dedicamos a la informática, de un modo u otro, nos han formulado alguna vez o bien a menudo. Por supuesto que no se refieren a ser un "manitas" de las placas base, sino a si somos ese tipo de gente que no tiene otra cosa que hacer que aprovechar vulnerabilidades del software para conseguir acceso a equipos ajenos de manera remota.

Muchos resumirían esto en ser un "hacker". Otros corregirían a éstos diciendo que sólo son hackers si son intrusos que no aprovechan sus conocimientos para hacer ningún mal, sino solamente por satisfacción personal o curiosidad. Aquí entraría el término "cracker", que serviría para definir a los "hackers malos", que se meterían en los bancos o en la base de datos de su colegio para modificar sus notas.

Sin embargo, tras leer mucho en internet, parece que lo anterior no ha sido más que una acepción particular que han dado los medios de comunicación a estos términos. En realidad, un "hacker" es aquella persona amante de la tecnología que está continuamente aprendiendo y desarrollando sus habilidades con temas informáticos. El término cracker, pues, serviría para designar a dos tipos diferentes de personas: a) los que desarrollan desprotecciones para los programas de software privativo, de manera que se puedan eliminar las limitaciones de los programas shareware o versiones de evaluación; b) los que se entrometen en sistemas ajenos, ya sea con buenas intenciones o con malas.

Porque, sinceramente, aquellos que se meten en sistemas ajenos, ya sólo por el mero hecho de haberlo hecho, no creo que se les pueda tildar de santos o incluso siquiera sabios. Después de leer este magnífico comentario de BarraPunto, seguro que os queda mucho más claro. Y a pesar de que hay una respuesta a este comentario que también ha adquirido muchos puntos de moderación, esa respuesta no me quita la idea de que cualquier acto de intrusión no obedece necesariamente a una habilidad especial o admirable en estos menesteres. ¿Cuántas de estas personas serán realmente descubridoras de los agujeros de seguridad que utilizan para comprometer la seguridad de los servidores a los que acceden?

Labels: ,


# posted by knocte @ 4:36 pm 0 comments

This page is powered by Blogger. Isn't yours?

Categories

RSS of the category Gnome
RSS of the category Mono
RSS of the category C#
RSS of the category Programming
RSS of the category Mozilla
RSS of the category Web Development
RSS of the category Security
RSS of the category Open Source
RSS of the category Engineering
RSS of the category Misc
RSS of the category Politics

Contact with me:
aaragonesNOSPAMes@gnNOSPAMome.org

Archive

About Me

My Photo
Name:
Location: Hong Kong, Hong Kong

Follow me on Twitter