Draft
Encrypt the message!
Loading description...
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
This comment has been hidden.
Please don't post solutions in Discourse. It means you can make changes (if you want) to your code before submitting it. After that, that's the solution it'll show no matter how many times you submit another version. Note this kata is a Draft, so you can't submit your solution.
Thanks for your help. I posted my solution because no one didn't comment on my first comment.
I have solved it and passes all test but i don't know why I can't sbmit my solution.
This comment has been hidden.
Your code is wrong. Don't round it but.. Example: (5.6 => 5), (5.3 => 5), (4.8 => 4)
This comment has been hidden.
A lossy encryption algorithm ?!?
With key
"hi"
, given the ciphertext, you can't know if the first character of the plaintext is'H'
or'I'
.As an author, you have a lot of leeway in designing your kata, but this is ridiculous.
Given a key and a ciphertext, how will you know where the plaintext ends and the trailing garbage begins? Trailing garbage might look like perfectly valid plaintext ( for medium high indices, you'll get digits ).
It is even possible to run out of ASCII for longer key values ( note that standard ASCII only goes up to
127
).Please don't make any contributions to OpenSSL just yet. :S
I'm very thankful for this comment, what I wanted to is to create a very simple encryption but I was wrong for adding the index in a computation. Thank you, I'll fix this.
Treat it as a hash function :-)
FIFY :P
@author: maybe you could lower the expectations somewhat by using the word "hashing" or "encoding" instead of "encryption". Encryption just is never simple. You might have kept the use of an index by using a modulo; you might have used an
xor
instead of a division ( or instead of an average ) to keep things more cryptographically sound, but if you want to keep things simple, invoking cryptography is not the way to do it.You are free to design your kata any way you like, but set the scene appropriately. :]
Okay sir, thanks for the advice.
This part makes no sense. It's easier to guess the algorithm from tests than to decipher the description.
Yeah I know, I'm pretty bad at english but I want to author a problem so I'll thank you for that. I'll fix the grammar soon.
The handling of messages shorter than keys is explained terribly. Why does key length affect encryption in such a dumb way in the first place?
It is my bad, what I'm trying to say is the remaining characters that are not used. Thank you again for that.
There's no such thing as "decimal of a characater".
How?
What i'm trying to say is the ascii decimal of a character in ascii list. For "If the answer is not a whole number, only get the whole number", example: 5.6 => 6, I forgot the term that's why I can't explain it properly. But thanks for that, I'll fix it.
"decimal of a character" -> "ascii code"
Sorry for not being direct.