@VulsSupongamos lo siguiente:
A quiere contactarse con
B, pero las dos partes usarán como ayuda a la criptografía asimétrica;
A genera su par de claves (
pública y privada) al igual que
B;
A le comparte su clave pública a
B, y éste hace lo contrario; una vez que han intercambiado las claves, es posible cifrar, y comunicarse de forma segura. Pero, ¿Qué sucedería si en el momento en que
A está intercambiado su clave (la transfiere), y
C como intermediario la intercepta?, pues, ahí está el meollo del problema.
Para solucionar esto, existen formas, que se podrían calificar de seguras por lo general, de intercambiar claves entre dos partes. La primera que se me ocurre, aunque algo tonta, puede ser intercambiar las claves en una conexión segura, pero eso igualmente no solventaría el problema subyacente. Tal vez pueda observar las diversas implementaciones de Los enlaces son solo para miembros.
Registrate o
iniciá sesión, que hablan un
poco sobre cómo es el procedimiento, aunque no es la Los enlaces son solo para miembros.
Registrate o
iniciá sesión.
Una respuesta que me gustó mucho de un post de stackexchange es:
CitarYes, this "would work" in a sense. This is a well-known MITM attack on asymmetric key crypto. This technique is not only used by "bad guys." For example, this is exactly what certain vendors' network security appliances do in order to "inspect" encrypted network traffic and block "bad" traffic.
So, why did I put "would work" in quotes? Well, for example, if a bad MITM attacker substitutes his own certificate for a known HTTPS website's certificate, that certificate will most likely not have been signed by a trusted CA (unless the MITM could have somehow tricked the trusted CA into signing a certificate that stated that he was the known web site). In this case a web browser going to the HTTPS website that receives the MITM certificate will send up an alarm and tell the user not to proceed because the domain name either doesnt match or it does match but the certificate was not signed by a trusted CA.
Trusted CA certificates are embedded in your operating system when you purchase it. These are guys like Verisign, etc. You can view your trusted CA certs using operating system utilities. You could remove them if you like, but then all the websites you visit will show up without a nice green Lock symbol
El respectivo post puede encontrarlo en: Los enlaces son solo para miembros.
Registrate o
iniciá sesiónO sea, es algo verdaderamente complejo, pero posible, aunque inviable siendo pruritos con la teoría.
Y quiero aclarar algo, porque no quiero que caiga en confusión: implementación no es lo mismo que el protocolo, y ninguna de los dos últimos es lo mismo que algoritmo. Indague más sobre ello para que se quite las dudas, pero en pocas palabras, algoritmo es la parte más baja (AES, vendría siendo en este caso), luego sigue su implementación o en otros textos, implantación, que vendría siendo la forma en la que fue escrito para ser usado el susodicho algoritmo, como una pequeña librería que permite hacer funciones tales como cifrar y descifrar; después, aunque esto es opcional para poder ser usado como se debe, es el protocolo, que vendría a hacer la forma en que dos o más partes se comunicarían usando una implementación específica, bajo un algoritmo específico.
Si quiere saber más sobre los protocolos de las aplicaciones que está indagando, lea documentación oficial:
*.- Los enlaces son solo para miembros.
Registrate o
iniciá sesión*.- Los enlaces son solo para miembros.
Registrate o
iniciá sesiónSiguiente con el tema: aunque AES haya ataques descubiertos, siguen Los enlaces son solo para miembros.
Registrate o
iniciá sesión.
Aquí dos enlaces; un post que deja algunos enlaces de interés, y de un libro que nos compartió un compañero del foro, y el otro, un enlace que se discute sobre las posibles capacidades de la NSA y el GCHQ:
*.-
https://underc0de.org/foro/dudas-generales-121/aes-256-y-el-metodo-de-fuerza-bruta/*.- Los enlaces son solo para miembros.
Registrate o
iniciá sesión~ DtxdF
