CN109905395B

CN109905395B - Method and related device for verifying credibility of client

Info

Publication number: CN109905395B
Application number: CN201910172875.2A
Authority: CN
Inventors: 周志刚
Original assignee: Wuhan Douyu Network Technology Co Ltd
Current assignee: Wuhan Douyu Network Technology Co Ltd
Priority date: 2019-03-07
Filing date: 2019-03-07
Publication date: 2021-09-07
Anticipated expiration: 2039-03-07
Also published as: CN109905395A

Abstract

The embodiment of the application discloses a method and a related device for verifying credibility of a client, which are used for improving verification efficiency of a server. The method in the embodiment of the application comprises the following steps: the live broadcast platform server sends a verification instruction to the client, wherein the verification instruction is used for indicating a verification requirement which needs to be met by a calculation result with the length of M and generated by the client, and the verification instruction comprises random data with the length of N, a current timestamp of the live broadcast platform server with the length of (M-N), position information of an anchor point, a numerical value P of the anchor point and a numerical value Q of a floating point; a live broadcast platform server receives a verification response sent by a client; the live broadcast platform server generates an encrypted KEY according to a preset algorithm and user information; when the calculation result meets the verification requirement, the live broadcast platform server splices the random data and the calculation timestamp to obtain verification data; the live broadcast platform server encrypts verification data according to the encryption KEY to obtain a verification value; and if the verification value is consistent with the calculation result, determining that the client is a credible client.

Description

Method and related device for verifying credibility of client

Technical Field

The present application relates to the field of live broadcast platforms, and in particular, to a method and related apparatus for verifying client trust.

Background

With the increasing popularity and development of networks, online live broadcasting becomes more and more popular with users. The live platform server needs to authenticate different clients to determine the computing power of each client, such as client H5, Android, IOS, PC client, and the like.

However, as the algorithm is continuously upgraded, the client may have new and old versions at the same time, so the live platform server needs verification logic compatible with the new and old versions. Meanwhile, when the user watches the live broadcast, the live broadcast platform server needs to consider the user characteristics when verifying because the watching time length of each user is different. Especially when the live platform has large-scale event, online user can increase on foot simultaneously, and the load pressure of live platform server can increase on foot so, consequently, how to let live platform server's verification process more high-efficient to alleviate live platform server's load pressure is the current problem that urgently needs to be solved.

Disclosure of Invention

The embodiment of the application provides a method and a related device for verifying credibility of a client, which are used for increasing the verification efficiency of a live broadcast platform server and effectively relieving the load pressure of the live broadcast platform server.

A first aspect of an embodiment of the present application provides a method for verifying that a client is trusted, including: a live broadcast platform server sends a verification instruction to a client, wherein the verification instruction is used for indicating a verification requirement which needs to be met by a calculation result with the length of M and is generated by the client, the verification instruction comprises a current timestamp of the live broadcast platform server with the length of (M-N), random data with the length of N, position information of an anchor point, a value P of the anchor point and a value Q of a floating point, the anchor point is the value P at a specified position of the calculation result, the specified position is the position information of the anchor point, the floating point is the value Q included in the calculation result, and M is larger than N; the live broadcast platform server receives a verification response sent by the client, wherein the verification response at least comprises the following information: the calculation result meeting the verification requirement and a calculation time stamp used in the calculation of the client; the live broadcast platform server generates the encrypted KEY according to a preset algorithm and the user information, wherein the preset algorithm is determined by negotiation between the client and the live broadcast platform server; when the live broadcast platform server judges that the calculation result meets the verification requirement, the live broadcast platform server splices the random data and the calculation timestamp to obtain verification data; the live broadcast platform server encrypts the verification data according to the encryption KEY to obtain a verification value; and if the verification value is consistent with the calculation result, the live broadcast platform server determines that the client is a credible client.

In a possible embodiment, the encrypting, by the live platform server, the verification data according to the encryption KEY to obtain a verification value includes: the live broadcast platform server obtains the verification value through the following encryption algorithm: blowfish _ Encrypt (& ctx, input); char input [ M ] ═ randdata + Timestamp 2; the Blowfish _ Encrypt () is an encryption interface of a Blowfish encryption algorithm, an output value of the encryption interface is the verification value, the & ctx is a context variable of the Blowfish encryption algorithm, the input is the verification data, the randdata is the random data, and the Timestamp2 is the computation Timestamp.

A second aspect of an embodiment of the present application provides a method for verifying that a client is trusted, including: a client receives a verification instruction sent by a live broadcast platform server, wherein the verification instruction is used for indicating a verification requirement which needs to be met by a calculation result with the length of M and generated by the client, the verification instruction comprises a current timestamp of the live broadcast platform server with the length of (M-N), random data with the length of N, position information of an anchor point, a value P of the anchor point and a value Q of a drift point, the anchor point is the value P at a specified position of the calculation result, the specified position is the position information of the anchor point, the drift point is the value Q included in the calculation result, and M is greater than N; based on a preset algorithm, the client generates an encryption KEY according to user information, the preset algorithm is determined by negotiation between the client and the live broadcast platform server, the user information comprises user identification information, equipment identification information and room identification information, and the length of a current timestamp of the client is M-N; the client splices the random data and the current timestamp of the client to obtain encrypted data with the length of M; the client generates the calculation result meeting the verification requirement according to the encrypted data and the encrypted KEY, and sends a verification response responding to the verification instruction to the live broadcast platform server, wherein the verification response at least comprises the following information: the client generates the calculation time length of the calculation result and the identification information of the client, so that the live broadcast platform server verifies whether the client is credible according to the verification response.

In one possible embodiment, the client generating the calculation result satisfying the verification requirement according to the encrypted data and the encrypted KEY comprises: the client side encrypts the encrypted data through the following encryption algorithm to obtain an encryption result: blowfish _ Encrypt (& ctx, input); char input [ M ] ═ randdata + Timestamp 3;

wherein, the Blowfish _ Encrypt () is an encryption interface of a Blowfish encryption algorithm, an output value of the encryption interface is the encryption result, the & ctx is a context variable of the Blowfish encryption algorithm, the input is the encrypted data, the randdata is the random data, and the Timestamp3 is the current Timestamp of the client; the client side judges whether the encryption result meets the verification requirement or not; if the encryption result does not meet the verification requirement, the client circularly encrypts the encrypted data by calling a while function until the encryption result meets the verification requirement, wherein the encryption result meeting the verification requirement is the calculation result, and the Timestamp3 is the current Timestamp of the client at each circulation.

