Complementando. Mesmo que o meliante consiga capturar o trafego, ele precisaria conseguir se passar pelo remetente original para que os dados sejam recebidos. Mas entenda a dificuldade. Mesmo assim, o meliante teria que conseguir receber a resposta e ter a chave simetrica para decriptar a mensagem. Para dificultar mais um pouco, na mesma sessao a chave muda de tempos em tempos.<div>
<br></div><div>Existem ataques do tipo man-in-the-middle em cima de SSL, que tentam fazer mais ou menos isso, mas pode ter certeza que eh um ataque bastante elaborado.<div><br></div><div><br><div><br></div><div><br></div>
<div><br><br>On Friday, December 6, 2013, Eduardo Coelho  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Cara,<div><br></div><div>PKI pressupoe uso de certificados verificados junto a CAs. Uma maquina tentando se passar por outra nao teria o certificado validado. Entao nao eh pra ter esse problema que vc mencionou, saca?<br>
<br>
On Friday, December 6, 2013, Eduardo Santos - Barros  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Verdade, entendi!<br><br></div>

Mas mesmo assim, seria possível um terceiro capturar esses dados, mesmo sem entender nada, e reenviá-los de forma legítima?<br>Porque na verdade ele não alteraria em nada a mensagem, apenas guardaria e enviaria em outro momento, apenas para prejudicar (como um script kid).  <br>


</div><br>Será que é possível um atacante fazer isso ou ele não consegue capturar nada por que está criptografado, assinado e com certificado?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">Em 6 de dezembro de 2013 14:29, Eduardo Coelho <span dir="ltr"><<a>eduardocoelholima@gmail.com</a>></span> escreveu:<br>


<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Rpz, na verdade se você usar SSL com PKI, por exemplo, ele usa criptografia assimétrica no estabelecimento do canal e depois simétrica pra troca de dados, exatamente por conta do custo computacional da criptografia simétrica ser bem inferior. Então já é basicamente o melhor dos mundos.<div>



<br></div><div>Se você optar somente por criptografia simétrica, você não consegue todas as garantias de segurança necessárias. Por exemplo, fica difícil garantir autenticidade.</div><div><br></div><div><br></div></div><div>


<div><div>
<br clear="all"><div><div dir="ltr"><br># Eduardo Coelho Lima<br># <a href="http://www.coelho.pro.br" target="_blank">http://www.coelho.pro.br</a></div></div>
<br><br><div>2013/12/6 Eduardo Santos - Barros <span dir="ltr"><<a>cebsjg3ster@gmail.com</a>></span><br><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div><div><div>Fala ai chará, muito obrigado pela resposta.<br></div>Entendo que se proteger o meio com PKI, seria a melhor opção, porém gostaria que fosse algo o mais próximo possível do tempo real.<br>E como sabemos a estrutura de criptografia assimétrica é bastante lenta em relação a simétrica. (<a href="http://stackoverflow.com/questions/118463/what-is-the-performance-difference-of-pki-to-symmetric-encryption" target="_blank"><strong>RSA is much, much slower</strong></a>)<br>




<br></div>Teria alguma forma de fazer isso com chaves simétricas (AES, DES ou 3DES) ou existira alguma outra estrutura, com autenticação, por exemplo, que conseguisse ser liver do ataque de replay?<br><br></div>Abraços!<br>




</div><div><br><br><div>Em 6 de dezembro de 2013 14:03, Eduardo Coelho <span dir="ltr"><<a>eduardocoelholima@gmail.com</a>></span> escreveu:<br>


<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Caro chará,<div><br></div><div>Existe um conhecido recurso usado no armazenamento de senhas que é o "salt" (tradução literal: sal). Tentando explicar de forma ultra simplista, consiste em uma string a ser adicionada à entrada de uma função criptográfica/hash, para garantir que duas senhas iguais gerem saídas diferentes. O salt não precisa ser mantido em segredo, mas precisa ser único para cada usuário.</div>





<div><br></div><div>Este recurso é usado principalmente para evitar ataques a bancos de hashs de senhas usando "rainbow tables", que é basicamente uma tabela computada com saídas da função hash e entradas possíveis (lembrando que funções hash normalmente aceitam entradas de qualquer tamanho e saídas de tamanho fixo).</div>





<div><br></div><div>No caso específico que você levantou, existem ainda a questão do canal de troca de dados. As técnicas de spoofing e de man-in-the-middle podem ser usados para tentar um ataque de replay. A principal linha que vejo como possível para mitigação para estes riscos seria através da proteção do canal de comunicação, por exemplo, uso de PKI e criptografia, buscando a fórmula autenticidade/não repúdio, integridade, confidencialidade, disponibilidade [1].</div>





<div><br></div><div>[1] <a href="http://en.wikipedia.org/wiki/Information_security#Key_concepts" target="_blank">http://en.wikipedia.org/wiki/Information_security#Key_concepts</a></div><div><br></div><div><br></div><div>




<br></div><div><br>
</div><div><br></div><div><br></div><div><br></div><div> </div><div><br></div><div><br></div><div><br></div></div><div><br clear="all"><div><div dir="ltr"><br># Eduardo Coelho Lima<br># <a href="http://www.coelho.pro.br" target="_blank">http://www.coelho.pro.br</a></div>





</div>
<br><br><div><div><div>2013/12/6 Eduardo Santos - Barros <span dir="ltr"><<a>cebsjg3ster@gmail.com</a>></span><br></div></div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div>
<div dir="ltr"><div><div><div>Companheiros (as), boa tarde!<br></div>Estava estudando sobre criptografia aqui e fiquei com uma dúvida em relação a como mitigar ataques de repetição (replay).<br><br></div>Observem essa situação no qual desejo enviar um comando de um chute em um jogo (video game), essa mensagem é criptografada com criptografia simétrica (DES, por exemplo) no qual apenas o jogador (Alice) e o jogo (Bob) detêm a chave.<br>






</div><div><br>Caso uma terceira pessoa (Carlos) intercepte o comando do chute (criptografado), ele não sabe o que é, mas ai reenvia o comando, o que acontece com o jogo (Bob), irá chutar? Carlos consegue fazer isso?<br>

</div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></blockquote></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>Que a graça e a paz que excede todo o entendimento seja com todos, para todo o sempre...amém!!!<br>


</div>

<p></p>

-- <br>
Você está recebendo esta mensagem porque se inscreveu no grupo "InfraRN" dos Grupos do Google.<br>
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para <a>infrarn+unsubscribe@googlegroups.com</a>.<br>

Para postar neste grupo, envie um e-mail para <a>infrarn@googlegroups.com</a>.<br>
Visite este grupo em <a href="http://groups.google.com/group/infrarn" target="_blank">http://groups.google.com/group/infrarn</a>.<br>
Para obter mais opções, acesse <a href="https://groups.google.com/groups/opt_out" target="_blank">https://groups.google.com/groups/opt_out</a>.<br>
</blockquote></div><br><br>-- <br><div dir="ltr"><br># Eduardo Coelho Lima<br># <a href="http://www.coelho.pro.br" target="_blank">http://www.coelho.pro.br</a></div><br>
</blockquote></div></div></div><br><br>-- <br><div dir="ltr"><br># Eduardo Coelho Lima<br># <a href="http://www.coelho.pro.br" target="_blank">http://www.coelho.pro.br</a></div><br>