Anonymous user
Talk:RSA code: Difference between revisions
m
→Difference from practical cryptographical version: demoted heading again for consistency
m (→Difference from practical cryptographical version: demoted heading again for consistency) |
|||
| (10 intermediate revisions by 2 users not shown) | |||
Line 1:
== Difference from practical cryptographical version ==
The are a number of differences between the bare algorithm presented on this page and what you'll see in real use.
* There's nothing to prevent tampering (such as including the length and a cryptographic hash in the encoded message).
* The keys are significantly smaller than in real deployments (where keys are often several kilobits long; this great length by comparison with symmetric cyphers – e.g., Blowfish – is required because of the relative sparseness of prime numbers, which are vital for building the keys).
** Absolutely true, the updated task only required using keys that exercised large integers and could potentially handle real keys. Even the long demo key is considerably shorter than RSA 129 (43 vs 129) --[[User:Dgamey|Dgamey]] 13:30, 23 May 2011 (UTC)
* Solutions here are not required to handle putting the message into blocks if it is too long (i.e., if the values are larger than the modulus part of the key).
** The updated description requires that this be done or the limitation called out. --[[User:Dgamey|Dgamey]] 13:30, 23 May 2011 (UTC)
* Solutions here are not required to compress the data before encrypting it (vital in general because it helps to reduce the amount of redundant information in the encrypted message and so frustrate cryptanalysis).
** Excellent point! --[[User:Dgamey|Dgamey]] 13:30, 23 May 2011 (UTC)
'''''Do not use these solutions in deployed code''''', or at least not without consulting both a cryptographer and an experienced software engineer! (Also, be aware that the generation of RSA keys is an entirely more complex problem than applying the encryption and decryption algorithm.) –[[User:Dkf|Donal Fellows]] 09:28, 23 May 2011 (UTC)
==Draft==
There's a ''lot'' to do to clean this up to the level of being a full task. For one thing, it's not at all clear what this code is trying to do! It also lacks links to resources (e.g., wikipedia) that describe the algorithm involved, and the Python solution needs much work too (especially in its surrounding descriptive text, which looks to me more like text that belongs here on the talk page). –[[User:Dkf|Donal Fellows]] 06:31, 24 March 2011 (UTC)
Line 9 ⟶ 21:
:: OK, things are starting to look better. We still lack a description of what the task ''is'' though! I guess it's to do the encryption and decryption (with fixed trivial keys?) and not to do key generation; the latter is much more computationally expensive and doesn't serve as an introduction to this area of cryptography. –[[User:Dkf|Donal Fellows]] 07:26, 2 April 2011 (UTC)
===Updated Task Description===
Nobody had taken it upon themselves to update and clarify the task after last months discussions. That and no one was adding code. So I jumped in.
As it currently stands the task is very flexible. You must implement RSA and be able to encrypt and decrypt messages, support character to number encoding and decoding. Support (or warn about) blocking. Demonstrate you can support real key lengths by using large integers. And demonstrated it works by showing intermediate results. You are free to pick your keys and encoding scheme although examples have been provided. For the examples added prior to GO the only hardship here might be the need to use large integers. Unfortunately one example just calls an RSA library. As that example was added later and there are lots of tasks about calling libraries, I believe that example should be marked incorrect.
I'd like to request that the Python author remove the massive UI code. Park it here in a section if you like and reference it.
Some of the other suggestions (including mine for RSA129) would have invalidated most of the original contributions. I hope this change strikes a reasonable compromise between respecting the work of the original contributors and strengthening the task.
I believe that this is now ready to graduate out of draft. I propose to let it sit a few weeks to give people a chance to respond before removing draft.
Thanks --[[User:Dgamey|Dgamey]] 03:21, 18 May 2011 (UTC)
===Solutions are starting to diverge===
Line 17 ⟶ 42:
--[[User:Dgamey|Dgamey]] 02:49, 27 April 2011 (UTC)
===Library or Implementation? The direction of PicoLisp===
Again we need to settle on a definition before too many people add solutions. Just calling a library may be a valid task but it doesn't fit the original task description or the alternate started in GO. A similar debate was held in [[MD5]] and [[MD5/Implementation]]. --[[User:Dgamey|Dgamey]] 10:15, 29 April 2011 (UTC)
:* I think a warning on the main page is due. --[[User:Dgamey|Dgamey]] 10:15, 29 April 2011 (UTC)
===The direction of GO===
: Deliberately so. :) With the task in draft status I thought I would mix things up with some different ideas, and thought I would start with some code as an illustration. So in no particular order here, I was thinking a number of things.
:* The task has potential to get uncomfortably large and multi-faceted. I wanted to see if I could write something compact. (Well, as Go code goes. I know Go tends to run long in LOC.)
Line 57 ⟶ 87:
::* I'll post some code that follows your example. But it won't be until at least this evening.
::: Oh, I ''like'' this version very much; the Go code is clear and it was enough for me to figure out exactly what I needed to do (along with the formulæ already in the task description). All I needed was a modexp implementation, which wasn't hard to find. I modified things slightly in the Tcl solution to force UTF-8 (on the grounds that it's trivial for me to do it and it gets rid of one of the restrictions mentioned above). What I considered, but didn't do in the end, was adding blocking to allow arbitrary length messages. I'm not sure that there's a huge need to show intermediate results though; the interpretation of the messages as numbers is not really very interesting after all and it makes a functional encryption interface much messier. –[[User:Dkf|Donal Fellows]] 09:09, 23 May 2011 (UTC)
==== New/Modified Tasks and Categories ====
Line 64 ⟶ 96:
:::I think the first thing to do is create a category (or maybe categories?) for these tasks. Then mark this task with that category. Then do up some draft task pages and see if they attract interest. I think that this one can be cleaned up, later, perhaps after we have had some practice with formulating tasks related to encryption, or perhaps by the original author. --[[User:Rdm|Rdm]] 14:00, 27 April 2011 (UTC)
:::: Ok. There is
::::: Thoughts.... simplicity is a virtue? Here, let's limit ourselves to just one category for now, based on the variant tasks we would want to tackle first. We can always add categories later. We could even go ahead and draft up some new tasks first and hold off on picking categories for now.
::::: In other words, I am going to downplay my earlier suggestion and suggest instead that we just come up with some simple tasks that seem to be good ones. Similarly, I would not worry too much about stealing a task: we have wiki edit history, so we should be able to bring back good stuff that gets stepped on. --[[User:Rdm|Rdm]] 17:21, 28 April 2011 (UTC)
:::::: I think the rest of this discussion should be on a category page. Probably not Encryption (too narrow). I'll get something going. --[[User:Dgamey|Dgamey]] 23:00, 28 April 2011 (UTC)
===Split the task?===
| |||