In one possible embodiment, the determining, by the client, whether the encryption result satisfies the authentication requirement includes:

the client judges whether the value of the encryption result at the specified position is the P or not; if the value at the designated position is not the P, the client determines that the encryption result does not meet the verification requirement; if the value at the designated position is P, the client judges whether the encryption result contains Q; if the value at the designated position is P and the encryption result comprises Q, the client determines that the encryption result meets the verification requirement; if the encryption result does not contain the Q, the client determines that the encryption result does not meet the verification requirement.

A third aspect of an embodiment of the present application provides a live platform server, including: a transceiving unit, configured to send a verification instruction to a client, where the verification instruction is used to indicate a verification requirement that a computation result with a length of M generated by the client needs to be met, where the verification instruction includes a current timestamp of the live broadcast platform server with a length of (M-N), random data with a length of N, location information of an anchor point, a value P of the anchor point, and a value Q of a floating point, where the anchor point is a value at a specified location of the computation result, the specified location is the location information of the anchor point, the floating point is a value including the Q in the computation result, and M is greater than N; receiving a verification response sent by the client, wherein the verification response at least comprises the following information: the calculation result meeting the verification requirement and a calculation time stamp used in the calculation of the client; the generating unit is used for generating the encrypted KEY according to the preset algorithm and the user information, wherein the preset algorithm is determined by negotiation between the client and the live broadcast platform server; when the live broadcast platform server judges that the calculation result meets the verification requirement, splicing the random data and the calculation timestamp to obtain verification data; the encryption unit is used for encrypting the verification data according to the encryption KEY to obtain a verification value; and the determining unit is used for determining that the client is a credible client if the verification value is consistent with the calculation result.

A fourth aspect of an embodiment of the present application provides a client, including: a receiving and sending unit, configured to receive a verification instruction sent by a live broadcast platform server, where the verification instruction is used to indicate a verification requirement that a calculation result with a length of M generated by the client needs to be met, where the verification instruction includes a current timestamp of the live broadcast platform server with a length of (M-N), random data with a length of N, location information of an anchor point, a value P of the anchor point, and a value Q of a floating point, where the anchor point is the value at an appointed location of the calculation result of P, the appointed location is the location information of the anchor point, the floating point is that the calculation result includes Q, and M is greater than N; the system comprises a generating unit, a receiving unit and a processing unit, wherein the generating unit is used for generating an encryption KEY according to user information based on a preset algorithm, the preset algorithm is determined by negotiation between a client and a live broadcast platform server, the user information comprises user identification information, equipment identification information and room identification information, and the length of a current timestamp of the client is M-N; splicing the random data and the current timestamp of the client to obtain encrypted data with the length of M; generating the calculation result meeting the verification requirement according to the encrypted data and the encrypted KEY, and sending a verification response responding to the verification instruction to the live broadcast platform server, wherein the verification response at least comprises the following information: the client generates the calculation time length of the calculation result and the identification information of the client, so that the live broadcast platform server verifies whether the client is credible according to the verification response.

A fifth aspect of the present application provides an electronic device, comprising a memory and a processor, wherein the processor is configured to implement the steps of the method for verifying that a client is trusted according to any one of the above first aspect when executing a computer management class program stored in the memory.

A sixth aspect of the present application provides a computer-readable storage medium having stored therein instructions, which, when run on a computer, cause the computer to perform the method of the above-described aspects.

A seventh aspect of the present application provides a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method of the above aspects.

According to the technical scheme, the embodiment of the application has the following advantages: a live broadcast platform server sends a verification instruction to a client, wherein the verification instruction is used for indicating a verification requirement which needs to be met by a calculation result with the length of M and is generated by the client, the verification instruction comprises a current timestamp of the live broadcast platform server with the length of (M-N), random data with the length of N, position information of an anchor point, a value P of the anchor point and a value Q of a floating point, the anchor point is the value P at a specified position of the calculation result, the specified position is the position information of the anchor point, the floating point is the value Q included in the calculation result, and M is larger than N; the live broadcast platform server receives a verification response sent by the client, wherein the verification response at least comprises the following information: the calculation result meeting the verification requirement and a calculation time stamp used in the calculation of the client; the live broadcast platform server generates the encrypted KEY according to the preset algorithm and the user information, wherein the preset algorithm is determined by negotiation between the client and the live broadcast platform server; when the live broadcast platform server judges that the calculation result meets the verification requirement, the live broadcast platform server splices the random data and the calculation timestamp to obtain verification data; the live broadcast platform server encrypts the verification data according to the encryption KEY to obtain a verification value; and if the verification value is consistent with the calculation result, the live broadcast platform server determines that the client is a credible client. In the embodiment of the application, the live broadcast platform server can realize the reliability of the verification client only by simple calculation, thereby increasing the verification efficiency of the live broadcast platform server and effectively relieving the load pressure of the live broadcast platform server.

Drawings

Fig. 1 is a flowchart of a method for verifying trust of a client according to an embodiment of the present disclosure;

fig. 2a is a schematic structural diagram of a possible live broadcast platform server according to an embodiment of the present disclosure;

fig. 2b is a schematic structural diagram of a possible client according to an embodiment of the present disclosure;

fig. 3a is a schematic diagram of a hardware structure of a possible electronic device according to an embodiment of the present disclosure;

fig. 3b is a schematic diagram of a hardware structure of another possible electronic device according to an embodiment of the present disclosure

FIG. 4a is a schematic diagram of a hardware structure of a possible computer-readable storage medium according to an embodiment of the present application;

fig. 4b is a schematic hardware structure diagram of another possible computer-readable storage medium according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

Referring to fig. 1, a flowchart of a possible method for verifying the trustworthiness of a client according to an embodiment of the present disclosure includes:

101. a live broadcast platform server negotiates an authentication protocol with a client;

it can be understood that in the embodiment of the present application, each client of the live platform needs to be verified by an asymmetric algorithm, and in practical application, the client specifically includes an H5 client, an Android, an IOS, and a PC client, so that in order to facilitate the live platform server to verify different clients, the types of the clients need to be identified in the verification protocol, that is, the corresponding identification values of different client types must be different. Specifically, in this embodiment of the present application, all client types may be enumerated by creating an enumeration variable, which is implemented as follows:

