1,529 Comments

Customizable Crypto Algorithms in HardwareMost HSM's provide such capability. Usually they are embedded processors inside a tamper proof housing. Systems on a board really, although the SoB acronym is already taken. There still seems to be a market demand for custom algorithms. These kind of HSM's simply fill demand. I don't think the providers themselves are that keen on custom algorithms, but as long as you pay and take the blame... Personally I'm more interested in running custom protocols / applications on them; a hardware token that performs crypto for anyone after a single PIN isn't that useful.

Extend OTP on random data?Yes, precisely that and the fact that such a large key is very inefficient. Side notes: even though OTP is perfectly secure it still leaks the size of the plaintext and it doesn't provide integrity / authenticity either.

3h

comment

Extend OTP on random data?The key stream in OTP must be random. OTP is mainly a theoretical construct. If the key stream anywhere relies on previous data then it's not OTP but a stream cipher. There are pretty good stream ciphers out there and you can easily turn a block cipher into a key stream (e.g. CTR mode of operation). In that case you just need a key of around 128 bits and you'd be pretty safe.

Is this variant of SRP useful?Steve, this Q/A site isn't really the best place to perform initial analysis of new algorithms as you may have found out. Invariably you end up with open ended answers, or with disagreeing with the opinion formed by the community. This particular answer is 1) not accepted and 2) doesn't really come to a conclusion. Could you try and add both?

10h

comment

Is the GOST block cipher broken?Yep, my idea exactly. This is why I mentioned the "amount of memory" even before the "amount of processing"... Still, it seems this cipher loses even more security than DES for specific attacks. It's that they start off at 256 bit that saves the cipher against practical attacks.

What is the advantage of AEAD ciphers?During encryption you can directly feed the plaintext to the internal encryption function (e.g. to perform CTR mode encryption in GCM, EAX or CCM). You can directly store the ciphertext, possibly in place. You cannot do this during decryption because you may be either dealing with the ciphertext or the tag. So you get update functions that return more or less plaintext compared to the ciphertext. If you have a doFinal method it may still need to return plaintext as well. So you need special buffer handling for decryption, not encryption. In implementations (Bouncy) it takes 33% more room.

2d

comment

What is the advantage of AEAD ciphers?Note that I think it is extremely stupid to include the authentication tag directly in the ciphertext as RFC 5116 does. It requires the decryption side to buffer the ciphertext until the location of the authentication tag is found. This makes for a horrible implementation that is not online nor symmetric for encryption/decryption. API developers certainly should not follow this example. I really should make this a blog post soon.

Why calculate pi to estimate randomness?@tylo fgrieu's answer seems new as well. I'm not sure which one came first, but this information certainly seems to be in the second paragraph of the answer of fgrieu, which would make this answer redundant.

How can I read the AE figures?I think the tweak (e.g. just a counter) is already supposed to be in there, otherwise scheme 2 would violate CPA (if $M_1 = M_3$ it would clearly show up as $C_1 = C_3$, and authentication would be vulnerable for similar reasons).