Tag Info

The huge key is definitely an issue. Another is the lack of standardization or recommendations. Should you use OAEP with McEliece, or some other padding? What parameters are actually secure? And so on. Part of the problem is that, while it has been around since the 70s, it was not considered particularly interesting until quite recently—so it probably ...

Wide adoption of an asymmetric encryption algorithm, or a digital signature algorithm, requires at least the following: There must exist a reasonably clear standard which unambiguously says where each byte goes. It must cover endianness and similar issues. PKCS#1 is such a standard, for RSA. The algorithm must provide reasonably good performance, in ...

Yes there are. The first publicly accessible McEliece implementation was this one from The Error Correcting Codes (ECC) Page, but it isn't particularly useful for reading, being quite obfuscated. There's INRIA's SECRET group implementation called HyMES that implements something quite similar. FlexiProvider (java library) contains quite a good amount of ...

We looked into post-quantum digital signature schemes for the Tahoe-LAFS "100 Year Cryptography" project but I stopped looking at all but one of them when David-Sarah Hopwood observed that they all rely on a secure hash function to generate a message representative for the digital signature scheme to sign. Therefore, all of them (except for that one) are ...

While McEliece could be used like a block cipher, in practice it would much must slower than the standard hybrid approach. McEliece might be relatively fast compared to other public key primitives, it is still quite slow compared to a symmetric cipher. On the Ecrypt performance page, they list the performance of McEliece on various hardware platforms; the ...