Enum eClientType{

eClientType_H5＝0,

eClientType_Android＝1,

eClientType_Ios＝2,

eClientType_PC＝3,

}

that is, if the value of the eClientType is 0, the client type is h 5; when the value of the eClientType is 1, the eClientType is the client type of the Android; when the value of the eClientType is 2, the type of the client side of the IOS is determined; if the value of the eClientType is 3, the PC is the client type. It should be noted that, in practical applications, there are various ways to identify the type of the client, for example, a uint32_ t type (32-bit integer) may be used to identify the type of the client, or the type of the client may be identified by combining letters and numbers, and the like, and the specific application is not limited herein.

It can be understood that the authentication languages of the clients adopted by different platforms are different, that is, the reverse analysis cost of each platform for hackers is different, for example, H5 is easier than hackers, and PC and Android are more complicated, so that the simpler authentication algorithm is bypassed in order to prevent hackers from intentionally tampering with the client type parameters, for example, the client using Android intentionally sets the client type incoming parameter from legal 1 to 0, that is, eClientType is 0, so as to cheat that the live platform server is currently a client of H5, so that the authentication algorithm is easier to reverse and crack. In view of this, in the embodiment of the present application, an additional independent hidden field of the client type needs to be added in the commercial authentication protocol between the live broadcast platform server and the client. Specifically, an encrypted hidden field uint32_ t encryption type is added to the authentication protocol, and in a possible embodiment, the original client type is encrypted by a packet encryption algorithm (TEA), and the specific function is expressed as follows:

encryptType＝Tea.encrypt(type,KEY)；

encrypt is used for representing an encryption interface of the TEA algorithm; type is used to represent the original client type; KEY is used for representing a KEY used in encryption, wherein the live platform server and the client negotiate to use the same KEY for encryption and decryption, and encryptType is used for representing the type of the encrypted client. Therefore, the client will report both the original type and the encrypted encryptType to the live platform server together with the authentication protocol.

Therefore, in the embodiment of the application, the live broadcast platform server negotiates with the client to verify the real client type according to the verification protocol, so that whether the client is primarily trusted is determined. Specifically, in this embodiment of the present application, the verification protocol may specifically include the following information:

type@＝VerifyReq/client@＝type2/data@＝encryptType

wherein, type @ ═ VerifyReq is used for indicating that the information is the verification protocol; the client @ ═ type is used for representing the original client type; data @ encryptType is used to indicate the encrypted client type.

Therefore, after receiving the verification protocol sent by the client, the live broadcast platform server can verify whether the client is forged or not according to the type and the encrypt type 2. Correspondingly, the live broadcast platform server decrypts through the TEA encryption and decryption algorithm, and the specific implementation function is as follows:

type2＝Tea.decrypt(encryptType,KEY)；

the encryptType is used for representing the encrypted client type; the KEY is used for expressing a KEY used during encryption and decryption negotiated by the live platform server and the client; type2 is used to indicate the client type after decryption. After decryption, comparing whether the type2 is consistent with the value of the type, if so, the verification is passed, and if not, the client is forged, so that the live platform server can directly recognize that the client is a forged client.

Optionally, in practical application, along with subsequent continuous iterative update, the algorithm is updated to repair the vulnerability and improve the security of the algorithm. For the client of the mobile terminal, because some users do not update in time, the old version and the new version of the client exist at the same time, and then the live platform server needs to perform compatible processing on different versions of the client. Therefore, in the embodiment of the application, a version number field can be further added in the authentication protocol, so that the live broadcast platform server can determine the authentication protocol version corresponding to the client according to the version number field. In practical applications, a 32-bit integer variable of a Uint32_ t may be used to represent the version number used by the authentication protocol, for example, Uint32_ t nVersion ═ 1 represents the first version, the version number is 1, and nVersion ═ 2 represents the second version if the subsequent version is upgraded. Specifically, in this embodiment of the present application, the verification protocol may specifically include the following information:

type@＝VerifyReq/version@＝nVersion/；

wherein, type @ ═ VerifyReq is used for indicating that the information is the verification protocol; and version @ and nVersion are used for indicating the corresponding authentication protocol version of the client.

Therefore, in order to prevent a hacker from using an old authentication protocol to authenticate by tampering with a new client, the live platform server may generate a table of the protocol corresponding to the client version, so as to query the version of the authentication protocol corresponding to each client version, and if the version of the authentication protocol is not matched, the client is directly determined to be an illegal client. The concrete implementation is as follows: the method comprises the steps of using a Map container of a standard database template (STL) to store corresponding relations among client types, client versions and verification protocol versions, specifically defining a Map array to distinguish different client types, wherein the size of the corresponding array is defined by a plurality of client types, and if 4 types of clients exist, defining Map < int, int > mapVer [4], wherein mapVer [0] is used for storing information of a client H5, mapVer [1] is used for storing information of client Android, mapVer [2] is used for storing information of a client IOS, and mapVer [3] is used for storing information of a client PC. In order to enable the live platform server to determine the client version released by each client and the verification protocol version corresponding to each client version, such configuration information may be initialized when the live platform server is started, and the specific function expression may be as follows:

mapVer[int].insert(pair<int,int>(x,y))；

where mapVer [ int ] is used to indicate the type of the client, x is used to indicate the version number of the client, and y is used to indicate the corresponding authentication protocol version number, for ease of understanding, as will be exemplified below, e.g., mapVer [1]. insert (pair < int, int > (12, 1)); the client type used for indicating that one piece of Android is inserted, wherein the corresponding client version of the Android is 12, and the corresponding verification protocol version is 1; similarly, mapVer [2] insert (pair < int, int > (13, 2)); for indicating the type of client that inserted an IOS, its corresponding client version of the IOS is 13 and its corresponding authentication protocol version is 2. It is understood that if other types of clients are added later or the client releases a new version, the corresponding version numbers of the client and the protocol may be added in a similar manner.

Therefore, when the client reports the version number of the current authentication protocol of the client in the authentication protocol, the live platform server queries whether the data reported by the client is legal, and specifically, the live platform server judges the validity of the data reported by the client by programming an interface, for example, Boo CheckVerifyVersion (uint32_ t type, uint32_ t app, uint32_ tver); wherein, the checkVerifyVersion is used for representing a judgment interface of the writing; the uint32_ t type is used for representing a corresponding client type; the agent 32_ t appver is used for indicating the version number of the client; and the agent 32_ t ver is used for representing the version number of the authentication protocol reported by the client. If the judging interface judges that the version number of the verification protocol reported by the client is different from the version number of the verification protocol corresponding to the client type and the version number of the client stored in the map container, the client is forged, and therefore the live broadcast platform server can directly identify that the client is a forged client.

