Scioly.org

pepperonipi wrote: On another note, have any teams tried to memorize quotes in order to get the first question extremely quickly? Seems like the winner of UPenn may have known the quote before the competition, since they solved the entire thing in less than 2 minutes...

Some people have claimed that they can solve cryptograms in their head without writing anything down. I think this is probably more likely then memorizing quotes, as I don't think the UPenn quote was a very common quote. (And the first word is almost a giveaway). Here's a link to the cryptograms.org forums where people claimed they can do this. https://forum.puzzlebaron.com/forum/puz ... -your-head

Knowing quotes is still useful though. At MIT my partner recognized the quote after we solved about half of it, but we have never deliberately tried to memorize quotes for the purpose of solving the timed cipher (and our time wouldn't have changed too much if we didn't recognize it). A sub 2 min solve time for most timed ciphers is very much possible solving just normally (although from what I understand UPenn didn't allow you to write on the test, which is why I think they solved it mentally).

Just taking tests is useful enough to get familiar with more quotes, and I don't think explicitly finding quotes just to memorize is worth the effort.

Sorry for double post, but I just wanted to make a comment on RSAs/4 and 5 function calculators. I'm glad they restricted RSA questions to toebes only in a FAQ that was made, but they need to make some changes next year. Our 4/5 function calculators suck to use, but also they only display 8 digits, which is sufficent for most ciphers, but not for RSA. The find year type of questions can't be done with only 8 digit calcs unless you feel like calculating the last few digits by hand if the primes are 3+ digits long. The find key, while it can be done with these calcs, cannot be checked by these calcs. In my opinion, they should just allow scientific calculators.

Name wrote:Sorry for double post, but I just wanted to make a comment on RSAs/4 and 5 function calculators. I'm glad they restricted RSA questions to toebes only in a FAQ that was made, but they need to make some changes next year. Our 4/5 function calculators suck to use, but also they only display 8 digits, which is sufficent for most ciphers, but not for RSA. The find year type of questions can't be done with only 8 digit calcs unless you feel like calculating the last few digits by hand if the primes are 3+ digits long. The find key, while it can be done with these calcs, cannot be checked by these calcs. In my opinion, they should just allow scientific calculators.

I agree with all of this. In addition, I think the answer format should be clarified- on the Cornell test, it turned out that the test writers wanted the answer to an encryption question to be presented as a series of letters, but this didn't make sense to us at the time (or now) because converting the encrypted numbers back to letters would have required modding them again by 26 since n was greater than 26, and therefore it would become way more difficult to get the original text back due to uncertainty over whether the letters had been modded or not. We ended up presenting the answer as a series of numbers, which we received no credit for because it didn't match the key, but it would be nice to have official information on what format the ES's actually want the encryption in since we knew how to do the math and only missed the question because of our answer format, which wasn't specified by the question.

Name wrote:Sorry for double post, but I just wanted to make a comment on RSAs/4 and 5 function calculators. I'm glad they restricted RSA questions to toebes only in a FAQ that was made, but they need to make some changes next year. Our 4/5 function calculators suck to use, but also they only display 8 digits, which is sufficent for most ciphers, but not for RSA. The find year type of questions can't be done with only 8 digit calcs unless you feel like calculating the last few digits by hand if the primes are 3+ digits long. The find key, while it can be done with these calcs, cannot be checked by these calcs. In my opinion, they should just allow scientific calculators.

I agree that RSA is extremely difficult to do on a 4/5 function calculator, but I don’t think scientific calculators should be allowed. It would be way too easy to program them to simply do ciphers for you (such as affine or hill) and there’d be no realistic way for proctors to prevent that from happening.

Riptide wrote:

Name wrote:Sorry for double post, but I just wanted to make a comment on RSAs/4 and 5 function calculators. I'm glad they restricted RSA questions to toebes only in a FAQ that was made, but they need to make some changes next year. Our 4/5 function calculators suck to use, but also they only display 8 digits, which is sufficent for most ciphers, but not for RSA. The find year type of questions can't be done with only 8 digit calcs unless you feel like calculating the last few digits by hand if the primes are 3+ digits long. The find key, while it can be done with these calcs, cannot be checked by these calcs. In my opinion, they should just allow scientific calculators.

I agree that RSA is extremely difficult to do on a 4/5 function calculator, but I don’t think scientific calculators should be allowed. It would be way too easy to program them to simply do ciphers for you (such as affine or hill) and there’d be no realistic way for proctors to prevent that from happening.

Couldn't a ban on programmable calculators prevent that? A lot of events require scientific, non-programmable calculators.

UTF-8 U+6211 U+662F wrote:

Riptide wrote:

Name wrote:Sorry for double post, but I just wanted to make a comment on RSAs/4 and 5 function calculators. I'm glad they restricted RSA questions to toebes only in a FAQ that was made, but they need to make some changes next year. Our 4/5 function calculators suck to use, but also they only display 8 digits, which is sufficent for most ciphers, but not for RSA. The find year type of questions can't be done with only 8 digit calcs unless you feel like calculating the last few digits by hand if the primes are 3+ digits long. The find key, while it can be done with these calcs, cannot be checked by these calcs. In my opinion, they should just allow scientific calculators.

I agree that RSA is extremely difficult to do on a 4/5 function calculator, but I don’t think scientific calculators should be allowed. It would be way too easy to program them to simply do ciphers for you (such as affine or hill) and there’d be no realistic way for proctors to prevent that from happening.

Couldn't a ban on programmable calculators prevent that? A lot of events require scientific, non-programmable calculators.

I will retract my previous statement as I forgot non programmable calculators exist.

UTF-8 U+6211 U+662F wrote:

Riptide wrote:

Name wrote:Sorry for double post, but I just wanted to make a comment on RSAs/4 and 5 function calculators. I'm glad they restricted RSA questions to toebes only in a FAQ that was made, but they need to make some changes next year. Our 4/5 function calculators suck to use, but also they only display 8 digits, which is sufficent for most ciphers, but not for RSA. The find year type of questions can't be done with only 8 digit calcs unless you feel like calculating the last few digits by hand if the primes are 3+ digits long. The find key, while it can be done with these calcs, cannot be checked by these calcs. In my opinion, they should just allow scientific calculators.

I agree that RSA is extremely difficult to do on a 4/5 function calculator, but I don’t think scientific calculators should be allowed. It would be way too easy to program them to simply do ciphers for you (such as affine or hill) and there’d be no realistic way for proctors to prevent that from happening.

Couldn't a ban on programmable calculators prevent that? A lot of events require scientific, non-programmable calculators.

The thing is, four function calculators are standardized. A scientific calculator with a floor, mod, store, etc. functions would give those teams a decent advantage on time. It is much more equal to keep everyone on a four function. It would be a lot more annoying for supervisors to check for calculators without those functions.

l0lit wrote:

UTF-8 U+6211 U+662F wrote:

Riptide wrote: I agree that RSA is extremely difficult to do on a 4/5 function calculator, but I don’t think scientific calculators should be allowed. It would be way too easy to program them to simply do ciphers for you (such as affine or hill) and there’d be no realistic way for proctors to prevent that from happening.

Couldn't a ban on programmable calculators prevent that? A lot of events require scientific, non-programmable calculators.

The thing is, four function calculators are standardized. A scientific calculator with a floor, mod, store, etc. functions would give those teams a decent advantage on time. It is much more equal to keep everyone on a four function. It would be a lot more annoying for supervisors to check for calculators without those functions.

Doesn't the same thing apply to all of the other calculator events though? Also, floor and mod don't save much time, and store doesn't save *that much*.

UTF-8 U+6211 U+662F wrote:

l0lit wrote:

UTF-8 U+6211 U+662F wrote: Couldn't a ban on programmable calculators prevent that? A lot of events require scientific, non-programmable calculators.

The thing is, four function calculators are standardized. A scientific calculator with a floor, mod, store, etc. functions would give those teams a decent advantage on time. It is much more equal to keep everyone on a four function. It would be a lot more annoying for supervisors to check for calculators without those functions.

Doesn't the same thing apply to all of the other calculator events though? Also, floor and mod don't save much time, and store doesn't save *that much*.

The number of digits aren't standardized. We have 8 digit calculators that are not capable of calculating some RSA questions that can be made from toebes. I tried to get a calculator with more digits, but was unable to find one. On the test, doing a find the key RSA, I copied the answer from the calculator wrong, and I tried checking but our calculator couldn't handle the number of digits, and it wasn't worth checking by hand, which cost us 700 pts. If we had a calculator that could check the answer I could've quickly reevaluated the fractions and realized I had copied the answer from my calculator to the answer sheet wrong.
Also a question on toebes exchange key question: if person A needs to decode a message sent by person B wouldn't it be the message^(the key of person B) not the message^(the key of person A) because person B encoded it with their encryption key? Anyways that costed us another 500 points.

Name wrote:

UTF-8 U+6211 U+662F wrote:

l0lit wrote: The thing is, four function calculators are standardized. A scientific calculator with a floor, mod, store, etc. functions would give those teams a decent advantage on time. It is much more equal to keep everyone on a four function. It would be a lot more annoying for supervisors to check for calculators without those functions.

Doesn't the same thing apply to all of the other calculator events though? Also, floor and mod don't save much time, and store doesn't save *that much*.

The number of digits aren't standardized. We have 8 digit calculators that are not capable of calculating some RSA questions that can be made from toebes. I tried to get a calculator with more digits, but was unable to find one. On the test, doing a find the key RSA, I copied the answer from the calculator wrong, and I tried checking but our calculator couldn't handle the number of digits, and it wasn't worth checking by hand, which cost us 700 pts. If we had a calculator that could check the answer I could've quickly reevaluated the fractions and realized I had copied the answer from my calculator to the answer sheet wrong.
Also a question on toebes exchange key question: if person A needs to decode a message sent by person B wouldn't it be the message^(the key of person B) not the message^(the key of person A) because person B encoded it with their encryption key? Anyways that costed us another 500 points.

As for the second part, I'm not sure what you're asking. Each person has two keys, a public and a private. You encrypt with the other person's public key and decrypt with your own private key.