Okay, I got a deck of cards and had quick try. Immediately I noticed few issues:
1) You practically need two decks of cards. One which stores your key, and another which you use for the encryption process. This is needed because the matrix is mutated when doing encryption, meaning that you lose the original key. So before you start encrypting, you sync the two decks so that one can be messed up and another still retains the key.
2) Nonce generation is an problem. Simplest way I got for now is shuffle unused 16 cards (e.g. 10,J,Q,K) and draw them pairwise and use the pair to get character (base4->base36 conversion). It is not ideal, but doable.
3) Signature is supposed to be a secret, but no method for managing it is provided. Again, leftover cards could be used here, but if the above simple card-pair -> character mapping is used then you get only 8 characters when the paper recommends 10. It is not clear how critical the randomness here is. Practically it can be considered part of your key almost.
4) Surprisingly large amount of desk space required. Not something that really would pose a problem, but you definitely need some space to layout the 6x6 matrix. I imagine with standard sized cards, 7x7 (as mentioned in one of the comments) would be already challenging. If you additionally need to manage the second deck (see 1.) then that might need some more space.
5) For effective use you need will need lookup tables for both card->character->card mapping and card->movement mappings. They can easily be generated on demand (basically base conversion table between 6/9/36) and as such do not need to be permanent, but its still a consideration.
6) Lookup tables feel like they will slow down the process. You will be doing at least 3 (or 5 depending on how you count) lookups for each character encrypted. And of course you will need to be careful with the lookups, try to avoid mixing up down vs right movements and adjacent rows/columns.
7) 36 characters is actually pretty limited. Sure, you can write messages with just [A-Z0-9], using e.g. 0 (or #/_ like in the article) as word-separator etc. 7x7 would be significant improvement here. If you don't mind extending the length of the message then I suppose you could use some sort of preprocessing to widen the character set (e.g. use 4 symbols to encode 3 chars). Although that might make the already laborous process too much so.
8) Still need to time the process. I feel like initially it will be super slow, but especially if you can manage to keep the lookups in your head then it might actually not be that bad.
1) You practically need two decks of cards. One which stores your key, and another which you use for the encryption process. This is needed because the matrix is mutated when doing encryption, meaning that you lose the original key. So before you start encrypting, you sync the two decks so that one can be messed up and another still retains the key.
2) Nonce generation is an problem. Simplest way I got for now is shuffle unused 16 cards (e.g. 10,J,Q,K) and draw them pairwise and use the pair to get character (base4->base36 conversion). It is not ideal, but doable.
3) Signature is supposed to be a secret, but no method for managing it is provided. Again, leftover cards could be used here, but if the above simple card-pair -> character mapping is used then you get only 8 characters when the paper recommends 10. It is not clear how critical the randomness here is. Practically it can be considered part of your key almost.
4) Surprisingly large amount of desk space required. Not something that really would pose a problem, but you definitely need some space to layout the 6x6 matrix. I imagine with standard sized cards, 7x7 (as mentioned in one of the comments) would be already challenging. If you additionally need to manage the second deck (see 1.) then that might need some more space.
5) For effective use you need will need lookup tables for both card->character->card mapping and card->movement mappings. They can easily be generated on demand (basically base conversion table between 6/9/36) and as such do not need to be permanent, but its still a consideration.
6) Lookup tables feel like they will slow down the process. You will be doing at least 3 (or 5 depending on how you count) lookups for each character encrypted. And of course you will need to be careful with the lookups, try to avoid mixing up down vs right movements and adjacent rows/columns.
7) 36 characters is actually pretty limited. Sure, you can write messages with just [A-Z0-9], using e.g. 0 (or #/_ like in the article) as word-separator etc. 7x7 would be significant improvement here. If you don't mind extending the length of the message then I suppose you could use some sort of preprocessing to widen the character set (e.g. use 4 symbols to encode 3 chars). Although that might make the already laborous process too much so.
8) Still need to time the process. I feel like initially it will be super slow, but especially if you can manage to keep the lookups in your head then it might actually not be that bad.