Mais um blog inútil.

Oi!

Segundo a LISP Police, vim a saber que a primeira arvorezinha em LISP do _Lone_Wolf_ não cumpria os standards definidos pelo rfc da arvorezinha, e ele para não sofrer as consequências redimiu-se com uma versão totalmente standard. Aqui vai ela:

  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8
Welcome to GNU CLISP 2.47 (2008-10-23) <http://clisp.cons.org/>
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2008
Type :h and hit Enter for context help.
[1]> (loop
    (loop for i from 1 to 4 do
        (loop for j from 1 to i do
            (write-char #\*)
        )
        (terpri)
    )
    (return '*****)
)
*
**
***
****
*****

Blogosphere is just multiplayer copy & paste.

Que raio.

Quero fazer uma coisinha simples, uma directoria partilhada para toda a gente com acesso a leitura/escrita e deparo-me com uma complicação extrema de um ficheiro de configuraçao de samba por default em Debian completamente ilegivel, confuso e com um monte de “features” e comentários inúteis em que só me apetece pegar fogo ao ficheiro. Para não falar dos exemplos que não funcionam se nao Desactivarmos/Activarmos/Re-activarmos algumas opções que estão 34843 linhas acima.

Aqui está a receita para o que eu quero:

pidgeon:~# cat /etc/samba/smb.conf
[global]
workgroup = devnull
server string = Public Share 
netbios name = pidgeon
security = share
smb passwd file = /etc/samba/smbpasswd

[public]
guest ok = yes
guest only = yes
#guest account = ftp
path = /opt/shares/public/
writeable = yes 

Simples, hein?
Fantasticamente isto não vem no ficheiro de default do debian como um dos exemplos…

pidgeon:~# wc -l /etc/samba/smb.conf
13 /etc/samba/smb.conf
pidgeon:~# wc -l /etc/samba/smb.conf.old 
337 /etc/samba/smb.conf.old

337 linhas de lixo. Obrigado!

Ora viva!!!

Há dias o senhor mirage fez um req para meter a administração do blol por ssl. Então segui a bela da FAQ do OpenBSD (Setting up a Secure HTTP server with SSL) e criei um certificado como explicam lá pus o login por https.

Mas no dia seguinte o dongs disse que com 1024 não se sentia seguro, e eu também achei que ele tinha razão, então picado por ele decidi criar um certificado de 16384 bits, porque I CAN REALLY NOTICE THE DIFFERENCE!

Depois de umas três horas a gerar, la pus a bombar e fui testar.

Então com a minha surpresa, o magnifico Firefox, a jóia da coroa do Open Sores, passa-se a processar o certificado. Clicko no link para fazer login, ele fica 20 segundos a pensar e depois mostra-nos esta mensagem bonita.

A seguir o Internet Explorer, tenho a versão 8 beta 2, fica também por volta de 20 segundos a pensar, mas depois lá nos mostra a página. E quase que aposto que o IE6 também funciona.

O Chrome também leva 20 segundos a pensar e depois abre.

Ate o clássico lynx abre bem :-P

O problema do Firefox em Windows IMEO é que não usa a *carteira* de certificados do Windows e implementa ele uma, e o fail surge daí.

Achei necessário vir blogar sobre isto, porque muitos dos blogers aqui usam o Firefox o que me faz baixar o tamanho do certificado. Talvez para 4096 bits ;-)

Bom dia. Tenho, com alguma tristeza, assistido ao flagelo que o Twitter se tornou nos últimos tempos. Esta actividade inútil, ’twitar’, fomentou a minha última criação: o kryptwit. A prova viva que inutilidade gera inutilidade.

Esta biblioteca tem como função cifrar updates do twitter, por forma a poderem apenas ser lidos pelos possuidores de uma password adequada. O RFC que proponho é o seguinte:

Mensagens de entrada - Não podem ultrapassar os 100 bytes (isto inclui caracteres unicode que podem ocupar mais de 1 byte) de tamanho.

Mensagem de saída - Tem exactamente 139 caracteres ASCII de tamanho. Tem como prefixo “;-) “. Os seguintes 10 caracteres (em Base 85) correspondem ao IV utilizado. Os restantes caracteres, também em Base85, correspodem à mensagem propriamente dita.

Algoritmo para cifração - AES no modo CTR (RFC3686), chave de 256 bits.

Derivação de chave - Password de tamanho arbitrário (até 2^32 bytes), ‘salt’ consiste no nome do utilizador que envia a mensagem. O algoritmo utilizado é o PBKDF2, 1000 iterações, SHA-256.

O IV tem apenas 64 bits. Esta escolha foi feita para contrabalançar a probabilidade de colisões (2^(n/2)) com o tamanho roubado à mensagem. 64 bits dá-nos um bom balanço entre 10 chars e 2^32 mensagens por colisão, em média.

