Usage of SHA-1

[numma_cway]

Since i didnt reverse engineered the software

I believe that you must have understood an algorithm (which, for closed-source software, includes reverse engineering in the first step) to make a statement on whether it's secure or not.

[plizze]

So yes. It might be the time to move to a proper one for the current time

Finally some common sense.

I believe that you must have understood an algorithm (which, for closed-source software, includes reverse engineering in the first step) to make a statement on whether it's secure or not.

there is enough stuff on github.

I gotta end it here. Good to see that you guys want to change the function, even tho a proper timeschedule would have been good.
And thanks for keeping the thread open...

[Schlumpi]

Sorry to extend, but I have to add a (hopefully more understandable) explanation why the SHA1 usage with the UID isn't a security risk.
The UID is used as user id within the Teamspeak server.
The client uses public/private key cryptography to prove his identity.
The UID is, as far as I know, the SHA1-hash of the public key of the client. Or of something that also includes the public key of the client. If you are able to crack that hash and regenerate the public key, you have the public key. An item that is per design of public key cryptography intended to be available to the public anyway.

You still need the private key of the key pair of a client to be able to make any use of the regenerated public key. Regenerating the private key is the actual challenge the public/private key cryptography is all about, and if the private key was generated with a long enough key length (2048 or more bits), it isn't possible to regenerate it with today's computers.

If a client connects, it cryptographically proves that his UID is the sha1 hash of his public key by the use of his private key.

As consequence, if some other client wants to impersonate this client, it is required that he has a public key whose sha1 hash has the same UID of the client he wants to impersonate, and in addition he needs the corresponding private key.

Instead of trying to regenerating the private key, which is beyond today's computer capabilities, how about just trying to create a key pair that by chance has the required public key? That's also not possible: According to https://crypto.stackexchange.com/que...public-modulus it is "far more likely that you'd win the lottery 100 times in a row than two devices happen to pick the same RSA key" (also included in the link is a mathematical proof).

[numma_cway]

The UID is not used for cryptography and it not the public key and therefore this thread is not about cryptographic security. There is more than one information related the public key. Some of these information are put into an ASN struct. This ASN struct is used for cryptography and is transferred over "voice client control query" encoded as a Base64 string (other than the myTSID verification, which is transfers in binary over "voice client control query"). That Base64 string of the ASN struct is called omega. omega is used in the following ways:

• SHA-1 it and display as hex, but don't use 0123456789abcdef for display but abcdefghijklmnop. This is called avatar file name.
• SHA-1 it and display as Base64. This is called UID.
• SHA-1 it, display as Base64 and encode Base64 in Base64. This is called chat log file name.
• Append a string representing a number, then SHA-1 the resulting string. Number of leading zero bits in big endian byte and little endian bit order is called security level.

In theory, if you could create a valid omega that will turn into a server admin's UID, you can take own of a server where that UID is server admin. Also, you will confuse the contact system. However, this is nearly impossible because constraints for the ASN struct that is turned into omega are very strict in the TeamSpeak server because it is part of the public key. Though extremely unlikely, in theory, using SHA-1 decreases server security from "basically impossible to break without quantum computers" to still "basically impossible to break without quantum computers".

Creating a private key that matches alpha (another Base64 string transferred over "voice client control query") and omega and could therefore pose a risk to cryptographic security is even more unlikely because even more bits must "match". Actually, a "weak" UID might even be better here because it's harder to know if your omega could be right from just hashing it. So cryptographic security is at least not lower by using SHA-1 instead of a more secure hash.

[plizze]

Sorry to extend, but I have to add a (hopefully more understandable) explanation why the SHA1 usage with the UID isn't a security risk.

Thats basically it. But SHA-1 should still be replaced.

The UID is not used for cryptography and it not the public key

Since permissions are assigned based on the UID, it is a cryptography part in the chain.

The rest you posted is nothing new.

[numma_cway]

I did not mean to post anything new to people who understood the thread.

[florian2833z]

I did not mean to post anything new to people who understood the thread.

For me, it was something new, thank you

[florian2833z]

Sha1 is broken af
https://www.golem.de/news/hashfunkti...01-145937.html