Re: [cryptography] RSA signatures without padding
This paper probably helps answering part of your question : http://www.iacr.org/archive/crypto2000/18800229/18800229.pdf Note that you can't replace a random oracle by SHA256 but you might have better luck with HMAC-SHA256 (https://eprint.iacr.org/2013/382.pdf) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
I still think it's important that TRNGs be practical in real usage contexts. As mundane as it sounds, perhaps the safest practice is just to ask the user to enter 50 random digits when they install the OS (or shake the mouse or whatever). At some point (100 digits?), even an uncreative person is going to produce enough entropy to be worth 128+ bits. From that point on, it's all CSPRNG. That way, we don't need to worry about timedelta predictability or how to securely acquire a new USB randomness device when it gets lost somewhere far away from the IT department. I see a few problems with that. First 128 bits of entropy is a lot to ask from a human and you'll end up with a string of however many 'a' character you asked for. I personally don't think you can blame any of that on the user : how should he know or care that it is important ? Where is he supposed to find those 100+ (that seems low actually) digits. passwords have thought us that when users don't care we end up with extremely low variability Another issue is in a lot of cases (think cloud/virtualization) OS are setup without human interaction. Last thing is you can't completely rely on a well seeded CSPRNG forever : you need to be able to reseed it in case of compromise and since you won't necessarily know when the compromise happened it's good practice to reseed from time to time -- Alexandre Anzala-Yamajako ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
The confidence in AES comes from its designation process during which many publicly tried and failed to convincingly reduce its security claim and the fact that it has (publicly still) stood the test of time : ten years later all we have are the bicliques which gains us 2 bits. It doesn't have much to do with the fact that it is state sponsored ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Client certificates, Tor-exit nodes and renegotiation
It also might be worthwhile to note that Client certification is not very common and needs an infrasctructure to generate and deploy. Also even if the client certificate is sent encrypted later in the handshake, it's size will be noticeable in the handshake (except if we are ready to pad certificate-less client messages). A competent and funded organization might then have a very small pool of users to choose from as to who might be trying to connect a particular server which somewhat defeats the purpose of Tor -- Alexandre Anzala-Yamajako ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Privacy Enforced [was: Comsec as Public Utility Beyond Illusory Privacy]
If OpenSSL has taught us one thing over the years it's that collaborative dev doesn't mean perfection and far from it. Also this : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0092 Also your first point sounds a lot like privacy is not a right you have but something that has to earned through technical expertise -- Alexandre Anzala-Yamajako ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
