457 reputation
312
bio website
location
age
visits member for 3 years, 4 months
seen Jul 2 at 0:55

Oct
26
comment Timing Attacks on ECDSA, ECDHE, AES and SHA2
Thank you for the detailed explanation.
Jul
31
comment What would be the most effective way to brute force a 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 functions
HMAC 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".