Search the Community

hi. as indicated in the topic... i set up auth. via a hashed password in torrc. i'm dead sure i'm copying same hash over to eddie (with the 16:prefix). one output only: Unable to communicate with Tor (515 Authentication failed: Password did not match HashedControlPassword *or* authentication cookie.). Is Tor up and running? Tor is detecting that control connection, but not complaining about auth issues (in the output). [notice] New control connection opened from 127.0.0.1.

Eddie client saves login and password information in AirVPN.xml as cleartext! I am suggesting this information be hashed when saved, if possible.

I would love to one day see Threefish-256 as an option. I think 512 and 1024 bits would only congest the servers too much, but 256 bits should be easy enough. In addition, I think Serpent is a very good option at 256 bits. Tiger is a great hash, but is currently only 160 bits plus the HMAC. So it is less desirable compared to SHA2-256 If there is a wishlist, I was unable to find it. I would appreciate a link to the thread if one exists. And I most certainly welcome discussion. Thanks in advance.

SLOTH attack targets old hash functions Researchers from the Prosecco team at INRIA published a number of attacks that exploit the use of weak hash functions in TLS and other protocols. They called their attack SLOTH (Security Losses from Obsolete and Truncated Transcript Hashes). The most severe attack is affecting the systems that use of client certificates and continue to support RSA-MD5 signatures. It’s been known since 2005 that MD5 hash collisions are easy to carry out. Many practitioners have argued in the past that the hash collisions don’t matter in certain scenarios and that the security of many protocols only relies on the so-called second preimage resistance. The INRIA researchers debunked many of these claims with their new publication. The most notable scenario where an attack is possible is when client certificates are used. If a user authenticates himself at a malicious server using a client that supports RSA-MD5 signatures, then the server can use the information provided to impersonate the user on some other target server (which must also support RSA-MD5). A surprising aspect of this is that TLS 1.2 is vulnerable to this attack while prior versions are not. The reason for this is that TLS 1.2 allows negotiation of the signature algorithm (prior versions always use a concatenation of MD5 and SHA1) and, crucially, still supports the insecure MD5 as an option. This is very surprising given the fact that TLS 1.2 was published in 2008—several years after practical attacks against MD5 were announced. This attack is made worse by the fact that various implementations accept RSA-MD5 signatures even if they advertise that they don’t do this. Several cryptographic libraries have received updates in response to this research, including NSS, GnuTLS, BouncyCastle and mbedTLS. An old version of OpenSSL (before 1.0.1f) was also affected.