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

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
accepted Replay attack prevention under strict conditions
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.
Jun
1
revised Replay attack prevention under strict conditions
added 76 characters in body
Jun
1
asked Replay attack prevention under strict conditions
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$.
May
3
revised Creating an encryption key from several other keys and using hash functions
added 2 characters in body
May
3
answered Creating an encryption key from several other keys and using hash functions
Apr
22
awarded  Talkative
Apr
22
comment How to perform file encryption using 128-Bit AES?
let us continue this discussion in chat
Apr
22
comment How to perform file encryption using 128-Bit AES?
@John Paul Parreño Such questions are better suited for Stack Overflow. Word of advice, if you are new to cryptography and wish to implement a cipher yourself, I'd suggest trying something simpler than AES at first, such as RC6.