meta user
network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 9 months |
| seen | Feb 6 at 14:14 | |
| stats | profile views | 18 |
|
Jul 31 |
comment |
Most effect way to brute force 16 char AES key @Thomas The process could be sped up significantly by utilizing a GPU in combination with an AES-NI CPU. |
|
Jul 19 |
comment |
How to hack the new save encryption on ipad for uplink? Do you have the specifications for the REDSHIRT and REDSHIRT2 ciphers? A quick search led me to believe that one of the two is a simple XOR cipher, and I assume that so is the other. |
|
Jul 19 |
comment |
How to hack the new save encryption on ipad for uplink? I took a look at an iPad Uplink save file ( [NAME].usr). Its contents do not look by any means encrypted. If you cannot parse the save file directly, you might want to convert it into a Mac/PC save file (by replacing SAV62 with REDSHRT2 and XORing every byte afterward with 0x80 - assuming I understood the format correctly). |
|
Jun 16 |
comment |
HMAC vs MAC functions The same as any other MAC algorithm. HMAC just has the added advantage that it doesn't require a MAC IV. Its typical uses are the same as any other MAC algorithm, ensuring the authenticity and integrity of a transmitted message for example. |
|
Jun 16 |
comment |
HMAC vs MAC functionsHMAC is a MAC algorithm. The term MAC algorithm refers to any algorithm that authenticates a message. There are other MAC algorithms besides HMAC, such as VMAC. |
|
Jun 16 |
comment |
Is it possible to use the RSA algorithm, or a variant, for software licensing? @Maeher I think he means using the private key for encryption and the public key for decryption, which is possible and similar to signing. |
|
Jun 10 |
comment |
Is HMAC-DRBG or Hash-DRBG stronger? Thank you @Paulo Ebermann, I missed the appendices. |
|
Jun 10 |
comment |
Is HMAC-DRBG or Hash-DRBG stronger? Is there any information on the initial value of $V$? |
|
Jun 9 |
comment |
Padding for the TEA The terms "PKCS#5 padding" and "PKCS#7 padding" are used interchangeably, they essentially mean the same thing. |
|
Jun 9 |
comment |
Padding for the TEA My previous comment equally applies to ECB mode. However, I'd suggest using another mode of operation. See the following page for more details: en.wikipedia.org/wiki/Block_cipher_modes_of_operation |
|
Jun 9 |
comment |
Padding for the TEA The method described in PKCS#5 is the most commonly used way, but there is no "default". I'm assuming you are using TEA in CBC mode. |
|
Jun 6 |
comment |
Are there any simple and yet secure encryption algorithms? @fgrieu Under most scenarios that holds true, but does that exclude the related-key attacks on (full, 64-round) TEA from being security issues? After all, between a (full) cipher that suffers from a related-key attack and one that does not, would you not choose the one that does not for a practical purpose? I am of course referring to the 64-round versions of both TEA and XTEA. Should, any more severe attacks on full 64-round XTEA surface, I will be the first to admit I was wrong. |
|
Jun 5 |
comment |
Are there any simple and yet secure encryption algorithms? @fgrieu I consider the related-key attack on TEA more severe than the attacks on XTEA. I did not say that all revisions are improvements, I wouldn't use XXTEA for example. |
|
Jun 4 |
comment |
Are there any simple and yet secure encryption algorithms? @fgrieu I'd recommend XTEA, it is as simple as TEA but, as far as we know, more secure. |
|
Jun 3 |
comment |
Replay attack prevention under strict conditions @PaŭloEbermann Correct, in HTTPS the server is always authenticated (but a client-authenticated TLS handshake is possible). Ignore my above comparison, it is flawed at best. |
|
Jun 1 |
comment |
Replay attack prevention under strict conditions @PaŭloEbermann The authenticated party sends the requests and the other party responds. In that sense it is very similar to HTTP(S). |
|
Jun 1 |
comment |
Replay attack prevention under strict conditions My apologies @CodeInChaos, it seems I initially misunderstood your concept. Thank you everyone for the help. |
|
Jun 1 |
comment |
Replay attack prevention under strict conditions By not sequential I mean that requests should be able to be sent in parallel without errors caused by the defense mechanism. I have considered a similar idea to the one you proposed, unfortunately both violate the "sequential rule". Say I send a request A, and then a request B. There is no guarantee that request A will arrive before request B (request A might be orders of magnitude larger), hence this will cause errors. Leaving space for these errors is, by definition, bound to cause replay attack opportunities. |
|
May 23 |
comment |
How were the number of rounds for different key sizes of AES selected? As to the choice for the round numbers? Have a look at this document: csrc.nist.gov/archive/aes/rijndael/Rijndael-ammended.pdf. Note the "Number of rounds" section under "Motivation for design choices". |
|
May 21 |
comment |
How were the number of rounds for different key sizes of AES selected? $N_r = len(key)/4 + 6$. |
