Anonymous user
Talk:RSA code: Difference between revisions
m
→Difference from practical cryptographical version: demoted heading again for consistency
(→Difference from practical cryptographical version: note on blocking, elevated heading a level) |
m (→Difference from practical cryptographical version: demoted heading again for consistency) |
||
| (One intermediate revision by the same user 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 246 ⟶ 258:
::::: Ok, but as specified, the task is to substitute the sequence of letters <code>'abcdefghijklmnopqrstuvwxyz,.!? '</code> and replace each of them with the corresponding number from this list: <code>1 581 1087 140 205 2371 1125 156 1864 2403 821 2497 2038 1616 2116 1841 959 2222 2299 793 41 45 2475 2130 1433 1836 1642 206 577 1488 384</code>. Decryption is looking up those numbers and substituting for the corresponding letters. The padding is irrelevant noise. And, as specified, you do not have to implement RSA at all to accomplish this task. --[[User:Rdm|Rdm]] 00:58, 2 April 2011 (UTC)
▲= 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)
| |||