Thomas Pornin

19,112 reputation

13571

bio	website	bolet.org/~pornin
	location	Quebec City, Canada
	age	37
visits	member for	1 year, 10 months
	seen	May 17 at 22:22
stats	profile views	284

Cryptographer, programmer in several languages (C, Java, several assemblies, Pascal, Forth...). I also have a life.

	19,112 reputation	bio	website	bolet.org/~pornin	visits	member for	1 year, 10 months
13571 badges		location	Quebec City, Canada		seen	May 17 at 22:22

summary answers questions tags badges favorites bounties reputation activity

612 Actions

suggestions reviews revisions comments badges posts accepts all

Jul 14	answered	Are there any tools for expressing the cipher operations as a system of equations?
Jul 14	comment	Is using slow password hashing on the client side easier attackable than on the server side? @Paũlo: mmh... you are right. Unless you use the user name (and server address) as salt, something which I have previously advocated against, on the basis that it does not handle password change. So yeah, you are up for an extra initial message (and response) with the user name as request, and the salt and iteration count as response.
Jul 14	comment	Is using slow password hashing on the client side easier attackable than on the server side? @Paũlo: it can be made user-definable, but such information will be stored on the server, so it must be transferred to the client sufficiently early in the process -- which entails transmitting the user name first, so there will be an extra message, which can induce latency, or a modification of the TLS-with-SRP protocol, which is (on a general basis) a bad idea. I would recommend using the "sensible minimum" for every user, and hardcode it in the client. Also, this allows running the bcrypt-thingy before doing the network connection.
Jul 14	answered	Is using slow password hashing on the client side easier attackable than on the server side?
Jul 14	comment	Is using slow password hashing on the client side easier attackable than on the server side? I would say that your first question ("is there already such a protocol ?") is security.SE stuff, while your second question ("is there any weakness in this protocol ?") belongs to crypto.SE.
Jul 14	reviewed	Approve suggested edit on What are the details of the DES weakness of reusing the same IV in CBC mode with the same key?
Jul 14	answered	RSA with small exponents?
Jul 13	comment	Should DES be avoided when developing new systems? @uygar.raf: strictly speaking, these algorithms are defined by FIPS 46-3, which is called "Data Encryption Standard", or "DES" for short. DES defines two algorithms, called "DEA" (Data Encryption Algorithm) and "TDEA" (Triple-DEA), the latter consisting of three cascaded instances of DEA. So DES designates both DEA and TDEA. But there are also other "traditional" conventions, where DES is DEA only, and TDEA is called 3DES. Or DESede. Or sometimes "DES with a 168-bit key". There is a terminology issue.
Jul 13	answered	Modern integer factorization software
Jul 13	awarded	Quorum
Jul 13	answered	Known methods for constant time (table-free) AES implementation using 'standard' operations?
Jul 13	awarded	Enlightened
Jul 13	answered	Protocol to generate Client Certificates at the start of a SSL session automatically?
Jul 13	answered	What are the details of the DES weakness of reusing the same IV in CBC mode with the same key?
Jul 13	answered	Should DES be avoided when developing new systems?
Jul 13	awarded	Nice Answer
Jul 13	awarded	Enlightened
Jul 12	awarded	Nice Answer
Jul 12	comment	Necessity of Randomness of Salts? @Paũlo: old passwords are valuable for an attacker, because they could be valid passwords for the same user on other systems; old passwords can also be very new passwords: some (many ?) users "rotate" in a list of 2 or 3 passwords.
Jul 12	answered	Necessity of Randomness of Salts?