In conclusion, the live broadcast platform server determines the content in the authentication protocol by negotiating the authentication protocol with the client, and can preliminarily identify whether the client is a trusted client.

102. The live broadcast platform server sends a verification instruction to the client;

in order to further verify the reliability of the client, in the embodiment of the application, the live broadcast platform server also verifies whether the client is reliable by verifying the calculation capacity detection value of the client, that is, the live broadcast platform server designs different titles according to the calculation capacity of the client and sends the titles to the client for calculation. For the client, the problem issued by the live platform server is calculated to obtain a calculation result, and the calculation result is reported to the live platform server. It can be understood that, in the embodiment of the present application, all titles sent by the live broadcast platform server are obtained by encrypting M-bit data sent by the live broadcast platform server, and obtaining an encryption result or an M-bit encryption result data, that is, a calculation result. Subject difficulty level in the examples of this application 2 terms are designed, one for anchor and one for float. The meaning of the anchor means that in the obtained M-bit calculation result, the designated position must meet the numerical requirement of the live broadcast platform server. For example, if the length of the bit 1 in the calculation result is 32, it must be 3, and the anchor is defined. The drift is defined by the fact that 4 values must be satisfied to appear in the calculation result of the M bits, and no special position needs to be specified. Because the complexity of the anchor is obviously higher than that of the drift by a large amount, a plurality of anchors can be specified for enhancing the calculation difficulty of the verification result, and the drift can be used for performing if fine adjustment is needed, the complexity of topic issuing by the live platform server can be determined by adopting the mode in a larger range space. For ease of understanding, the topics exemplifying the simple difficulty 1 are as follows: the live broadcast platform server specifies that the first bit data in the calculation result of the client is required to be 5; the difficulty 2 is titled as follows: the live platform server specifies that the first digit of the calculation result of the client is required to be 5, and one digit of the calculation result is required to be 4; the more difficult topics can be as follows: the live platform server specifies that the first digit of the client's calculation must be 5 and the 2 nd digit value must be 9. The same live platform server may also specify multiple floating data. Therefore, in the embodiment of the application, various topics with different difficulties can be designed, and the topics can be fine-tuned by using the floating.

The live broadcast platform server sends a verification instruction to the client, wherein the verification instruction is used for indicating a verification requirement which needs to be met by a calculation result with the length of M and is generated by the client, the verification instruction comprises a current timestamp of the live broadcast platform server with the length of (M-N), random data with the length of N, position information of an anchor point, a value P of the anchor point and a value Q of a floating point, the anchor point is P at a specified position of the calculation result, the specified position is the position information of the anchor point, the floating point is Q in the calculation result, and M is larger than N. In order to facilitate understanding, in this embodiment of the present application, a specific function implementation for the live broadcast platform server to send the verification instruction to the client may be as follows:

type@＝VerifyReq/Timestamp@＝1540132018/RandData@＝a12bcd980763acddeab879/anchor1pos@＝1/anchor1value@＝5/drift1@＝4/；

wherein, type @ ═ VerifyReq indicates that the instruction is the protocol content of the verification topic issued by the live platform server; timestamp @ ═ 1540132018 indicates the current Timestamp information of the live platform server, and the length of the Timestamp information is 10 bits long; RandData @ a12bcd980763acddeab879 represents random data generated by the live platform server, and the length of the random data is 22 bits long; anchor1pos @ ═ 1 indicates that the location information of the first anchor point is the first numerical value; anchor1value @ ═ 5 then means that the specific value of the first anchor must be 5; drift1@ 4 then indicates a drift value of 4, i.e. the final calculated result data must have a value of 4. In this example, there is only one anchor value and one drift value, and in practical applications, there may be multiple anchor values such as anchor r2pos, anchor2value, etc., or multiple drift values such as drift2, drift3, etc., and this is not limited herein.

103. The client generates an encrypted KEY according to the user information;

104. the client splices the random data and the current timestamp of the client to obtain encrypted data with the length of M;

105. the client generates a calculation result meeting the verification requirement according to the encrypted data and the encrypted KEY;

in the embodiment of the application, after the client receives the verification instruction, namely the random data with the length of N and the current timestamp of the live broadcast platform server with the length of (M-N) are sent by the live broadcast platform server, namely a section of M-bit data is sent to the client, the client encrypts the data, and continuously performs iterative encryption on the encrypted result, and judges whether the data of the encrypted result meets the requirement result of the live broadcast platform server every time the data is encrypted. The client encrypts the input M-bit data to obtain a 32-bit encryption result. In order to meet the requirement that the calculation of one-time encryption is very fast and the length of encrypted data cannot change, in the embodiment of the application, the blowfish algorithm can be selected as the algorithm for calculation power verification.

To obtain the calculation result, the client first needs to calculate an encryption KEY according to the user information, and the specific implementation function may be as follows:

KEY＝SHA512.Create(Timestamp+UserId+DeviceID+RoomId)；

create is a computing interface of the HASH algorithm SHA512, Timestamp is used for representing a current Timestamp of a client, UserID is used for representing user identification information, DeviceID is used for representing device identification information of the client, RoomID is used for representing room identification information, and encryption KEY is KEY data which can be used for a subsequent encryption algorithm blowfish. And then the client side carries out the iterative encryption of the blog hash on the data sent by the server until the encryption result can meet the question requirement of the live broadcast platform server.

Firstly, a start Time needs to be defined, which is good for the calculation Time consumption of the subsequent whole algorithm, specifically, a system function Time is used to obtain the current Time, and the implementation function may be Uint64_ t nstart ═ Time (); then, the number of times of the blowfish encryption is defined and initialized to 0, and the implementation function may be Uint64_ t nTimes ═ 0. Next, input data to be encrypted is defined, where the input data is obtained by splicing random data issued by a live platform server and a current timestamp of a client together, and the obtained encrypted data has a length of M, in this embodiment of the present application, a value of M may be 32, and a specific implementation function may be as follows: char input [32] ═ randdata + nStartTime; wherein randdata is used for representing random data in the verification instruction, and nStartTime is used for representing the acquired current timestamp of the client.

