20,283 reputation
12786
bio website
location Paris, France
age
visits member for 3 years, 2 months
seen 35 mins ago

I'm an engineer with experience in applied cryptography, in particular in Smart Card systems.


Oct
15
answered Database row level encryption scheme
Oct
15
comment Encrypted read-only message queue
Also: because RSA allows fast signature verification, it is a good candidate for the signature from an efficiency standpoint if reading and forwarding with integrity verification largely predominates writing/signing. If signature size overhead is an issue, RSA signature with message recovery can help reduce the signature overhead (e.g. to 34 bytes with ISO/IEC 9796-2 scheme 3 using SHA-256, with encrypted message of at least 222 bytes and 2048-bit RSA). $\;$ AES-CTR encryption/decryption is fast, and its size overhead is limited to the IV (e.g. 10 bytes for a counter to $2^{80}$).
Oct
15
comment Encrypted read-only message queue
Yes. The key for encrypting and decrypting the messages can (and should) be that of a symmetric algorithm, e.g. AES-CTR with suitably random or sequential IV, and known to groups 1 and 2. $\;$ Signing should be on the enciphered data, using an asymmetric signature algorithm (e.g. RSA with PKCS#1v2 signature padding), with the private key known to members of group 1, and the public key known to all (as implied by its name). $\;$ Everyone (except possibly from group 3) should verify signature of enciphered data manipulated.
Oct
15
revised Are LFSRs enough for this?
Polish, better distinguishing ticket and value on ticket.
Oct
15
comment Are LFSRs enough for this?
@mpr: I tried to address your comments in the answer, including generalizing to $m$ consecutive colluding players. $\;$ Notice that I have made no statement whatsoever about when we are safe, thus have not answered the question asked in the above comment.
Oct
15
revised Are LFSRs enough for this?
Generalize the initial exposition to m collusing players, and improve the bound; polish.
Oct
15
revised Are LFSRs enough for this?
Comment on nature of the uncertainty
Oct
15
revised Are LFSRs enough for this?
Polish, discuss 2/3 of colluding players
Oct
14
comment Is it true the longer the key length is the more secure the encryption?
I do not think that "under certain kinds of attacks AES-256 is actually easier to break than AES-128": the increase in key size gives much more security, thus not $2^{128}$ times more.
Oct
14
revised Are LFSRs enough for this?
Update per comment
Oct
14
answered Are LFSRs enough for this?
Oct
14
comment Are LFSRs enough for this?
I do not think that my first comment needs to be incorporated in the question. $\;$ Is it correct that the adversary knows the value on every ticket, and wants to assign which ticket was generated by which player, with odds better than random?
Oct
14
comment Are LFSRs enough for this?
On the problem: Are the experimenters that collude with the adversary capable of $\;$ a) telling which number they drew? $\;$ b) telling exactly when they pressed the button? $\;$ c) pressing the button at a chosen instant?
Oct
14
comment Are LFSRs enough for this?
Incidentally: we know how to tweak an LFSR with a primitive polynomial of degree $b$ into a generator with almost identical output save for an extra 0, making the period $2^b$ rather than $2^b-1$, and insuring that the generator can't become stationary when complemented; see this.
Oct
14
revised What is the recommended replacement for MD5?
RIPEMD-128 is NOT broken, despite the article proclaiming "Cryptanalysis of Full RIPEMD-128"
Oct
13
revised online Vickrey auction using remote coin flip
Fix title, define Vickrey auction
Oct
13
revised How does order-preserving encryption work?
Link to cited paper; we want an injective function so that deciphering works.
Oct
11
revised How does MD5 process text which is shorter than 512 bits
Minor fixes
Oct
10
comment How does MD5 process text which is shorter than 512 bits
Take care that MD5's endianness is quite pervert. The encoding of bits in bytes is big-endian (as shown by the fact the padding byte is 0x80, not 0x01), but the encoding of bytes in 32-bit words is little-endian. $\;$ IIRC, in the landmark paper with the first MD5 collision there was some endianness issue in the first version, and that needed the collision search to be performed all over again.
Oct
10
revised How does MD5 process text which is shorter than 512 bits
fix typos