A implementação foi feita em C, recorrendo às implementações excelentes do Brian Gladman do AES, SHA-2 e companhia. O resultado é algo pouco retocado, mas parece funcionar.

Download.

A aplicação de exemplo, sample.c, pode ser utilizada para cifrar e/ou decifrar mensagens. A utilização é simples:

sample e/d username password mensagem

Apresento agora um exemplo de funcionamento:

C:\kryptwit>sample.exe e dongs morte "ola sirs"
;-) lyqf(mXkLw&xU[53F8fP#Owitr}o6VVMAsf[C,h$POG=(M{u9sDT9t68Tfgj{RM}k6sGG.[n#V4i(jbdmp-FLxr#ENS`+Djv
(zV+t*imiCz=Aj]H39iRKcImO&DcSsmqZu-.f#F

C:\kryptwit>sample.exe d dongs morte ";-) lyqf(mXkLw&xU[53F8fP#Owitr}o6VVMAsf[C,h$POG=(M{
u9sDT9t68Tfgj{RM}k6sGG.[n#V4i(jbdmp-FLxr#ENS`+Djv(zV+t*imiCz=Aj]H39iRKcImO&DcSsmqZu-.f#F"
ola sirs

Divirtam-se!

EDIT: Disponibilizei uma nova versão (no mesmo link), com 1 bugfix menor e um Makefile e binario para Unix (amd64).

Em conversa há dias com o falso, mostrei-lhe uma calculadora de bitrate que tinha feito há (N) anos, toda em Win32 assembly. Escusado será dizer o desperdício de tempo que foi. Fiquei, no entanto, triste por ter perdido o código original da mesma; aquilo era até bastante complexo, para o efeito que era.

Para não perder mais lixo que fiz no passado, sempre que o encontrar por aqui vou postando. Neste post coloco o CryptoFrame, uma aplicação modular que fiz para servir de workbench para as várias experiências que ia fazendo. Como sempre, nunca foi acabado nem passou da primeira versão, 0.1. Mesmo assim, há quem tenha achado isto útil por alguma razão que me ultrapassa.

A versão inicial continha um plugin para brincar com curvas elípticas e assinaturas digitais com as mesmas, um plugin para calcular hashes de strings ou ficheiros e uma calculadora de precisão arbitrária com base na biblioteca GNU MP.

Download.

Lembram-se de todo o drama quando criaram certificados falsos a partir de colisões de MD5?

Aparentemente a resposta dos principais CAs foi rapidamente migrar para SHA-1, mesmo sabendo que já não era inteiramente seguro (reparem na data). Na altura eu disse que era má ideia, mas agora a situação piorou:

SHA-1 Collisions now 2^52. Infelizmente o artigo completo ainda não foi publicado, deixando os detalhes do ataque em aberto. Ainda assim, os autores são credíveis e os resultados vão ser apresentados na Eurocrypt 2009 pelo Greg Rose, autor de um dos candidatos ao SHA-3.

Para quem argumentar que este tipo de ataques não é practicável, vamos fazer as contas (tm). A implementação do SHA-1 presente no OpenSSL precisa de cerca de 768 ciclos num processador actual (Q6600). Isto num processador de 3 GHz e 4 cores dá-nos cerca de 16 milhões de iterações por segundo, i.e. ~2^24. Num único processador, isto levaria demasiado tempo, cerca de 8 anos. Mas num cluster de 1024 destes processadores, não tão incomum quanto isso, levaria cerca de 3 dias. Isto ignorando implementações optimizadas para o efeito e chips mais apropriados para o efeito, e.g. Cell, GPU, FPGA, ASIC, …

Assim, recomendo Calgon em todas as lavagens que o SHA-1 deixe de ser utilizado para assinaturas digitais. Para autenticação simétrica (e.g. HMAC) e geração de números aleatórios estes resultados são de relativamente pouco interesse.

P.S. Esta implementação parece atingir os 213 ciclos por compressão, diminuindo drasticamente os custos descritos acima.

Viva amigos.  Numa noite lenta como esta, decidi ceder aos pedidos de uma arvorezinha em brainfuck segundo as regras, isto é, sem ser hardcoded. E aqui está. Aviso desde já que podia ser reduzida pelo menos uns 20% com alguns melhoramentos mais ou menos óbvios, mas não tenho paciência para essas coisas. Podem alterar o número de iterações na quarta sequência de ‘+’.

++++++++++>++++++[>+++++++<-]>>++++++[>+>+<<-]>>[<<+>>-]+
[>+>+<<-]>>[<<+>>-]<[<<->>-]<[>+>+<<-]>>[<<+>>-]<<<[>>[<<
<<.>>>>-]<<<<<<.>>>>>><+[>+>+<<-]>>[<<+>>-]<[-]<<[-]<[>+>
>+<<<-]>>>[<<<+>>>-]<[>+>+<<-]>>[<<<->>>-]<[>+<-]>[<+<+>>
-]<<<]

Um grande bem-haja!

Palavras para quê….