viernes, febrero 25, 2005
drivers de la controladora de HD tenemos:
/sbin/modinf -> Nos da info de un determinado modo
/sbin/lsmod -> Nos listará los modulos que tenemos cargados
/sbin/lspci -> Nos dirá información sobre los dispositivos PCI que tenemos
Luego otro muy util es /bin/dmesg, que nos muestra mensajes del kernel.
Otro comando util para scripts es seq, que nos servirá para generar una secuencia de numeros.
Y para acabar este post: 10 razones para usar Firefox.
miércoles, febrero 23, 2005
Mirando sobre para optimizar una configuracion de RAID en el curro, he aqui que tengo que comentar:
+ Este link:
http://es.tldp.org/Articulos-periodisticos/jantonio/vfs/vfs_1.html
+ Los parametros del kernel para modificar el
read-ahead estan en /proc/sys/vm (el min y el max)
+ Tb. se pueden consultar/modificar con blockdev o
hdparam (de /sbin)
+ Y otra: http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html
martes, febrero 22, 2005
Caida de Wikipedia
Es lo mas interesante de hoy de barrapunto. Y mas interesantes que los posts de barrapunto, son los de Slashdot.
viernes, febrero 18, 2005
jueves, febrero 17, 2005
Sobre monitorización
Me he estado empapando de sar. Y echando un vistazo a que otras herramientas tengo instaladas.
En las maquinas en las que estoy currando (Linux) tenemos sar, mpstat (cpu), iostat (entrada y salida) y vmstat (memoria virtual).
El sar viene junto a sadc (lo usa de backend), sa1 y sa2. Los dos ultimos son para usarse con el cron.
Tb. hay otro comando, isag, que no se para que sirve.
El mas completo de todo es sar, y con el podemos ver lo que nos dan los otros.
Lo malo es que da una monitorización total, no se puede hacer por procesos.
Con la opción -x se pueden monitorizar procesos, pero sólo una información determinada.
Para monitorizar el disco iostat está bien, pero para obtener los tiempos de espera, es necesario tener parcheado el kernel (la maquina en la que estoy no lo está). ¿Afectará dicho parcheado al rendimiento?
Todos estos comandos normalmente tiene 2 parametros, que son el intervalo en segundos a monitorizar y el numero de veces a hacerlo.
Aquí hay un script para sar que le pasa los siguienes flags (y saca la salida a un fichero; y cada segundo):
-b : ratio de transferencia de I/O
-d : actividad en sectores de bloques (numero de sectores)
-q : queue length and load averages
-r : estadisticas de memoria y swap
-u :utilización de CPU
-W: swapping
-n FULL: red
La opción -A de sar aparte de los anteriores mete :
-B: swapping
-c: creación de procesos
-R:estadisticas de memoria
-v: estado de inodos, ficheros y tablas del kernel
-w: estadisticas de swapping
-y: estadisticas de dispositivos TTY
-I SUM: estadisticas de interrupciones
-I PROC: estadisticas de interrupciones
sábado, febrero 12, 2005
emule
Aqui ando mirando como mejorar el rendimiento de la mula. Que tiene su cosa. Un link bueno.
A partir de él podemos acceder a otros.
Aparte de explicar en ellos determinados parametros, me ha llamado la atención el saber que los ISPs filtran las conexiones para darte por el rasca si usas emule. para ello usan una aplicación de p-cube. Que por cierto ha sido pillada por cisco.
Para acabar este post. Una de las primeras cosas a hacer es cambiar los puertos.
viernes, febrero 11, 2005
RAID
Una consulta al respecto.La definicion.
Este los explica muy bien.
Y otro link, que no he mirado. Solo ojeado por encima.
martes, febrero 08, 2005
Sobre certificados de FNMT
Esta es la url: http://www.cert.fnmt.es.
Yo lo tenia, pero ahora mismo entre reinstalaciones de ordenadores y movidas ya no. Con lo cual a pedirlo de nuevo.
Ya lo he solicitado => siguiente tramite ir a AEAT.
Una vez hecho el proceso fisico, te lo puedes descargar. El certificado se te instala en el ordenador => lo primero que hay que hacer es exportarlo. Se puede exportar con clave privada o sin ella. He aqui la diferencia:
Ud. deberá exportar el certificado con su clave privada solo para su uso personal o como copia de seguridad.
La clave privada servirá para realizar firma digital.
El certificado sin la clave privada podrá exportarlo para entregarlo a todo aquel que quiera comunicarse con Ud. de forma segura.
Importante: Haga copia de seguridad a disco de su certificado junto con la clave privada y guárdela en lugar seguro. Nunca entregue copia de su clave privada a nadie bajo ningún concepto.
Es importante exportarlo en un formato que entienda tanto Netscape como Exporer, el PKCS #12 (.PFX).
Es necesario que nuestro navegador soporte encriptación con 128 bits (si estamos actualizados a navegadores recientes, lo estará).
En la url anterior se pueden consultar muchas cosillas, ya que tienen una 'base de conocimiento', con preguntas mas frecuentes.
Para descargarse el certificado:
El certificado raíz de FNMT Clase 2 CA se obtiene en la siguiente página: http://www.cert.fnmt.es/certifi.htm. Una vez en la página, descargaremos el certificado haciendo click sobre el link: Descarga del Certificado Raíz de FNMT-RCM Certificado de Usuario, en cuyo caso se le mostrarán las instrucciones precisas dependiendo de su navegador
También puede descargar el certificado raíz directamente pinchando aquí. Ha de seleccionar la opción 'Abrir este archivo desde su ubicación actual' en el caso de Internet Explorer y siguiendo las instrucciones en todos los casos.
Y ya unas ultimas cosillas:
Si en el momento de la solicitud se aportó la dirección de correo electrónico, los certificados emitidos desde el 6 noviembre del 2000 poseen las características necesarias para que pueda ser utilizado en su correo.
Para poder utilizar su certificado este debe tener ciertas características, la principal es que tenga una dirección de correo electrónico incluida en el propio certificado según lo establecido por el protocolo S/MIME descrito en el RFC 1521 (http://www.ietf.org/).
Si el certificado no tiene ninguna dirección de correo asociada, y si Ud. desea utilizar las ventajas que ofrece este tipo de correo, deberá solicitar la revocación del antiguo y solicitar otro certificado por los procedimientos habituales, pero aportando su dirección de correo electrónico.
Como dicen, el certificado para poderse usar para firmar correos digitalmente, debe de tener la dirección de correo. El mio desde luego no lo tiene, ni lo va a tener => me va a tocar revocarlo y volverlo a pedir :(. Siempre esta la opción de pedirlo a otra entidad certificadores
lunes, febrero 07, 2005
Sobre encriptacion
Respuesta segunda del colega de Isra (sobre lo de detectar el algoritmo):
No.
Cuando cifras algo incluyes información sobre el algoritmo usado (los famosos formatos PKCS o algo similar) de forma que no mandas directamente el chorro de datos sino que va con su cabecera que dice método, etc. etc.
Pero si cifras algo a lo bestia (a lo Ibarretxe, vamos) y no dices que método de cifrado has usado, lo que tienes es un auténtico galimatias.
Podría hacerse algo para intentar acotar la familia y quizá algo más haciendo algún estudio matemático, por la longitud del bloque, y siempre que pensemos que buscamos entre los algoritmos conocidos, podriamos intentar algo, pero vamos, no lo veo factible. Con cifrados clásicos sí que sería relativamente fácil (Cesar, Vigenere, etc.) pero si te vas a los métodos modernos (Safer, DES, 3DES, Blowfish,......) vas de craneo´porque además puedes haber usado métodos para que un bloque cifrado dependa del anterior y cosas así de raras que usa esta gente. Por ganas de dar por saco y aunque no aumenta la seguridad puedes pasarlo por dos algoritmos, meter información que no aporta nada,... luego tienes que aún sabiendo el algoritmo puede estar usando longitudes de clave o de bloque diferentes,....
Vamos que ni de coña.
Sobre el certificado PKCS #12
Una FAQ al respecto.
Es el certificado que hay que usar para exportar de IE e importar con el Firefox.
Para exportar te indican: Make sure the Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above) check box is checked.
Para importar te indican:
- Supply the password you used when you created the PKCS #12 file.
- Make sure the Enable strong private key protection check box is checked.
- Make sure the Mark this key as exportable check box is checked.
sábado, febrero 05, 2005
Post antiguos sobre encriptacion
Vaya, habia metido lo siguiente por error en otro weblog...
Sobre detección de un bloque encriptado
Del grupo scri.crypt. El thread.Esta muy interesante el hilo.
Según dicen es posible detectarlo, pero siempre habrá errores. Se supone que la detección es automatica, mediante un programa.
El primer problema, es cuantos fallos habrá, pero más atún, cuantos megas al dia de fallos habrá.
Tambien comentan que se usa mucho el uuencode y uudecode. Esto añade la problematica de que no sabes eltipo de fichero que va.
Esta parrafada es muy interesante:
ne way to avoid encryption detection is by a variation of the old microdot
routine.
1. Digitize some old, grainy photo
2. Replace bit k*n of the photo with bit k of the encoded message; where n
is some constant ~ 60.
With even a modest computer, no need to securely transmit the constant n. The
recipient just tries them all.
Clearly, this method does not conserve bandwith.
Our photo eMicrodot (tm) can be compressed anbd viewed as a regular photo.
For a special treat for the boys from Justice, use a picture of J. Edgar in
drag. ¡Ah! Al principio del thread, mencionana a 'Eve'. No se si se tratará de una aplicación.
Y este otro:
...probably wasn't even the first to propose this, but I wrote
articles in sci.crypt in 1988-89 about the "LSB method," wherein
messages, presumably encrypted, are placed in the least significant
bit of a GIF or other image, or in the LSBs of digital audio tapes.
(Cf. Kevin Kelly's article in "Whole Earth Review," Summer 1993, or in
his new book, "Out of Control," for a description.)
A version of this was hacked in PhotoShop, by me.
Several "stego" (steganography, which is of course what this is)
programs now exist, notably "JSTEG" (pun on JPEG) and "Stego."
Romana Machado's "Stego" program for the Mac has gotten a fair amount
of attention. I think it's available at the sumex.stanford.edu archive
site.
Interestingly, law enforcement types are speculating that the computer
porn folks using the Lawrence Livermore Labs computers were using the
LSB method to smuggle out defense secrets. I doubt it pretty strongly. Y...
Otro thread, sobre detección de 'ciphertext'.
Esta parrafada es buena:
"Any decent crypto software produces a perfectly uniform distribution,
i.e. totally random-looking data. Any automatic crypto-detection
software would be looking for known crypto-headers or uniformly-
distributed data after all other headers.
To increase NSA's computers workload, you may simply add layers of
encoding or compression, like uuencode .zip .arj .tar etc.
Since there's a bewildering amount of data formats and software,
trying to match a file's distribution with the typical one is a
daunting task. The file may be too small to detect a significant
difference, and many won't even be recogniced.
So it's possible to foil automatic cryptogram detection by padding
files with non-randomly distributed garbage. The garbage may be
chosen to imitate the distribution of common formats (wich may be
difficult) or simply with a different pattern each time.
The bottom line is that *detecting* a message may be as hard as
cracking a cipher. For that reason, personal-ads in papers and
even flower orders were forbidden in WWII. So what chances have"
spys against the gigantic Usenet?"
Y ya para acabr por hoy, un concepto, steganography. Es el hecho de ocultar un mensaje.
viernes, febrero 04, 2005
Haciendo ya busquedas mas correctas, al final he conseguido articulos interesantes de DDJ y CUJ (he buscado por 'random' y 'statistical analysis').
De DDJ:
- Heads I Win, Tails You Lose.
- A fast pseudo-random number generator.
- Pseudo-random sequence generator for 32-bits cpus.
- Truly Random Numbers.
- Testing Random Number Generators.
- Testing Random Number Generators, Part 2.
- A Class Hierarchy for Random Number Generation.
- Quick and Portable Random Number Generators.
- A Pseudo-Random Number Generator.
Statistical testing of random number genrators
Llevo poniendo ultimament muchos post sobre este tema :(. Bueno ha sido un procesos de busqueda larga, pero al final la busqueda ha sido fructifera.
Un articulo al respecto.
Una pagina con links al respecto. Entre ellos esta la Testing Suite del NIST.
Aqui esta Diehard. E info al respecto.
Y aqui esta Dieharder. Que no se si es util
Buscando por 'Diehard tests' en google se obtiene bastante info.
Randomness in the ciphertext
Un thread al respecto. Esta muy interesante ya que de él, he obtenido (al fin) lo que estaba buscando, una aplicación que haga analisis estadísco de 'ciphertext', FineCrypt. Es interesante otro programa que menciona, Yarrow. Lo usa para generar ficheros con contenido pseudo-aleatorio.
FineCrypt la verdad es que tiene muy buena pinta. Lo malo es que el analisis estadistico se hace dentro del GUI, por lo que no serviría. Necesito un comando. De todas formas si al final acabo desarrollando uno, puede servir para comparar.
La pregunta que lanza el tio (tras una introduccion):
My question is: is randomness of cyphertext a reasonable measure of actual encryption strength, or is it just another item muddying theVoy a intentar extraer las parrafadas mas interesantes. Eso si, vete a saber si son afirmaciones ciertas todas.
water?
+ "It is not a reasonable measure..."
+ "For messages that are much longer than the key, the ciphertext is about as random as
the corresponding plaintext."
+ "> Results are along the lines of "The file content is almost
> certainly not random" or "The file content is almost certainly random."
"The former makes sense but the latter doesn't. What "randomness" tests
determine is whether the observed data is consistent with the hypothesis
that it is generated by a random source. It is possible to attribute a
likelihood for deviation from the model, but not for conformance to it."
+ " Beware. I looked at FineCrypt about a year ago and it had many
implementation errors that do not inspire confidence. The "randomness"
tests are pretty basic compared to what is availiable... Check out the NIST
test suite, Diehard, DiehardC FIPS 140."
+ "It is becoming increasingly clear that the best way to test the
programs is with the test vectors."
+ "
The
randomness of the output depends both on the input and the cypher. No
distinction is made by the questioner. He simply took a few outputs and
measured their randomness and found some to be random, according to some
stupid test, and other not. He asked if the output's being random
according to his unknown test, could
be used to infer something about the strength of the cypher. The answer is no.
One reason is that the output also depends on the input (the whole point
of the argument) . Another is that
no small key cypher has truely random output with non-random input, since there is a
simply algorithm (the decryption) which will produce the non random
input from the output. However, no stupid randomness test will ever
discover this unless the cypher is very very very weak."
+ "
>The
> randomness of the output depends both on the input and the cypher.
Not with RC4, unless "Input" has now been changed to include the
key."
jueves, febrero 03, 2005
Esta hecha por españolitos.
Aclarando conceptos
Ya para acabar con todo este tema de la criptografica, voy a aclararme unos conceptos.
Por un lado tenemos la criptografia (cryptography) y el criptoanalisis (cryptanalysis). Ambas forman la criptologia (cryptology).
Por otro lado tenemos la 'steanography' y la 'steganalysis'.
Unas cifras sobre logitudes de claves
Según he leido los algoritmo no simetricos (de llave publica) deben de tener una longitud de clave mayor que los simetricos para la misma seguridad.
En los asimetricos, se consideran seguras hasta las siguientes fechas las longitudes:
- 1024 hasta 2010
- 2048 hasta 2030
- 3072 mas alla del 2030
En los simetricos creo que se considera seguro 256.
Creo que con DES se está usando 112 bits y con AES 128. El govierno de USA recomienda para AES 192 o 256.
Para acabar. De los asimétricos, la 'elliptic curve cryptography' necesita menores longitudes de clave.
En sourceforge.net, con la busqueda adecuada (cryptanalysis), ya obtengo resultados. Bien!!! No hay nada como buscar con las palabras adecuadas. Pero no veo nada de lo que me interesa, que es detectar que algo está encriptado.
He aqui, la primera busqueda exitosa. En muy informativo:
"There is an automated statistical software package (ATS) that can do an
excellent vertical differentiation and a reasonable horizontal
differentiation of about 75 different commercial cipher systems based on
analysis of ciphertext or suspected ciphertext. It also tests the random
number generation, based on standard NIST FIPS 140-1,2 standards. I have
used it in my consulting and improved it for several years ( as the various
cipher systems have grown/ changed or introduced). I have been able to
detect changes in product offerings and detect encrypted traffic in
some very sensitive assignments. ATS can be used to look at network traffic
and packetized traffic and has various options to pear down the headers to
get to the VPN or IPSec traffic.
ATS has some limitations. Steganography laced with 3DESor RC5 yields
signatures that are more difficult to interpret. I have only characterized
Rijndael (my favorite) and Twofish in the current AES 5-finalist group. ATS
is not as rigorous as the NIST tools and is not used for certification at
NIST levels.
indistinguishable. However, implementations are not perfect and platforms
respond differently. The latter two permit statistical and probabilistic
analysis of the various cipher product offerings.
My "ICSA Guide To Cryptography," McGraw Hill, 1999 has a brief discussion in
Chapter 21."
Tras ella penseé que iba a encontrar algo, pero nada. De momento mis intentos han sido infructuosos. He intentado google, ddj, cuj y sourceforge.net
A ver si otro dia estoy mas inspirado buscando. Algo tiene que haber...
Por lo visto CSIM es un certificado de seguridad y CISA de auditoria.
Otra pagina sobre steganalysis.
WetStone es una empresa que tiene varios productos, de steganalysys.
Leyendo sobre la empresa veo que hay un termino que se usa para este tipo de investigacion 'digital forensics'. Bueno el producto que interesa (tienen mas) es Stego Suite. Cuesta $1.995. La suite se compone de dos productos, Stego Watch y Stego Analyst, que hacen lo que su nombre sugiere.
Aparte tienen otro producto para detectar Malware, Malicious Software; Gargoyle.
Esta también es interesante, ya que:
- Afirman que el 'statistical stegoanalysis' ya no es eficaz para la detección.
- Y tienen montado un framework para detectar imagenes en la web. Usan un crawler libre para ello. Luego usan stegdetect y finalmente 'stegbreak' (esto no se lo que es :( ).
Y una ultima[forensics.nl] pagina. Ya estoy un poco saturado.... y en esta hay muchisimos articulos en pdf. Y su hermana para watermarking. Este sitio parece estar muy bien, cubriendo el tema de 'Computer Forensics'.
Esta[stegoarchive.com] es otra pagina que he encontrado al respecto. Tiene bastantes productos sobre para hacer 'stegoing' y algunos para hacer 'unstegoing' o detección. Como por ejemplo:
- stirmark. Se dispone como binario y en codigo fuente (C/C++). Es una 'suite' para probar esquemas de 'watermarking'. Creo que necesita lo marcado y el original.
- stegdetect (solo para jpeg)
En la pagina de stegdetect [ourgess.org] se pueden encontrar articulos al respecto (de steanography) y links.
Buscando en google, sobre 'steganography detection' obtengo resultados, pero de todas formas sobre encryption detection, no.
Si se quiere detectar mensajes ocultos en la red, habrá que hacer:
+ En primer lugar mirar si sobre el bloque de datos se ha aplicado alguna técnica de ocultación (steganography).
+ O bien si los datos estan encriptados.
Con esto ya tendriamos detectado, contenido sospechoso.
Hay que tener en cuenta que ademas de aplicar ocultación, posiblemente los datos ocultos pueden estar cifrados.
Por cierto, un concepto relacionado con 'steganography' es watermarking.
Al final no he encontrado nada en ddj, pero este articulo tiene buena pinta.
Lo que me ha resultado curioso de ddj es que ahora no te dejan ver los ultimos números, pero de los antiguos si.
Aqui hay uno del Alexandrescu sobre el Double-Checked Locking. Y la primera parte del mismo.
Mas sobre la detección de datos criptograficos
He preguntado en Kriptopolis, a ver si me responde alguien.
Ya me han respondido en scr.crypt. Me indican, que en ddj salio algo hace poco.
There was a related article in the last few months in Dr. Dobb's Journal, but I
don't have that issue right at hand...
Basically, encrypted data looks random, so testing a block for randomness will
help to find ciphertext, but it will also find compressed blocks of data which
also look random.
Habrá que buscar en ddj a ver si veo algo...