eggyal

137 reputation

bio	website
	location
	age
visits	member for	1 year, 7 months
	seen	Jul 3 '12 at 19:42
stats	profile views	3

	137 reputation	bio	website		visits	member for	1 year, 7 months
7 badges		location			seen	Jul 3 '12 at 19:42

summary answers questions tags badges favorites bounties reputation activity

22 Actions

suggestions reviews revisions comments badges posts accepts all

Jun 25	awarded	Citizen Patrol
Jun 25	awarded	Commentator
Jun 25	awarded	Promoter
Jun 25	comment	How much computing resource is required to brute-force RSA? Thanks, but I'd really meant that once the factorisation you give has been discovered it can then be applied wherever the given product needs to be factorised. Over forty years with vast computing resources, many such factorisations could be discovered. I find @Maeher's answer more convincing in countering this argument, as it helps me to realise that the number of such factorisations required to be generated and stored even for 1024-bit RSA moduli is so vast that it is simply not reasonable even to hope for a collision with a known key.
Jun 25	accepted	How much computing resource is required to brute-force RSA?
Jun 25	comment	How much computing resource is required to brute-force RSA? Thank you for all of the additional links - lots of very useful reading! I suppose my perspective was whether due consideration had been given not only to the challenge of breaking RSA today from a zero-starting point, but had also factored in 40 years of effort?
Jun 25	awarded	Supporter
Jun 25	accepted	Incorporating known ciphertext into new message
Jun 25	awarded	Scholar
Jun 25	accepted	How can I encrypt + authenticate short strings into similar short ciphertexts?
Jun 25	asked	How much computing resource is required to brute-force RSA?
Jun 22	awarded	Editor
Jun 12	comment	Incorporating known ciphertext into new message @mikeazo: Trent will not know $p_1$, that's correct (it would otherwise be a trivial problem, I think?); however he will know (indeed, he will generate) $p_2$ as that would be the HTTP headers and/or other application-layer encapsulation of Alice's message. Alice and Bob do indeed have public/private key pairs.
Jun 12	comment	Incorporating known ciphertext into new message Okay, this was a dumb question as the actual session key negotiated between Trent and Bob won't be known by Alice in advance of that session. I presume therefore that there will need to be a higher encryption layer between Alice and Bob; it is simply not possible for Trent to store and forward HTTPS messages?
Jun 11	comment	Incorporating known ciphertext into new message What if the two messages are of different lengths? In my case, $p_2$ would be HTTP headers (generated by Trent) whilst $p_1$ is some arbitrary length message... Alice could inform Trent of its length if that wouldn't impair secrecy.
Jun 11	comment	Incorporating known ciphertext into new message @poncho: Duh, good point! Assume asymmetric cipher where only public key is known. I'm trying to devise means for Alice to store with Trent a message destined for Bob; Trent will later forward that message to Bob over pure HTTPS.
Jun 11	asked	Incorporating known ciphertext into new message
Oct 18	comment	How can I encrypt + authenticate short strings into similar short ciphertexts? @PaŭloEbermann: Agreed. I have started a new question on SO seeking suggestions for excellent compression rates given the particular structure of domain names - see stackoverflow.com/questions/7801753/…
Oct 17	comment	How can I encrypt + authenticate short strings into similar short ciphertexts? My leaning towards HMAC came from an earlier thought to only encrypt the domain and add an HMAC in the clear for authentication, intended to reduce the length of the result if encoding the ciphertext resulted in a string of greater length than the plaintext (as it does here). Perhaps it would also be useful to compress the plaintext, e.g. encode TLDs, many popular SLDs and common letter combinations and express the remainder in base 38? I fear space really is of the essence, as some validators will reject an address with as few as 30 characters - including the remainder of the email address!
Oct 17	comment	How can I encrypt + authenticate short strings into similar short ciphertexts? It feels to me that a sequence of $m$ zeroes provides relatively weak authentication, especially considering that strong authentication is of greater priority than strong confidentiality. I propose instead appending a separation marker (perhaps ASCII US 0x1f) followed by e.g. the first $m-1$ characters of an HMAC, such as MD5(plaintext + key). Indeed, if the authentication code is of a fixed length, it could prefix the plaintext and avoid having the separation marker at all. Otherwise your scheme feels good, albeit the resulting strings may be longer than many validators will accept.