<rss version="2.0"
     xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:dc="http://purl.org/dc/elements/1.1/">
        <channel>
        <title>Magazine - rsa</title>
        <link>https://www.genbeta.com</link>
        <description>Publicación de noticias sobre gadgets y tecnología. Últimas tecnologías en electrónica de consumo y novedades tecnológicas en móviles, tablets, informática, etc</description>
        <pubDate>Tue, 09 Jun 2026 21:17:14 +0000</pubDate>
        <generator>https://www.genbeta.com</generator>
        <atom:link href="https://www.genbeta.com/tag/rsa/rss2.xml" rel="self" type="application/rss+xml" />
                                        <item>
                <title><![CDATA[Tor se actualiza: nueva versión estable y mejoras en la seguridad y el cifrado]]></title>
                <link>https://www.genbeta.com/seguridad/el-navegador-tor-se-actualiza-nueva-version-estable-y-mejoras-en-la-seguridad-y-el-cifrado</link>
                <guid>https://www.genbeta.com/seguridad/el-navegador-tor-se-actualiza-nueva-version-estable-y-mejoras-en-la-seguridad-y-el-cifrado</guid>
                <pubDate>Fri, 28 Apr 2017 15:31:29 +0000</pubDate>
                                         <dc:creator>Sergio Agudo</dc:creator>
                                       <description>
                    <![CDATA[
                              <p>
      <img src="https://i.blogs.es/16c013/2560_3000/1024_2000.jpg" alt="Tor&#x20;se&#x20;actualiza&#x3A;&#x20;nueva&#x20;versi&#x00F3;n&#x20;estable&#x20;y&#x20;mejoras&#x20;en&#x20;la&#x20;seguridad&#x20;y&#x20;el&#x20;cifrado">
    </p>
    <p>Después de haber estado en desarrollo durante los últimos meses, <strong>Tor 0.3.0.6 es la nueva versión estable</strong> del proyecto, que tendrá soporte durante nueve meses, tal y como han anunciado en un <a rel="noopener, noreferrer" href="https://blog.torproject.org/blog/tor-0306-released-new-series-stable">comunicado</a>. Con ella llega una nueva serie de mejoras y características.</p>
<!-- BREAK 1 -->
<p>Vale la pena recordar que con la llegada de las versiones estables de la serie 0.3.0 <strong>se ha dejado de usar el cifrado RSA1024</strong> para los relevos y los clientes, que a partir de ahora usarán claves Ed25519 para autenticar sus conexiones a los relevos.</p>
<!-- BREAK 2 --><!--more--><p>Más aún, las versiones 0.3.0 de Tor ahora está preparando las <strong>bases para la próxima generación de servicios ocultos</strong>. Para ello, habilita la gestión de células ESTABLISH_INTRO v3, junto con soporte para el protocolo HSDir versión 3 para todos los relevos de Tor, permitiendo almacenar y servir descriptores de dicha versión.</p>
<!-- BREAK 3 -->
<p>Otras características implementadas en Tor 0.3.0.6 que vale la pena mencionar es una mejor resistencia a <strong>ataques de correlación basados en DNS</strong>. Esto se ha conseguido cambiando el algoritmo usado para determinar los TTLs de los DNS para los servidores y los clientes.</p>
<!-- BREAK 4 -->
<p>El tráfico IPv6 ahora <strong>está habilitado por defecto en SocksPort</strong>, se ha inyectado un modo "check_existing" en el script updateFallbackDirs.py (que comprueba si los servidores de respaldo de la lista funcionan correctamente o no), y ahora Tor soporta un rango más amplio de suites de cifrado, incluyendo AES-CCM y chacha20-poly1305.</p>
<!-- BREAK 5 -->
<p>Se emplearán además dos opciones para permitir la <strong>separación del tráfico de salida y de los relevos</strong> a diferentes fuentes de direcciones IP. También se ha aumentado la longitud de la clave RSA usada para la autenticación de enlaces TLS a 2048 bits.</p>
<!-- BREAK 6 -->
<p>Vía | <a rel="noopener, noreferrer" href="https://blog.torproject.org/blog/tor-0306-released-new-series-stable">Tor</a><br />
En Genbeta | <a class="text-outboundlink" href="https://www.genbeta.com/navegadores/como-navegar-de-forma-anonima-en-internet-con-tor-browser" data-vars-post-title="Cómo navegar de forma anónima en Internet con Tor Browser" data-vars-post-url="https://www.genbeta.com/navegadores/como-navegar-de-forma-anonima-en-internet-con-tor-browser">Cómo navegar de forma anónima en Internet con Tor Browser</a></p>
<script>
 (function() {
  window._JS_MODULES = window._JS_MODULES || {};
  var headElement = document.getElementsByTagName('head')[0];
  if (_JS_MODULES.instagram) {
   var instagramScript = document.createElement('script');
   instagramScript.src = 'https://platform.instagram.com/en_US/embeds.js';
   instagramScript.async = true;
   instagramScript.defer = true;
   headElement.appendChild(instagramScript);
  }
 })();
</script>

                    ]]>
                </description>
            </item>
                                <item>
                <title><![CDATA[Así es la seguridad en Mega: no es tan buena como dice ser]]></title>
                <link>https://www.genbeta.com/seguridad/asi-es-la-seguridad-en-mega-no-es-tan-bueno-como-dice-ser</link>
                <guid>https://www.genbeta.com/seguridad/asi-es-la-seguridad-en-mega-no-es-tan-bueno-como-dice-ser</guid>
                <pubDate>Mon, 21 Jan 2013 08:01:12 +0000</pubDate>
                                         <dc:creator>Guillermo Julián</dc:creator>
                                       <description>
                    <![CDATA[
                              <p>
      <img src="https://i.blogs.es/4073dc/megarsa/1024_2000.png" alt="As&#x00ED;&#x20;es&#x20;la&#x20;seguridad&#x20;en&#x20;Mega&#x3A;&#x20;no&#x20;es&#x20;tan&#x20;buena&#x20;como&#x20;dice&#x20;ser">
    </p>
    <p>El sábado, Mega, el sucesor de Megaupload, <a class="text-outboundlink" href="https://www.genbeta.com/almacenamiento/mega-ha-llegado-saluda-al-nuevo-servicio-de-almacenamiento-sucesor-de-megaupload" data-vars-post-title="Mega ha llegado. Saluda al nuevo servicio de almacenamiento en la nube, sucesor de Megaupload" data-vars-post-url="https://www.genbeta.com/almacenamiento/mega-ha-llegado-saluda-al-nuevo-servicio-de-almacenamiento-sucesor-de-megaupload">salió al público</a>. Una de las características más llamativa es lo seguro que dicen que es. Los archivos se cifran en tu ordenador, Mega no sabe qué estás guardando, estás totalmente protegido... Al menos, eso es lo que podríamos adivinar. Pero, <em>¿qué nivel de seguridad tiene Mega en realidad?</em> ¿Es todo palabrería o estamos hablando de un salto que nadie más ha hecho? </p>
<!-- BREAK 1 --><!--more--><p>Antes de nada, me gustaría aclarar que de lo que vamos a hablar aquí es <em>de la seguridad del diseño</em>. Ya en las primeras horas se han descubierto fallos en el cliente web de Mega: es <a rel="noopener, noreferrer" href="https://twitter.com/z0mbiehunt3r/status/292701436834365441">vulnerable a XSS</a> con los nombres de archivo, no tiene HSTS, una cabecera que fuerza que todas las conexiones al sitio sean por HSTS; ni tampoco usa <a rel="noopener, noreferrer" href="http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions">DNSSEC</a>. También se ha detectado que el generador de claves no es precisamente aleatorio: usa el generador de números aleatorios de Javascript, que es predecible. Sin embargo, estos son fallos relativamente sencillos de corregir, y hay que tener en cuenta que Mega salió ayer y habrá que darles tiempo a cambiar cosas. Lo que es permanente es el diseño, y esto es lo que vamos a explorar.</p>
<!-- BREAK 2 -->
<h2>¿Cómo funciona el cifrado simétrico y asimétrico?</h2>

<p><div class="caption-img"> </p>
<div class="article-asset-image article-asset-normal article-asset-center">
 <div class="asset-content">
                   <img class="centro_sinmarco" height=314 width=650 loading="lazy" decoding="async" sizes="100vw" fetchpriority="high" srcset="https://i.blogs.es/ee2390/asymmetric/450_1000.webp 450w, https://i.blogs.es/ee2390/asymmetric/650_1200.webp 681w,https://i.blogs.es/ee2390/asymmetric/1024_2000.webp 1024w, https://i.blogs.es/ee2390/asymmetric/1366_2000.webp 1366w" src="https://i.blogs.es/ee2390/asymmetric/450_1000.webp" alt="Cifrado asimétrico" onerror="this.src='https://i.blogs.es/ee2390/asymmetric/450_1000.png';this.srcset='https://i.blogs.es/ee2390/asymmetric/450_1000.png 450w, https://i.blogs.es/ee2390/asymmetric/650_1200.png 681w,https://i.blogs.es/ee2390/asymmetric/1024_2000.png 1024w, https://i.blogs.es/ee2390/asymmetric/1366_2000.png 1366w';return false;">
   <img alt="Cifrado asimétrico" class="centro_sinmarco" src="https://i.blogs.es/ee2390/asymmetric/450_1000.webp">
   
      </div>
</div>
<p><span>Esquema de funcionamiento del cifrado asimétrico</span> </div></p>

<p>Para poder entender bien cómo funciona el cifrado de Mega, antes voy a explicar brevemente <em>qué es el cifrado simétrico y asimétrico</em>. En el cifrado simétrico, ciframos el archivo con una clave X. Para descifrarlo y obtener el archivo original, utilizamos la misma clave X. Es un concepto muy sencillo y básico.</p>
<!-- BREAK 3 -->
<p>El <em>cifrado asimétrico</em> es más complicado. Aquí no tenemos una sola clave común. En su lugar, cada persona tiene dos claves, una pública y una privada. Para enviarle un archivo a un amigo, lo cifras con su clave pública. De esta forma, sólo lo puede descifrar él con su clave privada. Es más seguro que el cifrado simétrico, ya que la clave de descifrado (la privada) nunca se comparte, siempre la tiene el receptor. </p>
<!-- BREAK 4 -->
<p>Lo malo de esto es que el cifrado asimétrico es mucho más caro en términos de computación. Por eso, en ocasiones se usan combinaciones más eficientes. Por ejemplo, la generación de una clave simétrica usando los pares claves públicas/privadasa: primero, combinas tu clave privada y la clave pública del receptor para obtener la clave de cifrado X. El receptor hace lo mismo con su clave privada y tu clave pública, obteniendo la misma clave X. Entonces, se usa esa clave X para cifrar de forma simétrica el archivo. Este sería el concepto básico, aunque por supuesto hay algoritmos más elaborados, como el <a rel="noopener, noreferrer" href="http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange">intercambio de claves Diffie-Hellman</a> para dos usuarios puedan generar la misma clave a partir de las claves públicas y privadas. </p>
<!-- BREAK 5 -->
<p>Por otra parte están los sistemas de cifrado híbrido, en los que se usa una clave simétrica para cifrar el archivo, y después se cifra la clave simétrica con los pares de claves pública/privada.</p>
<!-- BREAK 6 -->
<h2>¿Cómo funciona el cifrado de Mega?</h2>
<div class="article-asset-image article-asset-normal article-asset-center">
 <div class="asset-content">
                   <img class="centro_sinmarco" height=320 width=650 loading="lazy" decoding="async" sizes="100vw" fetchpriority="high" srcset="https://i.blogs.es/5073a4/mega-1/450_1000.webp 450w, https://i.blogs.es/5073a4/mega-1/650_1200.webp 681w,https://i.blogs.es/5073a4/mega-1/1024_2000.webp 1024w, https://i.blogs.es/5073a4/mega-1/1366_2000.webp 1366w" src="https://i.blogs.es/5073a4/mega-1/450_1000.webp" alt="Mega" onerror="this.src='https://i.blogs.es/5073a4/mega-1/450_1000.jpg';this.srcset='https://i.blogs.es/5073a4/mega-1/450_1000.jpg 450w, https://i.blogs.es/5073a4/mega-1/650_1200.jpg 681w,https://i.blogs.es/5073a4/mega-1/1024_2000.jpg 1024w, https://i.blogs.es/5073a4/mega-1/1366_2000.jpg 1366w';return false;">
   <img alt="Mega" class="centro_sinmarco" src="https://i.blogs.es/5073a4/mega-1/450_1000.webp">
   
      </div>
</div>
<p>Vamos ahora con Mega. Lo primero que hace cuando os registráis es <em>generar un par de claves pública/privada RSA</em> de 2048 en vuestro ordenador. Se guardan en vuestro espacio de almacenamiento del navegador (HTML5), pero también se envían a los servidores de Mega. También se genera una clave simétrica maestra, que permanece en los servidores de Mega. Esta clave está cifrada con un _hash_ derivado de vuestra contraseña. Esta es la clave que se usa para proteger tu clave privada.</p>
<!-- BREAK 7 -->
<p>Bien, ahora, ¿qué ocurre cuando subes un archivo? Según la documentación de desarrolladores de Mega, el proceso (básico, resumido y obviando detalles que no son demasiado relevantes, como los chequeos de integridad) es el siguiente:</p>
<!-- BREAK 8 -->
<ul>
<li>Se genera una clave simétrica aleatoria de 128 bits para el archivo.</li>
<li>Se cifra el archivo con esa clave.</li>
<li>Se genera otra clave para enviar el archivo. La documentación no especifica de dónde sale la clave, aunque probablemente se use el <a rel="noopener, noreferrer" href="http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange">intercambio de claves Diffie-Hellman</a> con tu par de clave pública/privada y un secreto compartido.</li>
<li>Se envía el archivo cifrado a Mega, junto con la clave de cifrado del archivo, todo ello protegido con la clave que habíamos generado antes.</li>
<li>Mega guarda el archivo cifrado (sin descifrar sus contenidos) por un lado. Por otro, guarda la clave del archivo cifrada con tu clave maestra. </li>
</ul>

<p>En la documentación <em>no se discute cómo se descarga el archivo</em>. Probablemente Mega envíe el archivo y su clave de cifrado al cliente protegidos de nuevo con tu par clave pública/privada, pero esto es sólo especulación ya que no se especifica nada.</p>
<!-- BREAK 9 -->
<h2>¿Cómo se comparten los archivos?</h2>

<p>Lo que he explicado es lo básico del funcionamiento de Mega. Sin embargo, <em>hay más detalles que añaden complejidad</em>. Una de ellas es la posibilidad de compartir ficheros con otros usuarios.</p>
<!-- BREAK 10 -->
<p>Cuando permites a otros usuarios que accedan a alguna de tus carpetas, <em>las claves de cifrado de cada uno de los archivos que tienes ahí también se comparten con ellos</em>. Así pueden acceder al contenido que esté almacenado, y también podrán cargar ficheros nuevos, compartiendo su clave con todos los que tengan acceso a esa carpeta.</p>
<!-- BREAK 11 -->
<p>Por otro lado está la posibilidad de enviar ficheros usando enlaces. Un enlace a un archivo de Mega tiene el formato _http://mega.co.nz/#[ID de archivo]![Clave de cifrado (opcional)]_. Si simplemente envías un enlace con el ID de archivo, Mega te pedirá la clave de cifrado de 43 caracteres para descargar el archivo. Si el enlace tiene contiene la clave, con sólo acceder ya podrás descargarlo.</p>
<!-- BREAK 12 -->
<p>Lo bueno de usar esta forma de compartir es que sólo distribuyes las claves de los archivos que compartes. El resto de tus ficheros permanecen cifrados con claves <em>a las que nadie más puede acceder</em>.</p>
<!-- BREAK 13 -->
<h2>Duplicación de archivos, un punto comprometido</h2>

<p>Cotilleando por los términos de uso, encontré un párrafo interesante (traducción propia):</p>

<blockquote>8. Nuestro servicio puede borrar automáticamente un bloque de datos que subas si determina que es un duplicado exacto de otro bloque ya almacenado en nuestro servicio. En este caso, tendrás acceso al bloque original.</blockquote>

<p>Hasta aquí nada extraño, otros servicios de almacenamiento en la nube también lo hacen para evitar almacenar varias veces el mismo archivo. Pero hay un problema en el caso de Mega. Los archivos se guardan cifrados, y (en teoría) Mega no puede descifrarlos. Por lo tanto, <em>no puede saber si dos archivos son duplicados o no</em>, y sólo podría chequear si ya tiene el mismo bloque de datos cifrados.</p>
<!-- BREAK 14 -->
<p>El problema es que hacer eso sería bastante ineficiente. Podemos asumir que un bloque de datos cifrados es totalmente aleatorio, así que la probabilidad de que haya una colisión (dos bloques sean iguales) es extremadamente baja. Si tuviésemos cien mil archivos de 1 MB cifrados, la probabilidad de que haya una colisión es de, aproximadamente, 3 por diez elevado a -145. Para que os hagáis una idea, <em>es más probable que os toque el Gordo de la lotería durante veinte años seguidos a que haya una colisión</em>.</p>
<!-- BREAK 15 -->
<p>Tampoco sería plausible generar el _hash_ (huella digital) del archivo antes de subirlo para evitar duplicados: aunque pudieses detectar que lo tiene ya otro usuario, <em>no podrías acceder a él</em> ya que la clave de cifrado es suya y sólo desbloqueable con su contraseña.</p>
<!-- BREAK 16 -->
<p>La solución plausible a esto sería el <a rel="noopener, noreferrer" href="http://www.ssrc.ucsc.edu/Papers/storer-storagess08.pdf">cifrado convergente</a>, que genera una clave a partir del propio archivo que quieres cifrar. De esta forma, puedes mantener el control de duplicados al mismo tiempo que mantienes los archivos seguros. Sin embargo, <em>no parece que Mega está usando esto</em>: las claves de cada fichero son aleatorias, y la documentación no menciona nada relativo a esto.</p>
<!-- BREAK 17 -->
<p>Quizás sea un fallo en sus términos de servicio (lo más probable, en mi opinión), o quizás un error en la documentación. O, lo más improbable de todo, que nos estén mintiendo y sí tengan mecanismos para descifrar los archivos. Pero como digo, para mí lo más probable es que <em>sea un error de comunicación y no de programación de Mega</em>.</p>
<!-- BREAK 18 -->
<h2>Conclusión: Mega no está blindado, y tampoco tiene seguridad de alto nivel</h2>
<div class="article-asset-image article-asset-normal article-asset-center">
 <div class="asset-content">
                   <img class="centro_sinmarco" height=334 width=650 loading="lazy" decoding="async" sizes="100vw" fetchpriority="high" srcset="https://i.blogs.es/b85813/dotcom/450_1000.webp 450w, https://i.blogs.es/b85813/dotcom/650_1200.webp 681w,https://i.blogs.es/b85813/dotcom/1024_2000.webp 1024w, https://i.blogs.es/b85813/dotcom/1366_2000.webp 1366w" src="https://i.blogs.es/b85813/dotcom/450_1000.webp" alt="Kim Dotcom" onerror="this.src='https://i.blogs.es/b85813/dotcom/450_1000.jpg';this.srcset='https://i.blogs.es/b85813/dotcom/450_1000.jpg 450w, https://i.blogs.es/b85813/dotcom/650_1200.jpg 681w,https://i.blogs.es/b85813/dotcom/1024_2000.jpg 1024w, https://i.blogs.es/b85813/dotcom/1366_2000.jpg 1366w';return false;">
   <img alt="Kim Dotcom" class="centro_sinmarco" src="https://i.blogs.es/b85813/dotcom/450_1000.webp">
   
      </div>
</div>
<p>Con todo esto, parecería que Mega es lo más seguro que te puedas encontrar. <em>En mi opinión, no lo es</em>. Dropbox o SkyDrive, por ejemplo, también cifran los archivos en su servidor con una clave que también está protegida. También cifran las descargas y cargas de archivos desde tu ordenador a sus servidores. </p>
<!-- BREAK 19 -->
<p>Diréis que Mega tiene la ventaja de que la clave se almacena cifrada en sus servidores y no pueden acceder a ella y por tanto no pueden acceder a vuestros archivos, mientras que Dropbox o SkyDrive sí que pueden hacerlo porque la clave la tienen ellos. <em>En realidad no es una ventaja</em>. Si no os fiáis de que los segundos no accedan a vuestros archivos, ¿por qué fiaros de que Mega entonces? No podéis saber si va a guardar vuestras claves sin cifrar, ni tampoco si los archivos JavaScript de su página cifran correctamente los datos.</p>
<!-- BREAK 20 -->
<p>Mega, Dropbox, SkyDrive, SugarSync y el resto de servicios de almacenamiento en la nube están protegidos muy bien contra atacantes externos, y llega un momento en el que importa más las protecciones de los servidores que las capas de cifrado que tenga cada archivo. El problema es que <em>si no confías en ellos, ninguno es seguro</em> por muchas claves, capas, algoritmos y demás que haya.</p>
<!-- BREAK 21 -->
<p><strong>¿Queréis tener un almacenamiento en la nube seguro de verdad?</strong> Entonces cifrad vuestros archivos en vuestro ordenador con una clave privada propia que mantengáis oculta, sin transmitirla a nadie y que además la hayáis generado vosotros; y después subidlos a donde queráis. Entonces sí que estarán (bastante) protegidos de cualquier mirada indiscreta del servicio y de quien sea.</p>
<!-- BREAK 22 -->
<p>Pero si vais a elegir Mega por la "seguridad mejorada", <em>os estáis equivocando</em>. Quizá tenga muchas ventajas sobre cualquier otro servicio de almacenamiento (por poner una aquí, el precio, por ejemplo) pero ya os adelanto que la seguridad no es una de ellas.</p>
<!-- BREAK 23 -->
<p>De hecho, tanta preocupación por la privacidad viene más bien del deseo de protegerse ellos mismos. Si no saben qué tienen los usuarios, no pueden recriminarles los contenidos que tengan alojados porque nadie sabe cuáles son, y tampoco pueden establecer un filtro para que nadie suba contenido protegido con copyright. En este caso, <em>la protección es más para ellos que para los usuarios.</em></p>
<!-- BREAK 24 --><script>
 (function() {
  window._JS_MODULES = window._JS_MODULES || {};
  var headElement = document.getElementsByTagName('head')[0];
  if (_JS_MODULES.instagram) {
   var instagramScript = document.createElement('script');
   instagramScript.src = 'https://platform.instagram.com/en_US/embeds.js';
   instagramScript.async = true;
   instagramScript.defer = true;
   headElement.appendChild(instagramScript);
  }
 })();
</script>

                    ]]>
                </description>
            </item>
            </channel>
</rss>
