Re: road toll transponder hacked
Bill Frantz writes, in part: -+-- | In the San Francisco Bay Area, they are using the transponder codes | to measure how fast traffic is moving from place to place. They | post the times to various destinations on the electric signs when | there are no Amber alerts or other more important things to | display. It is quite convenient, and they promise they don't use it | to track people's trips. | Look for general tracking to appear everywhere. Fast declining gasoline tax revenues will be replaced with per-mile usage fees, i.e., every major road becomes a toll road. Most likely first in will be California and/or Oregon. The relationship to this list may then be thin excepting that the collection and handling of such data remains of substantial interest. Of course, everyone who carries a cell phone has already decided that convenience trumps security, at least the kind of security that says they can't misuse what they ain't got. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Decimal encryption
Hi, I am searching for symmetric encryption algorithms for decimal strings. Let's say we have various 40-digit decimal numbers: 2349823966232362361233845734628834823823 3250920019325023523623692235235728239462 0198230198519248209721383748374928601923 As far as I calculated, a decimal has the equivalent of about 3,3219 bits, so with 40 digits, we have about 132,877 bits. Now I would like to encrypt those numbers in a way that the result is a decimal number again (that's one of the basic rules of symmetric encryption algorithms as far as I remember). Since the 132,877 bits is similar to 128 bit encryption (like eg. AES), I would like to use an algorithm with a somewhat comparable strength to AES. But the problem is that I have 132,877 bits, not 128 bits. And I can't cut it off or enhance it, since the result has to be a 40 digit decimal number again. Does anyone know a an algorithm that has reasonable strength and is able to operate on non-binary data? Preferrably on any chosen number-base? Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Decimal encryption
At Wed, 27 Aug 2008 17:05:44 +0200, Philipp Gühring wrote: Hi, I am searching for symmetric encryption algorithms for decimal strings. Let's say we have various 40-digit decimal numbers: 2349823966232362361233845734628834823823 3250920019325023523623692235235728239462 0198230198519248209721383748374928601923 As far as I calculated, a decimal has the equivalent of about 3,3219 bits, so with 40 digits, we have about 132,877 bits. Now I would like to encrypt those numbers in a way that the result is a decimal number again (that's one of the basic rules of symmetric encryption algorithms as far as I remember). Since the 132,877 bits is similar to 128 bit encryption (like eg. AES), I would like to use an algorithm with a somewhat comparable strength to AES. But the problem is that I have 132,877 bits, not 128 bits. And I can't cut it off or enhance it, since the result has to be a 40 digit decimal number again. Does anyone know a an algorithm that has reasonable strength and is able to operate on non-binary data? Preferrably on any chosen number-base? There are a set of techniques that allow you to encrypt elements of arbitrary sets back onto that set. The original paper on this is: John Black and Phillip Rogaway. Ciphers with arbitrary ?nite domains. In CT-RSA, pages 114?130, 2002. For a modern proposal to make this a NIST mode, see: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ffsem/ffsem-spec.pdf -Ekr Full Disclosure: Terence Spies, the author of the FFSEM proposal, works for Voltage, Voltage has a product based on this technology. and I'm on Voltage's TAB and have done some work for them. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
On Aug 27, 2008, at 7:10 AM, [EMAIL PROTECTED] wrote: The relationship to this list may then be thin excepting that the collection and handling of such data remains of substantial interest. Actually, it points to cash settlement of road tolls. Most likely digital bearer transaction settlement, in the long run. But y'all knew I'd say that, right? :-) Cheers, RAH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Decimal encryption
=?ISO-8859-15?Q?Philipp_G=FChring?= [EMAIL PROTECTED] writes: Does anyone know a an algorithm that has reasonable strength and is able to operate on non-binary data? Preferrably on any chosen number-base? I posted a description of how to perform encryption in limited subranges to sci.crypt about ten years ago, http://groups.google.com/groups?hl=enlr=ie=UTF-8threadm=5c8sin%24piv%40scream.auckland.ac.nzrnum=1prev=/groups%3Fq%3D%2B%2522ASCII%2522%2Bgroup:sci.crypt%2Bauthor:Peter%2Bauthor:Gutmann%26hl%3Den%26lr%3D%26ie%3DUTF-8%26as_drrb%3Db%26as_mind%3D12%26as_minm%3D5%26as_miny%3D1996%26as_maxd%3D17%26as_maxm%3D7%26as_maxy%3D1998%26selm%3D5c8sin%2524piv%2540scream.auckland.ac.nz%26rnum%3D1, the code and a cleaned-up description is also in Building Secure Software by John Viega and Gary McGraw. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Decimal encryption
On Wed, 27 Aug 2008 17:05:44 +0200 Philipp G__hring [EMAIL PROTECTED] wrote: Hi, I am searching for symmetric encryption algorithms for decimal strings. Let's say we have various 40-digit decimal numbers: 2349823966232362361233845734628834823823 3250920019325023523623692235235728239462 0198230198519248209721383748374928601923 As far as I calculated, a decimal has the equivalent of about 3,3219 bits, so with 40 digits, we have about 132,877 bits. Now I would like to encrypt those numbers in a way that the result is a decimal number again (that's one of the basic rules of symmetric encryption algorithms as far as I remember). Since the 132,877 bits is similar to 128 bit encryption (like eg. AES), I would like to use an algorithm with a somewhat comparable strength to AES. But the problem is that I have 132,877 bits, not 128 bits. And I can't cut it off or enhance it, since the result has to be a 40 digit decimal number again. Does anyone know a an algorithm that has reasonable strength and is able to operate on non-binary data? Preferrably on any chosen number-base? Do you want a stream cipher or a block cipher? For the former, it's easy. Use something like rc4, which produces a sequence of keystream bytes. Retrieve the low-order N bits from each key stream byte, where N is large enough for the base you're using. If the value is greater than or equal to the base you're using, discard that byte and try again. For your example, you'd use the low-order 4 bits, but discard any bytes whose value is = 10. Add this value, discarding the carry, to the digit to be encrypted. You're running RC4 at 5/8 efficiency; unless you have a *lot* of data, that almost certainly doesn't matter. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
On Wed, 27 Aug 2008 07:10:51 -0400 [EMAIL PROTECTED] wrote: Bill Frantz writes, in part: -+-- | In the San Francisco Bay Area, they are using the transponder codes | to measure how fast traffic is moving from place to place. They | post the times to various destinations on the electric signs when | there are no Amber alerts or other more important things to | display. It is quite convenient, and they promise they don't use it | to track people's trips. | Look for general tracking to appear everywhere. Fast declining gasoline tax revenues will be replaced with per-mile usage fees, i.e., every major road becomes a toll road. Most likely first in will be California and/or Oregon. The relationship to this list may then be thin excepting that the collection and handling of such data remains of substantial interest. Of course, everyone who carries a cell phone has already decided that convenience trumps security, at least the kind of security that says they can't misuse what they ain't got. There's a limit to how far they can go with that, because of the fear of people abandoning the transponders. For example -- they absolutely will not use it for automated speeding tickets on, say, the NJ Turnpike, because if they did people would stop using their EZPasses. Given what a high percentage of drivers use them, especially at rush hour, they make a significant improvement in throughput and safety at toll plazas. On congested roads, throughput is *extremely* important. As for usage-based driving -- the first question is the political will to do so. In NYC, there's been tremendous resistance to things like tolls over the East River bridges or congestion charges for driving into much of Manhattan during the business day -- the Mayor tried very hard, but was unable to push it through the state legislature. That said, I've seen some papers on how use of these transponders has desensitized people towards the actual tolls they pay, and hence to toll increases. Finally, the transponders may not matter much longer; OCR on license plates is getting that good. As has already been mentioned, the 407 ETR road in Toronto already relies on this to some extent; it won't be too much longer before the human assist is all but unneeded. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Decimal encryption
Philipp Gühring wrote: Hi, I am searching for symmetric encryption algorithms for decimal strings. Let's say we have various 40-digit decimal numbers: 2349823966232362361233845734628834823823 3250920019325023523623692235235728239462 0198230198519248209721383748374928601923 As far as I calculated, a decimal has the equivalent of about 3,3219 bits, so with 40 digits, we have about 132,877 bits. Now I would like to encrypt those numbers in a way that the result is a decimal number again (that's one of the basic rules of symmetric encryption algorithms as far as I remember). Since the 132,877 bits is similar to 128 bit encryption (like eg. AES), I would like to use an algorithm with a somewhat comparable strength to AES. But the problem is that I have 132,877 bits, not 128 bits. And I can't cut it off or enhance it, since the result has to be a 40 digit decimal number again. Does anyone know a an algorithm that has reasonable strength and is able to operate on non-binary data? Preferrably on any chosen number-base? The short answer is no, nobody knows a secure algorithm that would work as a decimal stream cipher AND would not extend the message size for some form of key material reference data (or salt or IV ...). If you have room for such message-specific reference data, it should be easy to design a decimal stream cipher for short messages. -- - Thierry Moreau - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Decimal encryption
Philipp Gühring wrote: Hi, G'day Philipp, I am searching for symmetric encryption algorithms for decimal strings. Let's say we have various 40-digit decimal numbers: 2349823966232362361233845734628834823823 3250920019325023523623692235235728239462 0198230198519248209721383748374928601923 As far as I calculated, a decimal has the equivalent of about 3,3219 bits, so with 40 digits, we have about 132,877 bits. Now I would like to encrypt those numbers in a way that the result is a decimal number again (that's one of the basic rules of symmetric encryption algorithms as far as I remember). Since the 132,877 bits is similar to 128 bit encryption (like eg. AES), I would like to use an algorithm with a somewhat comparable strength to AES. But the problem is that I have 132,877 bits, not 128 bits. And I can't cut it off or enhance it, since the result has to be a 40 digit decimal number again. Does anyone know a an algorithm that has reasonable strength and is able to operate on non-binary data? Preferrably on any chosen number-base? There is a fairly standard technique for handling things like this. 1. encode your number N into a 133-bit string S 2. encrypt S with your favourite 133-bit block cipher (see below) 3. decode S to a number N' 4. if N' = 10^40, goto 2 (that is, re-encrypt until it is in range) 5. N' is your answer. This is uniquely invertible, although a little slow (since on average it will take 8.9% or so more encryptions because of the inner loop, and some side-channel information leaks when it does the extra encryptions. Decryption is exactly the same operation except step 2 uses decryption mode of the block cipher. So, you don't have a 133-bit block cipher lying around? No worries, I'll sell you one ;-). Actually that is easy too. Take a trustworthy 128-bit block cipher like AES. To encrypt, do: 1. Encrypt the first 128 bits (ECB mode) 2. Encrypt the last 128 bits (also ECB mode). To decrypt, do decryptions in the reverse order, obviously. It's easy to see that this is a secure permutation if AES itself is, depending on your definition of secure; if you add a third step, to re-encrypt the first 128 bits, it is truly secure. (Without the third step, tweaking a bit in the first 5 bits will often leave the last 5 unchanged on decryption, which is clearly a distinguishing attack; the third encryption makes it an all-or-nothing transform.) I believe the above gives you a secure enough block cipher on 40 digit strings, and if you only ever encrypt single chunks, ECB mode should be fine... of course that depends on the real threat analysis of your system. It does about 2.19 AES encryptions per 40 digits, should be fast enough. hope that helps, Greg. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Decimal encryption
Philipp Gühring writes: I am searching for symmetric encryption algorithms for decimal strings. Let's say we have various 40-digit decimal numbers: 2349823966232362361233845734628834823823 3250920019325023523623692235235728239462 0198230198519248209721383748374928601923 As far as I calculated, a decimal has the equivalent of about 3,3219 bits, so with 40 digits, we have about 132,877 bits. Right, although as an American I was confused for a moment until I remembered the European convention of using comma for the decimal point, while we use period. But you are right and it was my mistake. Now I would like to encrypt those numbers in a way that the result is a decimal number again (that's one of the basic rules of symmetric encryption algorithms as far as I remember). Since the 132,877 bits is similar to 128 bit encryption (like eg. AES), I would like to use an algorithm with a somewhat comparable strength to AES. But the problem is that I have 132,877 bits, not 128 bits. And I can't cut it off or enhance it, since the result has to be a 40 digit decimal number again. This is a very common question. Unfortunately the state of the art in cryptography does not as far as I know have a good answer. The most recent analysis I found is http://www.cs.ucdavis.edu/~rogaway/papers/subset.pdf from CT-RSA 2002 by Black and Rogaway. Basically they propose what is called a Luby-Rackoff construction, related to another construction called a Feistel network. Unfortunately their analysis does not show that this is secure, but I believe that by adding more steps it can be made so. The idea is to start with your 40 digit number and split it into two parts of 20 digits. Call the left part L and the right part R. Then repeatedly execute the following steps: L = (L xor AES(R)) mod 10^20 (L,R) = (R,L) (i.e. interchange L and R) After doing this a certain number of steps, interchange L and R one last time, and concatenate L and R to get your output. (Equivalently, skip the interchange of L and R on the last step.) Now, it is important in doing this that AES have a different key for each round or step. You can start with a single key K, and generate the round keys as K0 = AES(K,0), K1 = AES(K,1), K2 = AES(K,2), and so on. To decrypt, the same basic process is used. But this time, use the round keys in the reverse order. Instead of K0, K1, K2, use K2, K1, K0. Black and Rogaway analyzed for just 3 rounds, and they found basically that for your case, this construction would only have about 32 bits of strength; that is, after encrypting about 4 billion numbers, you would be losing security. If you are only ever encrypting many fewer numbers than this (with a given key), it should probably be OK. The other possibility is to increase the number of rounds. The paper hints that this will help but does not offer any specific analysis. I saw a speculative comment online that 8 rounds would be strong. I believe that going back to the Luby-Rackoff paper may offer some guidance, but I don't have time to do that now. Note that this unfortunately does not get the benefit you were hoping for from being so close to the AES block size. While there are some known tricks for dealing with being a little shorter than the cipher block, I couldn't find any good ones for being a few bits longer. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Decimal encryption
On Wed, 27 Aug 2008, Eric Rescorla wrote: At Wed, 27 Aug 2008 17:05:44 +0200, Philipp Gühring wrote: Hi, I am searching for symmetric encryption algorithms for decimal strings. Let's say we have various 40-digit decimal numbers: 2349823966232362361233845734628834823823 3250920019325023523623692235235728239462 0198230198519248209721383748374928601923 As far as I calculated, a decimal has the equivalent of about 3,3219 bits, so with 40 digits, we have about 132,877 bits. Now I would like to encrypt those numbers in a way that the result is a decimal number again (that's one of the basic rules of symmetric encryption algorithms as far as I remember). Since the 132,877 bits is similar to 128 bit encryption (like eg. AES), I would like to use an algorithm with a somewhat comparable strength to AES. But the problem is that I have 132,877 bits, not 128 bits. And I can't cut it off or enhance it, since the result has to be a 40 digit decimal number again. Does anyone know a an algorithm that has reasonable strength and is able to operate on non-binary data? Preferrably on any chosen number-base? There are a set of techniques that allow you to encrypt elements of arbitrary sets back onto that set. The original paper on this is: John Black and Phillip Rogaway. Ciphers with arbitrary ?nite domains. In CT-RSA, pages 114?130, 2002. But he probably wants an encryption scheme, not a cipher. Also, correct me if I am wrong, but Black and Rogaway's approach is not efficient for large domains. But if you use their approach for small domains then you open yourself up to dictionary attacks. For a modern proposal to make this a NIST mode, see: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ffsem/ffsem-spec.pdf -Ekr Full Disclosure: Terence Spies, the author of the FFSEM proposal, works for Voltage, Voltage has a product based on this technology. and I'm on Voltage's TAB and have done some work for them. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Decimal encryption
Philipp Gühring wote: I am searching for symmetric encryption algorithms for decimal strings. Let's say we have various 40-digit decimal numbers: 2349823966232362361233845734628834823823 3250920019325023523623692235235728239462 0198230198519248209721383748374928601923 As far as I calculated, a decimal has the equivalent of about 3,3219 bits, so with 40 digits, we have about 132,877 bits. English readers normally use . as the decimal point - you had me confused for a few seconds and maybe it wasn't only me. Regardless of the calculated bit-equivalent you aren't storing these strings in 132.877 bits - but possibly 40*8 bits, 40*4 bits or in some other way. Now I would like to encrypt those numbers in a way that the result is a decimal number again (that's one of the basic rules of symmetric encryption algorithms as far as I remember). I don't think that's a feature of the encryption as such. Since the 132,877 bits is similar to 128 bit encryption (like eg. AES), I would like to use an algorithm with a somewhat comparable strength to AES. But the problem is that I have 132,877 bits, not 128 bits. And I can't cut it off or enhance it, since the result has to be a 40 digit decimal number again. This sounds like possible confusion over block length and key size. Then you get involved in padding and storage of a slightly larger ciphertext. Does anyone know a an algorithm that has reasonable strength and is able to operate on non-binary data? Preferrably on any chosen number-base? It sounds as if you want a stream cipher arrangement that you could make out of a normal binary stream cipher by: read a byte of the keystream if 9 reject it and take the next one (aiming for uniform distribution) if the value is [0-9] add it to the current plaintext digit mod 10 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Good writeup on UI spoofing attacks
The Codinghorror blog has a good writeup on the level of sophistication of UI spoofing being used in phishing attacks, specifically how a web search for lilies leads to a pretty convincing social-engineering attack designed to get users to install their malware: http://www.codinghorror.com/blog/archives/001164.html What I'm more concerned about here is how well the user interface was spoofed. The browser FUI [fake UI] was convincing enough to even make me -- possibly the world's most jaded and cynical Windows user -- do a bit of a double- take. How do you protect naive users from cleverly designed FUI exploits like this one? Can you imagine your mother doing a web search on flowers -- flowers, for God's sake -- clicking on the search results to a totally legitimate website, and correctly navigating the resulting maze of fake UI, spurious javascript alerts, and download dialogs? To pre-empt the inevitable discussions of Noscript and similar measures, they're all well and good but the very people who need them the most are the ones who're least likely to have them installed. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Decimal encryption
On Wed, 27 Aug 2008 09:34:15 -0700 Greg Rose [EMAIL PROTECTED] wrote: So, you don't have a 133-bit block cipher lying around? No worries, I'll sell you one ;-). Also see Debra Cook's PhD dissertation on Elastic Block Ciphers at http://www1.cs.columbia.edu/~dcook/thesis_ab.shtml --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SRP implementation - choices for N and g
Michael Tschannen wrote: Hi list Has anybody already gained experience concerning the technical implementation of SRP (http://srp.stanford.edu)? There is one point I couldn't find in any documentation: Should the modulus and the generator (N and g) be unique for each client or can they be chosen application-wide? What are the (security-related) implications in each case? There is no readily apparent reason why N and g should not be application wide. Of course, some clever persons might discover some unobvious flaw. Rather than using SRP, you might use J-PAKE. J-PAKE has a proof that there is nothing wrong with J-PAKE unless there is something wrong with all similar protocols, so you can go right ahead and do what all the other protocols do - which is one value of N and g for all. Thanks, Michael - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Decimal encryption
At Wed, 27 Aug 2008 16:10:51 -0400 (EDT), Jonathan Katz wrote: On Wed, 27 Aug 2008, Eric Rescorla wrote: At Wed, 27 Aug 2008 17:05:44 +0200, There are a set of techniques that allow you to encrypt elements of arbitrary sets back onto that set. The original paper on this is: John Black and Phillip Rogaway. Ciphers with arbitrary ?nite domains. In CT-RSA, pages 114?130, 2002. But he probably wants an encryption scheme, not a cipher. Hmm... I'm not sure I recognize the difference between encryption scheme and cipher. Can you elaborate? Also, correct me if I am wrong, but Black and Rogaway's approach is not efficient for large domains. But if you use their approach for small domains then you open yourself up to dictionary attacks. I suppose it depends what you mean by small and large. A lot of the relevant values are things like SSNs, CCNs, etc. which fall in the 10-20 digit category, where the Luby-Rackoff approach is efficient. As I understand the situation, the cycle following approach is efficient as long as the set is reasonably close to the L-R block size. As far as dictionary attacks go, for any small domain permutation you have to worry about table construction attacks. The only defense I know of is randomized encryption which defeats the non-expansion requirement. WRT to the security of the L-R construction, Spies claims that I believe that Patarin's 2004 result [0] is relevant here, but I'm not qualified to evaluate it. Anyway, the reference I provided earlier [1] provides a summary of the claimed security properties of L-R + Cycle Following. -Ekr [0] Jacques Patarin. Security of random feistel schemes with 5 or more rounds. In Matthew K. Franklin, editor, CRYPTO, volume 3152 of Lecture Notes in Computer Science, pages 106?122. Springer, 2004. [1] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ ffsem/ffsem-spec.pdf - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: road toll transponder hacked
Personally, I don't want to have a history of my travel stored in any database. Right now, purchasing a one-time CharlieTicket is a 30 cent surcharge per ride, but it is the only way to take the subway in Boston without creating a travel history. Privacy in public transportation should be equally accessible to all citizens, regardless of financial resources. I suspect that you, as do I, pay for as many things in cash as humanly possible though, of course, we are well past the point at which paying for an airline ticket, say, in cash does anything more than make you even more inspected than you would be if you used credit. That said, the 30c surcharge for having no record kept for riding the subway is at once a price for privacy that is at least expressed in the coin of the realm and, at the same time, not a guarantee, just a side effect. If the MBTA general manager were to say For 30c more, we promise to forget you were a passenger he would be out of a job in the morning at the Governor's demand and there'd be wide agitation against the idea that better off people get privacy when poor folks don't. Do you suppose that we can, just possibly, make privacy into a class warfare issue? We sort of do that already in that the people who make privacy law, legislature and executive alike, are afforded precisely zero privacy by both the courts and the press. As such, one has to be a truly addled optimist to imagine that those who have no privacy are nevertheless willing to grant you more privacy than they have, unless they are somehow nostalgic for what they themselves lost in becoming a member of government. Me, I think that the loss of privacy required to become part of government is a sieve for not caring about such issues because, if you did care, you wouldn't go into government in the first place. --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Decimal encryption
I like Greg Rose's solution best: There is a fairly standard technique for handling things like this. 1. encode your number N into a 133-bit string S 2. encrypt S with your favourite 133-bit block cipher (see below) 3. decode S to a number N' 4. if N' = 10^40, goto 2 (that is, re-encrypt until it is in range) 5. N' is your answer. This is Rich Schroeppel's trick from his Hasty Pudding cipher, a somewhat under-rated AES submission IMO. HPC originated not only this trick, but also the idea of tweakable encryption, which has turned out to be important for disk encryption. The Black-Rogaway paper referenced earlier has a proof of security of this construction. So, you don't have a 133-bit block cipher lying around? No worries, I'll sell you one ;-). Actually that is easy too. Take a trustworthy 128-bit block cipher like AES. To encrypt, do: 1. Encrypt the first 128 bits (ECB mode) 2. Encrypt the last 128 bits (also ECB mode). I didn't understand this at first, but I finally saw that the point is to do the encryptions in-place; step 1 replaces the first 128 bits of the data with the encryption, and similarly for step 2. This is equivalent to doing CBC mode with a fixed IV of 0, and ciphertext stealing for the final partial block of 5 bits. To decrypt, do decryptions in the reverse order, obviously. It's easy to see that this is a secure permutation if AES itself is, depending on your definition of secure; if you add a third step, to re-encrypt the first 128 bits, it is truly secure. (Without the third step, tweaking a bit in the first 5 bits will often leave the last 5 unchanged on decryption, which is clearly a distinguishing attack; the third encryption makes it an all-or-nothing transform.) I am not familiar with the security proof here, do you have a reference? Or is it an exercise for the student? Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Decimal encryption
Hal Finney wrote: So, you don't have a 133-bit block cipher lying around? No worries, I'll sell you one ;-). Actually that is easy too. Take a trustworthy 128-bit block cipher like AES. To encrypt, do: 1. Encrypt the first 128 bits (ECB mode) 2. Encrypt the last 128 bits (also ECB mode). I didn't understand this at first, but I finally saw that the point is to do the encryptions in-place; step 1 replaces the first 128 bits of the data with the encryption, and similarly for step 2. This is equivalent to doing CBC mode with a fixed IV of 0, and ciphertext stealing for the final partial block of 5 bits. Yes, I guess it is... hadn't thought of it that way. But yes, I confirm that I meant to do the encryptions in place. To decrypt, do decryptions in the reverse order, obviously. It's easy to see that this is a secure permutation if AES itself is, depending on your definition of secure; if you add a third step, to re-encrypt the first 128 bits, it is truly secure. (Without the third step, tweaking a bit in the first 5 bits will often leave the last 5 unchanged on decryption, which is clearly a distinguishing attack; the third encryption makes it an all-or-nothing transform.) I am not familiar with the security proof here, do you have a reference? Or is it an exercise for the student? It's a degenerate case of Rivest's All-or-nothing transform (which applies to larger, multi-block blocks, if you know what I mean :-) ). I believe he gave a security proof, some 6ish years ago. But I could be confabulating. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