The client defines a context environment variable of a BLOWFISH encryption algorithm through a function BLOWFISH _ CTX, and then performs initialization operation through a function BLOWFISH _ Init, wherein the function BLOWFISH _ Init is an environment variable interface for initializing the context and assigns an encrypted key to the environment variable, and the function implementation can be as follows: blowfish _ Init (& ctx, key, sizeof (key)). After the initialization operation is completed, a while loop is written to continuously encrypt until the encryption result meets the requirement. In the while loop, firstly, the calculation times are increased by 1, then an encryption interface of a blob hash encryption algorithm is called to encrypt data, and after the encryption is finished, an encrypted result is stored in an input. The specific function is implemented as follows:

While(true){

nTimes＝nTimes+1；

Blowfish_Encrypt(&ctx,input)；

the nTimes represents the number of times of calculation, Blowfish _ Encrypt is used for representing an encryption interface of a Blowfish encryption algorithm, & ctx represents a context environment variable of the Blowfish encryption algorithm, and input represents data to be encrypted. And judging whether the encrypted result meets the verification requirement issued by the live broadcast platform server or not after the encrypted result is obtained. Assuming that the specific value of the value required for verification as the first anchor point must be 5, and the value of the drift is 4, first, it is determined whether the anchor, that is, the first data is equal to 5, that is, it is determined that input [1] ═ 5; if not, the requirement is not met, if yes, the further judgment is carried out to determine whether other anchors exist, and if not, the judgment is carried out to determine whether other floats exist, and the judgment of the floats is carried out. In the embodiment of the application, the drift can be judged through the For cycle, which specifically comprises the following steps:

For(int i＝0；i<32；i++){

If(input[i]＝＝4){

}

if 4 in the encrypted result, the data is verified, so that the verification requirement of the live platform server is met.

After obtaining the encryption result meeting the verification requirement, obtaining the current Time according to a function Uint64_ t ncurrent Time ═ Time (), obtaining the Time consumed by the whole calculation through the Time difference between the current Time and the previous Time, that is, calculating how long the client consumes to obtain the encryption result meeting the verification requirement, that is, calculating data, and specifically expressing the function as follows:

Uint64_t Elapse＝nCurrentTime-nStartTime；

the Elapse is used for indicating the calculation time for the client to generate the calculation result, the nCurrentTime is used for indicating the time for generating the calculation result, and the nStartTime is used for indicating the time for starting encryption.

Optionally, if the encrypted result does not meet the verification requirement, the next round of calculation is performed again. The method specifically comprises the following steps: the current timestamp is obtained through a function Uint64_ t nCurrentTime ═ Time (), and the first N bits of data of the original data encrypted for the second Time are encrypted together with the current timestamp, that is, each encryption replaces timestamp data with a length of (M-N) bits in the data to be encrypted. The first N bits of the M-bit data are not replaced, while the last (M-N) bit data are the current timestamp, and each calculation is replaced by the current timestamp. For example, when M is 32 and N is 22, the data to be encrypted may be obtained as follows, where the data to be encrypted is the data to be encrypted next time:

input[32]＝randdata[0-21]+nCurrentTime；

wherein, input [32] is data to be encrypted, randdata [0-21] is random data of 22 bits, and nCurrentTime is a time stamp when the second encryption is started.

Similarly, the verification requirement issued by the live broadcast platform server is achieved through continuous calculation, the CPU resource of the client is consumed in the process, and the consumed duration is determined by the difficulty of issuing the title by the server.

106. The client sends a verification response responding to the verification instruction to the live broadcast platform server;

and after generating an encryption result, namely a verification result, meeting the verification requirement, the client sends a verification response responding to the verification instruction to the live broadcast platform server. Wherein the verification response comprises: and the client generates the calculation time of the calculation result and the identification information of the client. The specific implementation function is as follows:

type@＝VerifyRes/ResultData@＝596abbccdd78a12bcd9807463acddeab/Times@＝1000/Elapse@＝3000/TimeStamp@＝1540133335/DeviceId@＝aabbccdd；

the client side replies the message type of the verification protocol of the live platform server; ResultData @ 596 abbcdd 78a12bcd9807463 acddab is the calculation result of the client, and the data length is 32 bits long; times @ ═ 1000 indicates the number of Times the client calculates the encryption; elapse @ ═ 3000 represents the time milliseconds consumed by the client to calculate the whole result; TimeStamp @ 1540133335 is the TimeStamp used in the calculation; DeviceId @ ═ aabbcdd is the identification information of the client, i.e. the device unique ID.

107. The live broadcast platform server generates an encrypted KEY according to a preset algorithm and user information;

108. when the live broadcast platform server judges that the calculation result meets the verification requirement, the live broadcast platform server splices the random data and the calculation timestamp to obtain verification data;

109. the live broadcast platform server encrypts verification data according to the encryption KEY to obtain a verification value;

110. and if the verification value is consistent with the calculation result, the live broadcast platform server determines that the client is a credible client.

And after receiving the verification response sent by the client, the live broadcast platform server needs to verify the authenticity of the reported data of the client. The calculation mode of the live broadcast platform server is simpler than that of the client, so that a large amount of resources of the live broadcast platform server are not consumed. Firstly, a live broadcast platform server generates an encryption KEY according to a preset algorithm and user information, wherein the encryption KEY is the same as that of a client during calculation and use, and the method is specifically realized as follows:

KEY＝SHA512.Create(Timestamp 1+UserId+DeviceID+RoomId)；

create is the computing interface of HASH algorithm SHA512, Timestamp1 is used to represent the current Timestamp of the live platform server, UserID is used to represent user identification information, DeviceID is used to represent device identification information, and RoomID is used to represent room identification information. And after the live broadcast platform server obtains the encrypted KEY, decrypting the verification response according to the encrypted KEY to obtain the information contained in the verification response. After the information contained in the verification response is obtained, the live broadcast platform server firstly judges whether the calculation result reported by the client is an anchor and drift value meeting the requirements of the live broadcast platform server, and if the calculation result is not the anchor and drift value, the client is considered as forged data, namely the client is not credible; if yes, the live broadcast platform server performs encryption calculation once again to judge whether the client is calculated by the data sent by the live broadcast platform server. Firstly, a live broadcast platform server splices random data and a computation time stamp to obtain verification data, and the specific implementation function is as follows:

Char input[32]＝randdata+Timestamp；

wherein randdata is random data issued by a live platform server, Timestamp is a calculation Timestamp reported by a client and calculated when a verification requirement is met, and input [32] is 32-bit verification data; the live broadcast platform server encrypts verification data according to the encryption KEY to obtain a verification value, and the specific implementation function is as follows:

Blowfish_Encrypt(&ctx,input)；

wherein Blowfish _ Encrypt is an encryption interface of a bowfish encryption and decryption function, & ctx is a context environment variable of a Blowfish encryption algorithm, input is verification data, and a value obtained after encryption is a verification value. The live broadcast platform server judges whether the verification value is consistent with the calculation result reported by the client, if so, the data reported by the client is correct, and therefore, the client is judged to be a true and credible client.

In the embodiment of the application, the live broadcast platform server can realize the reliability of the verification client only by simple calculation, thereby increasing the verification efficiency of the live broadcast platform server and effectively relieving the load pressure of the live broadcast platform server.

The embodiments of the present application are described above from the perspective of a method for verifying the credibility of a client, and the embodiments of the present application are described below from the perspective of a live broadcast platform server and a client.

Referring to fig. 2a, fig. 2a is a schematic diagram of an embodiment of a possible live platform server according to an embodiment of the present application, where the live platform server specifically includes:

a transceiving unit 201, configured to send a verification instruction to a client, where the verification instruction is used to indicate a verification requirement that a computation result with a length of M generated by the client needs to meet, where the verification instruction includes a current timestamp of the live broadcast platform server, random data with a length of N, location information of an anchor point, a value P of the anchor point, and a value Q of a floating point, where the anchor point is a value at a specified location of the computation result that is P, the specified location is the location information of the anchor point, the floating point is a value that includes Q in the computation result, and M is greater than N; receiving a verification response sent by the client, wherein the verification response at least comprises the following information: the calculation result meeting the verification requirement and a calculation time stamp used in the calculation of the client;

a generating unit 202, configured to generate the encrypted KEY according to a preset algorithm and the user information, where the preset algorithm is determined by negotiation between the client and the live broadcast platform server; when the live broadcast platform server judges that the calculation result meets the verification requirement, splicing the random data and the calculation timestamp to obtain verification data;

the encryption unit 203 is configured to encrypt the verification data according to the encryption KEY to obtain a verification value;

a determining unit 204, configured to determine that the client is a trusted client if the verification value is consistent with the calculation result.

Referring to fig. 2b, fig. 2b is a schematic diagram of an embodiment of a possible client according to the present application, where the client specifically includes:

a receiving and sending unit 210, configured to receive a verification instruction sent by a live broadcast platform server, where the verification instruction is used to indicate a verification requirement that a calculation result with a length of M generated by the client needs to be met, the verification instruction includes a current timestamp of the live broadcast platform server, random data with a length of N, location information of an anchor point, a value P of the anchor point, and a value Q of a floating point, where the anchor point is a value P at an appointed location of the calculation result, the appointed location is the location information of the anchor point, the floating point is a value Q included in the calculation result, and M is greater than N;

a generating unit 220, configured to generate an encryption KEY according to user information based on a preset algorithm, where the preset algorithm is determined by negotiation between the client and the live broadcast platform server, the user information includes user identification information, device identification information, and room identification information, and a length of a current timestamp of the client is M-N; splicing the random data and the current timestamp of the client to obtain encrypted data with the length of M; generating the calculation result meeting the verification requirement according to the encrypted data and the encrypted KEY, and sending a verification response responding to the verification instruction to the live broadcast platform server, wherein the verification response at least comprises the following information: the client generates the calculation time length of the calculation result and the identification information of the client, so that the live broadcast platform server verifies whether the client is credible according to the verification response.

Referring to fig. 3a, fig. 3a is a schematic view of an embodiment of an electronic device according to an embodiment of the present disclosure.

As shown in fig. 3a, the embodiment of the present application provides an electronic device, which includes a memory 310, a processor 320, and a computer program 311 stored on the memory 320 and executable on the processor 320, and when the processor 320 executes the computer program 311, the following steps are implemented: sending a verification instruction to a client, wherein the verification instruction is used for indicating a verification requirement which needs to be met by a calculation result with the length of M and generated by the client, the verification instruction comprises a current timestamp of the live broadcast platform server, random data with the length of N, position information of an anchor point, a numerical value P of the anchor point and a numerical value Q of a floating point, the value of the anchor point at a specified position of the calculation result is P, the specified position is the position information of the anchor point, the floating point is that the calculation result comprises Q, and M is greater than N; receiving a verification response sent by the client, wherein the verification response at least comprises the following information: the calculation result meeting the verification requirement and a calculation time stamp used in the calculation of the client; generating the encrypted KEY according to the preset algorithm and the user information, wherein the preset algorithm is determined by negotiation between the client and the live broadcast platform server; when the live broadcast platform server judges that the calculation result meets the verification requirement, splicing the random data and the calculation timestamp to obtain verification data; encrypting the verification data according to the encryption KEY to obtain a verification value; and if the verification value is consistent with the calculation result, the live broadcast platform server determines that the client is a credible client.

As shown in fig. 3b, an electronic device according to the embodiment of the present application includes a memory 330, a processor 340, and a computer program 331 stored in the memory 340 and executable on the processor 340, where the processor 340 executes the computer program 331 to implement the following steps: receiving a verification instruction sent by a live broadcast platform server, wherein the verification instruction is used for indicating a verification requirement which needs to be met by a calculation result with the length of M and generated by a client side, the verification instruction comprises a current timestamp of the live broadcast platform server, random data with the length of N, position information of an anchor point, a numerical value P of the anchor point and a numerical value Q of a floating point, the anchor point is the value P at a specified position of the calculation result, the specified position is the position information of the anchor point, the floating point is the value Q included in the calculation result, and M is larger than N; generating an encryption KEY according to user information based on a preset algorithm, wherein the preset algorithm is determined by negotiation between the client and the live broadcast platform server, the user information comprises user identification information, equipment identification information and room identification information, and the length of a current timestamp of the client is M-N; splicing the random data and the current timestamp of the client to obtain encrypted data with the length of M; generating the calculation result meeting the verification requirement according to the encrypted data and the encrypted KEY, and sending a verification response responding to the verification instruction to the live broadcast platform server, wherein the verification response at least comprises the following information: the client generates the calculation time length of the calculation result and the identification information of the client, so that the live broadcast platform server verifies whether the client is credible according to the verification response.

Since the electronic device described in this embodiment is a device used for implementing a live platform server or a client in this embodiment, based on the method described in this embodiment, a person skilled in the art can understand a specific implementation manner of the electronic device of this embodiment and various variations thereof, so that how to implement the method in this embodiment by the electronic device is not described in detail herein, and as long as the person skilled in the art implements the device used for implementing the method in this embodiment, the device is within the scope of protection intended by this application.

Referring to fig. 4a, fig. 4a is a schematic diagram illustrating an embodiment of a computer-readable storage medium according to the present application.

As shown in fig. 4a, the present embodiment provides a computer-readable storage medium 400, on which a computer program 411 is stored, which computer program 411, when being executed by a processor, realizes the following steps: sending a verification instruction to a client, wherein the verification instruction is used for indicating a verification requirement which needs to be met by a calculation result with the length of M and generated by the client, the verification instruction comprises a current timestamp of the live broadcast platform server, random data with the length of N, position information of an anchor point, a numerical value P of the anchor point and a numerical value Q of a floating point, the value of the anchor point at a specified position of the calculation result is P, the specified position is the position information of the anchor point, the floating point is that the calculation result comprises Q, and M is greater than N; receiving a verification response sent by the client, wherein the verification response at least comprises the following information: the calculation result meeting the verification requirement and a calculation time stamp used in the calculation of the client; generating the encrypted KEY according to a preset algorithm and the user information, wherein the preset algorithm is determined by negotiation between the client and the live broadcast platform server; when the live broadcast platform server judges that the calculation result meets the verification requirement, splicing the random data and the calculation timestamp to obtain verification data; encrypting the verification data according to the encryption KEY to obtain a verification value; and if the verification value is consistent with the calculation result, the live broadcast platform server determines that the client is a credible client.

Referring to fig. 4b, fig. 4b is a schematic diagram illustrating an embodiment of a computer-readable storage medium according to the present application.

As shown in fig. 4b, the present embodiment provides a computer-readable storage medium 420 having a computer program 431 stored thereon, the computer program 431 when executed by a processor implementing the steps of: receiving a verification instruction sent by a live broadcast platform server, wherein the verification instruction is used for indicating a verification requirement which needs to be met by a calculation result with the length of M and generated by a client side, the verification instruction comprises a current timestamp of the live broadcast platform server, random data with the length of N, position information of an anchor point, a numerical value P of the anchor point and a numerical value Q of a floating point, the anchor point is the value P at a specified position of the calculation result, the specified position is the position information of the anchor point, the floating point is the value Q included in the calculation result, and M is larger than N; generating an encryption KEY according to user information based on a preset algorithm, wherein the preset algorithm is determined by negotiation between the client and the live broadcast platform server, the user information comprises user identification information, equipment identification information and room identification information, and the length of a current timestamp of the client is M-N; splicing the random data and the current timestamp of the client to obtain encrypted data with the length of M; generating the calculation result meeting the verification requirement according to the encrypted data and the encrypted KEY, and sending a verification response responding to the verification instruction to the live broadcast platform server, wherein the verification response at least comprises the following information: the client generates the calculation time length of the calculation result and the identification information of the client, so that the live broadcast platform server verifies whether the client is credible according to the verification response.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include such modifications and variations.

Claims

1. A method for verifying that a client is trusted, comprising:

a live broadcast platform server sends a verification instruction to a client, wherein the verification instruction is used for indicating a verification requirement which needs to be met by a calculation result with the length of M and generated by the client, the verification instruction comprises random data with the length of N, a current timestamp of the live broadcast platform server with the length of (M-N), position information of an anchor point, a value P of the anchor point and a value Q of a floating point, the anchor point is the value P at a specified position of the calculation result, the specified position is the position information of the anchor point, and the floating point comprises the value Q in the calculation result;

the client generates an encrypted KEY according to the user information;

the client splices the random data and the current timestamp of the client to obtain encrypted data with the length of M;

the client generates a calculation result meeting the verification requirement according to the encrypted data and the encrypted KEY;

the live broadcast platform server receives a verification response sent by the client, wherein the verification response at least comprises the following information: the calculation result meeting the verification requirement and a calculation time stamp used in the calculation of the client;

the live broadcast platform server generates the encrypted KEY according to a preset algorithm and the user information, wherein the preset algorithm is determined by negotiation between the client and the live broadcast platform server;

when the live broadcast platform server judges that the calculation result meets the verification requirement, the live broadcast platform server splices the random data and the calculation timestamp to obtain verification data;

the live broadcast platform server encrypts the verification data according to the encryption KEY to obtain a verification value;

if the verification value is consistent with the calculation result, the live broadcast platform server determines that the client is a credible client;

the client generates the encrypted KEY according to the user information, and the method comprises the following steps:

the client calculates the encryption KEY by:

KEY＝SHA512.Create(Timestamp+UserID+DeviceID+RoomID)；

wherein the SHA512.Create is a computing interface of a HashSH algorithm SHA512, the Timestamp is used for representing a current Timestamp of the client, the UserID is used for representing user identification information, the DeviceID is used for representing device identification information of the client, and the RoomID is used for representing room identification information;

the client splices the random data and the current timestamp of the client to obtain the encrypted data with the length of M, and the method comprises the following steps:

Char input[M]＝randdata+nCurrentTime；

wherein input is the encrypted data, randdata is the random data, and nCurrentTime is the current timestamp.

2. The method of claim 1, wherein the generating the encrypted KEY by the live platform server according to the preset algorithm and the user information comprises:

the live broadcast platform server calculates the encrypted KEY in the following way:

KEY＝SHA512.Create (Timestamp1+UserID+DeviceID+RoomID)；

wherein the Timestamp1 is used to indicate the current Timestamp of the live platform server.

3. The method of claim 1, wherein the encrypting, by the live platform server, the authentication data according to the encrypted KEY to obtain an authentication value comprises:

the live broadcast platform server obtains the verification value through the following encryption algorithm:

Blowfish_Encrypt(&ctx,input)；

Char input[M]＝randdata+Timestamp2；

the Blowfish _ Encrypt () is an encryption interface of a Blowfish encryption algorithm, an output value of the encryption interface is the verification value, the & ctx is a context variable of the Blowfish encryption algorithm, the input is the verification data, the randdata is the random data, and the Timestamp2 is the computation Timestamp.

4. A method for verifying that a client is trusted, comprising:

a client receives a verification instruction sent by a live broadcast platform server, wherein the verification instruction is used for indicating a verification requirement which needs to be met by a calculation result with the length of M and generated by the client, the verification instruction comprises random data with the length of N, a current timestamp of the live broadcast platform server with the length of (M-N), position information of an anchor point, a numerical value P of the anchor point and a numerical value Q of a drift point, the anchor point is the value P at a specified position of the calculation result, the specified position is the position information of the anchor point, and the drift point comprises the Q in the calculation result;

based on a preset algorithm, the client generates an encryption KEY according to user information, the preset algorithm is determined by negotiation between the client and the live broadcast platform server, the user information comprises user identification information, equipment identification information and room identification information, and the length of a current timestamp of the client is M-N;

the client generates the calculation result meeting the verification requirement according to the encrypted data and the encrypted KEY and sends a verification response responding to the verification instruction to the live platform server, wherein the verification response at least comprises the following information: the client generates the calculation time length of the calculation result and the identification information of the client so that the live broadcast platform server verifies whether the client is credible according to the verification response;

wherein verifying whether the client is trusted specifically comprises;

if the verification value is consistent with the calculation result, the live broadcast platform server determines that the client is a credible client; the client generates the encrypted KEY according to the user information, and the method comprises the following steps:

the client calculates the encryption KEY by:

KEY＝SHA512.Create (Timestamp+UserID+DeviceID+RoomID)；

Char input[M]＝randdata+nCurrentTime；

5. The method of claim 4, wherein the client generating the computation result satisfying the verification requirement according to the encrypted data and the encrypted KEY comprises:

the client side encrypts the encrypted data through the following encryption algorithm to obtain an encryption result:

Blowfish_Encrypt(&ctx,input)；

Char input[M]＝randdata+Timestamp3；

wherein, the Blowfish _ Encrypt () is an encryption interface of a Blowfish encryption algorithm, an output value of the encryption interface is the encryption result, the & ctx is a context variable of the Blowfish encryption algorithm, the input is the encrypted data, the randdata is the random data, and the Timestamp3 is the current Timestamp of the client;

the client side judges whether the encryption result meets the verification requirement or not;

if the encryption result does not meet the verification requirement, the client circularly encrypts the encrypted data by calling a while function until the encryption result meets the verification requirement, wherein the encryption result meeting the verification requirement is the calculation result, and the Timestamp3 is the current Timestamp of the client at each circulation.

6. The method of claim 5, wherein the determining, by the client, whether the encryption result satisfies the authentication requirement comprises:

the client judges whether the value of the encryption result at the specified position is the P or not;

if the value at the designated position is not the P, the client determines that the encryption result does not meet the verification requirement;

if the value at the designated position is P, the client judges whether the encryption result contains Q;

if the value at the designated position is P and the encryption result comprises Q, the client determines that the encryption result meets the verification requirement;

if the encryption result does not contain the Q, the client determines that the encryption result does not meet the verification requirement.

7. A live platform server, comprising:

a transceiving unit, configured to send a verification instruction to a client, where the verification instruction is used to indicate a verification requirement that a computation result with a length of M generated by the client needs to meet, where the verification instruction includes random data with a length of N, a current timestamp of the live broadcast platform server with a length of (M-N), location information of an anchor point, a value P of the anchor point, and a value Q of a floating point, where the anchor point is the value at a specified location of the computation result that is P, the specified location is the location information of the anchor point, and the floating point is a value that includes Q in the computation result; receiving a verification response sent by the client, wherein the verification response at least comprises the following information: the calculation result meeting the verification requirement and a calculation time stamp used in the calculation of the client;

the generating unit is used for generating an encryption KEY according to a preset algorithm and user information, wherein the preset algorithm is determined by negotiation between the client and the live broadcast platform server; when the live broadcast platform server judges that the calculation result meets the verification requirement, splicing the random data and the calculation timestamp to obtain verification data;

the encryption unit is used for encrypting the verification data according to the encryption KEY to obtain a verification value;

the determining unit is used for determining that the client is a credible client if the verification value is consistent with the calculation result;

the client generates an encrypted KEY according to the user information;

the client calculates the encryption KEY by:

KEY＝SHA512.Create (Timestamp+UserID+DeviceID+RoomID)；

Char input[M]＝randdata+nCurrentTime；

8. A client, comprising:

a receiving and sending unit, configured to receive a verification instruction sent by a live broadcast platform server, where the verification instruction is used to indicate a verification requirement that a calculation result with a length of M generated by the client needs to be met, where the verification instruction includes random data with a length of N, a current timestamp of the live broadcast platform server with a length of (M-N), location information of an anchor point, a value P of the anchor point, and a value Q of a floating point, where the anchor point is the value at an appointed location of the calculation result of P, the appointed location is the location information of the anchor point, the floating point is that the calculation result includes Q, and M is greater than N;

the system comprises a generating unit, a receiving unit and a processing unit, wherein the generating unit is used for generating an encryption KEY according to user information based on a preset algorithm, the preset algorithm is determined by negotiation between a client and a live broadcast platform server, the user information comprises user identification information, equipment identification information and room identification information, and the length of a current timestamp of the client is M-N; splicing the random data and the current timestamp of the client to obtain encrypted data with the length of M; generating the calculation result meeting the verification requirement according to the encrypted data and the encrypted KEY, and sending a verification response responding to the verification instruction to the live broadcast platform server, wherein the verification response at least comprises the following information: the client generates the calculation time length of the calculation result and the identification information of the client so that the live broadcast platform server verifies whether the client is credible according to the verification response;

wherein verifying whether the client is trusted specifically comprises;

if the verification value is consistent with the calculation result, the live broadcast platform server determines that the client is a credible client; wherein generating the encrypted KEY according to the user information comprises:

the client calculates the encryption KEY by:

KEY＝SHA512.Create (Timestamp+UserID+DeviceID+RoomID)；

splicing the random data and the current timestamp of the client to obtain encrypted data with the length of M, wherein the method comprises the following steps:

Char input[M]＝randdata+nCurrentTime；

9. A computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the method of any of claims 1-6.