I developed a new method of encrypting information. It does not comply with standard methods of encryption and was custom made to encrypt info stored in session cookies.
It basically works like this:
-It takes a standard 72 char string as it's IDENTITY or password. There could be more than a million variations of this.
It then uses a pre-defined set of randomly generated variations of text and uses that to hide the actual content. However, it has special chars hidden in each enrypted line to help identify how to decrypt it.
My reason for posting here is to see if anyone here could (a) crack it or (b) give me some advice on how to make it better.
I am not too reluctant to give too much info yet as this is still in aplha stage and not the finished project.
Here is an example. It is the 50 US states in random order. Please note that even if I keep the same order, each time it will look different. To prove that, I will run it twice with the same order used:
First Run:
H39pwxMnczu+#u!?:IeQAAeSPrjJFRZ84#zma-XbMaU7#F|Bm!6o3qgnJ3 cFIoTYNS|dAfVa
ibes!zd!O-e4sxx8yOo!?hTvK-f6htqlRxT?pV3CT--l4vU#7TInYV-WXNFil-t3+tG+:9b5X
?9#2Ncfn8AUim!3LZw#s5YRqF5Xfwm1:sCO?B90ViBQkmW?MlHn1h4Pd5AU8Lw QYwzr8IxhB
0r!mccmccmffmRzbapQ_dSjm+9#5jRR_IlqvWjY:Z9RfiABL_Rp#Dp!DyP?HiAB#9+HXRp?1x
SHjCpl+lvLvKVECH#bY+jn?T_-:1T7M#x?4uQ!bsJglVmc5dHN79HUF58|sTVDIp#jN__8tIk
?5ErfVd2N9TgcR3pWE#Dw98FYnUT9BHlBolV:mPFYnHw5P69BmJhWo|fYYL25P?rguINWY+f4
P?6QBXUxyYg3iWNpVL2FoBd-s UaqyAaOc M#2xd6ewglq??MZe4nD-#UnW3H6Fa?TIAdegkd
ERM?yyKtW_IydIOm77ia:9ao8 o#RcB8u_G3Jwox-K?0IC#S22GG0wQH-hfbptWSCCKo0Noaj
SRnCpwIzQv2CwvtH_Qt2RUT9ms#TDY9#Jb9J88m_V5xmQL_Gnj_9kO5JiRYVN0pY?YW_RnI9g
rDVUGkUuEg76dDXVawq|SImE8MyKKDDmar+|vHh93?y88SwmFwtYvzCNEA52n:eCfu1PGgH k
RO6ZAV7VO3S:3WWz+1LGzlb+o#!+:xyL3BKA1jIHArAd+K#4:5k2 Oi2Og2F|:DI+fxXL|f7G
DmqBiMZv2277kCjE# 6JPAorUURxk+xNB p?ew!cnuTz?GMqO8v63tJ7Mu TGoENfSN6Q4C7Y
!VMBYFY5YLadz0!TnjMrVA8Sr2rFdML-zR45:9m59i5e zg8dx0+T x?1LP79cFTnj:mc93w
S#?vL+v+i+mNXmV:W4ckvwjGMJRcQKAntLxgIH9KMWJQFTVb!Vxhlp9ELJ_7FVBU2YD:gJbAL
omUd_SFpmR_dXC RwigvHF67DObZdOZ-O_f6#egP4lMfP?BHzJZEiMj!bdEZQSfTsRBbWrzm:
09!mIINcG-n??B1-jQfdA#_lp|tG++M9jpedAJ_mpzd+P 7Ws5MD4Y#+p4dP97n0?HYR4!0Z+
cEtiKjA:6hfp+#D2ClS-2eH9e1dDsNZ7mN5vwR- a:EZ6j|3Py#I3ivk0hfp1|KIglp-Jz-d
|c9O:#Ue5Mk575P004EY 9QKC!5 cQ0ysIGgp46Z-r0 ZQyEIPLVo-HZXLN0RRiYbAYV0S_ZV
xXY#8SAwW ZB?Sr4OcL!ncpl+#m_W?iL5HAJ3 Z0Jol9|DyC-A80UgCm7zmr_8QMOpDmHE4XF
:r7:LlgSvzJuKm6oXy8r#XRMaJvNsnydX?N-rtt4Y73YsrwIXsf6nKoYf7Zc be:dj0ppKKh#
G-f8w8PPb-Z-oHp:BPAVDj-MHvSZyp0_E8k mwZvLLp?30AaFCUO!DUZ+h:#OS637Am6UXKUu
TcWQAUyQ:VJKv94zus2X9tn88p3vD34tgr2iupAwD+INKoMQuc?mXeZoouyKDohTm6 JoveXP
dP27Gb4iLdZ51w7YDr8#XTdisjQGrYII#BnX6P532?KH2r0LtS?D:nN6Q:2-_2lGDcZU3THX3
wAt9|j:9:OyvSwM8GmuFAN0zbg:eGXTUaknggG!bAgcqU62PgrkaxGCTXCtGlrF|lGq:XdUT1
np1lj08kyIC-qNcOpxAwjxS9Y|#A6g-dNJgxiDx+K6W?vp3jqpplpSDvTI:49N|16NHZNs :i
qA_92j6!YML9jMMF mv|b5NSS K97Seq|8JXS+5b2 zvmzf c+BCc qMmr|vyhVgc+xLhn_Oh
3O!9IS|9Vj9BY_G J-0: !zf!ZIGLjuq|Reqq9q4fuPt8vm0y5G0#H0p78zeYE6eGd3O sO+5
4KxCIUCRCe614E_K 5aI72VD297P BMP76eD|1VqjmRP uXjdF3jP|NiCBPoVUKmx1QT_skiB
rD_IvYESiE::6th4CKM67?:hNStD1:g _xH_jdY54#+y8YK+snh2|zyf0:we UtwCKHhcI:jc
j4vbZ0hkYSkr2!Vq5ua+rxT4mHUxGtLYEEXXxeTAmzsyG_vL4hX:xeArSKJq8ldm4ij2qklrx
848Tf?I76s?TZVDsSW7NW M6om3j+E6|jiIbOR_+5uD4US?14G|Nb9dD 961hLBj1zsb!0bZo
QefvLrM!sP:OmqqRRsHuCNV_BPG0O83RXsHCapIbJ75#N8czeJx5as7LxiFv#5cVydKyrsPL3
gJxaabTzbY!7LSCNsZ-XhBFrl1dbtleLgsPmrHP7tK2VStDTs qsJ07ckxwul2mwXg_Xrr8nw
glo3YkbTQnzTQJ5evtzc8gDulM0o qF_std?h TFlgqwTrKm_Fd-74j73gJwzrK0gloYJteVS
aHDL7A+ZHlFLIygly8nkKBqQjNUQF8 sC48pgqJDq|?FV+ih-nsjh#Bw#NN1AhGL+Jm78BqAw
H-U8Jyg7n:6ei#af:qF?erI6l?As8iefonU9nwI-l7As!IrRm-ajd3F|0NVM-sccAbZIMC6VF
JqWhZczdLcpfqn_5kNwuKe30yKP6e8|ZeqXO3k8Vn3CFkDB_ke??9qDMr8tfqpRvqkGhMe2XF
AAx7JTdlXYYSdVMdA1!NjHgS1RNdUI2AxCDcaJuS8iiwm#NuxeJcNK7jSuiDA2ZAj!lj+n7D_
-FQf::fvo9:1MM:YVuA0VxX-+yuhn+61y 4vyVddlx aIupDxQFMxyPtaVcX1!mhmZAmLxT5W
CC603Xv0n:CqhLd 9:1g3yFpS2CYaaOf8L2gtSFLjWTC2ay1:v1T0kTQ?WyRNn14Qv_zy5|6l
qSU9E92MC9hstXhHAA+Ssy 5-aSKejShBLyHdfFDC:C1WCRSpOvAx8|4zwjcV|M18b:PnBqmN
pGWHgmJUU3:sBt|6lSB+2?9tUMGCXG?mk?1_2MufcGW1XdiMDY7Td3#HckI!h+Qsp?SjNB3 ?
p97lhhHvpl7#E93wDTkoWeiCtCB6Ca9lMN:rjvVugE?IvmBjht_|wUQ1|XS#Xp9_agWo2gd5R
Ua9QU!j|UQ|G:tdALda+OaP-bthr|dmPLW9tc01_WBJj|OHIU9:Qk8o:kHm3CE95BP?W6ptd3
usPh|dRWdWftqwqtZ21#4R5O4+ 4#T2C?nkCjbSZMM#Ml5YqO-?q:HL?J|sT3h-#rQ9#gB09P
j4ehkYokoQUs2Gvb5GS?xv_Tmmis?wO1TrHY1r_txSAJG+C04nza5xZ:dH93a!C0G56X4#fAx
us:1SdYdh14#T2C?nkCjbSZMM#Ml5YqO-?q:HL?J|sT3h-#rQ9#gB09P5t4QK_wb3XZiO|ZFS
p4sHcceZElZvE+Nh:gUlQqEUQIWBswi931xdjFMGBpaCqrTM#1x9GXZdRJwBBjU3IUcpG!sHG
jmQbkkb??bb9aO4Chq4HvXq_jG:iZh5Uux5VWYxwa2+uT1n#iLmKCjmf6oGlwssJE0qHP+qtd
gJ-mTnvc?VoJrCXtG-fSg78_B!wfPCXJSactZKuggGNr5NT7S0MzS1J 0QQrhDvlxH?t 3V
Second Run:
GAG58FX0vFXjbXH-S#Np6aEPC6ekzwQvpbP0 3F8AihC9UdZ0+2of_70kfqv?KH-SQo5kyEAM
hjLKSsOShgSjjH3Grh|YMjqC6fwRji hY9v?aJZDunghjC FYvd#x8nxCm#theeFMuXMrhTlC
:dZNv3gLrJMp04uYXAL 5z3v#nkrCjDa c:oPi6 pPVY?fIsduoUp7T#mb9rYCUN2AvIr:epy
p1rJJrJJrhhr4HM!mtC6AQiYq 50jSC!Gt?6QcrfEjfGorwCll?s0UsnCdhG34 EY5sj0I7F
kxATb4J4aBae!wHoXJx0WnZdLl0pdP V_s9m17E:ex5b#3ok83maad-2pXIwxUXvNUEnnyLXH
AoRZTCJ2!T#4-c::ZcokDSyFgo#9TTlncSKkMCstgolM jnvB4sibSNV!O1Xdj884jdEpwRI7
hM1S#R|RM1GKrJlMx7uChoIdYQnZYMSSem96piXhBpqGB7EE3fpxv9Zjn|BOfB#FxLVShoI6h
Dz3ivvRAodwv4wlgZZrQm73U8BLYANr8dJQ0p!Lus76Cwj#SxJII!JxDKTnktxm#j27FCTFY7
RK#iHq4tlVDiqV3Mr73+VVhWnz6f2|#6yq#gFFBU61en7OrZ#DU#_T1KIV|CHz||N|3UaQcki
qSKpX6p:MgXacPBTjDqRS1|MytVmc??jcmdLh5r6m tywS8|h8_Sh apmSLq1AMaC+9bh Yv+
QJdvgr#rdpm76yyoGd8Zb#JVv7zG7uR8-LrN!OaNNXNiGEM?53CJoI8JHUJPf5za:BWa809sZ
CFg3J2sndTYYBTdm5Oh9WdFqlDC wO NCOF|SdC5aLf0|:1sAOFpu1Rt1LOfpkbjAVNQI1Ttn
PdjcQ1QWQy-wUagFcNgxQxV#G_x6_g3bHF3m8Jjfmgmp0ZaVTAA4OeAR 3RqJTgjc??jb2?v0
xL+B? B m3gyOgBCnPy:me40_ZZyiYBCM|zl7DA00nH8v EC4ozl7hDr|H:irBmLv9rCl?DB|
jSWhZYRNSoZh6Tko5ePqx8d+x9jOwJ9q9HyXm_YGGt!RGUsxUVOYqw622w8I2#y45KkjCzS++
! vpssP#mwYBBcVoY1t:TnLqPzzv5mu#F1 QTnLxqy:5wVyYd9uKy1nsqY:wSyji79D-8diOs
XCV34ukN|9|WzyBUU0+ZU!i6!JbB:LS88L238 |CXRNP-lxppoMipVK6A9EpJx#r20jXCQkfC
u!e1W0uHKh2KRKdD-HW59Zf84MQ_CwD0qCdt?HVC94R_dw0XCl!T?:znt!rR44gLCb5|R9aft
s7RcsundeK|Y8u1xE7|gg7VUgLt2kQ8W?Pw--aO0-N!S3lq-hwizVe9k2yrI2iBEEVurPbz3k
cEXHAQK:TEdT-ZCkdpv:hT0n5d+r!ZxRb-rs:vvgNdW4l:pai-3CZfkNpdfoIDPu6Z-15aaxS
AcH!Y!JJCpCbHJOosE2NF+bc:MJSd!TAtkjoNIj2eewlovAdRTcAjFljX1SwAJdoyuNsW2wc9
Nd4brngbG+DCb+1NL1U-+BBAxDXbHX1cm1qzyWcwCXFiH1v30r4P-U3:CXXgS?dVPdM9pUU-Q
X+Qnb_IduieZkrnWkUAd4XQ?zC6Jzv22p8CgXA 4:Xz#8zylUpXkAC5|6VRvp:+JkUoF4X#iN
q7fgCpMgMH7rt7+?RCrn9HV5T7xUEw_bP1Uv9HHKgBmYbm A211PJLS_|S+Lj1ne2EYxwSW_s
ipqEg:X?!c-pYtxIgbtVG-VFMNct?xpiXTSLQcbfw?NPJgtGW4p#4zTJLZ-UFmPTvEt8mdb-Q
kuXTnNQz|asTNayvWFXJK v7TmmVBMp|Jp9un K!s0Xb0esN 5EnW|yF0UXotdAN#x+t9mtl
-Eb1J#-1|:18ylTE+ hZ!pmyIF6TxSr2lQWY+CY:Zrp8Vj-RSZo1lGRtIVmPyzdWV+?Dn4D5Z
!zupeZpspY0j?zc37puAR+LM+BRQg c34d1!8yziP94:2ntqeVJD8ynp1szKB6VXe_9gyZil5
hrp|wESsOSh6JjB8BGCBH?9:vxjxnhM1fO6naExgQCAu8RrA7Fx7iMCH16h9K|M8EsLrVY6:y
Zf#puO9hDFNPUqwJW0:SGmp2woALX-ufvV:SL8WhGt_1f ub2NScmQOPoYzJ4TlG2RcUJIhPS
_ObYH2 Jk72YU-LG1S+O-DkURITg547tg#NU#8GTe1OLyHhG4kzZt0VOnpJ1QMiVxW+aGJtcC
Fm7|tY1feJyc5ngtpeFPM6kjG54cQUzp!TNX_sv1m3:Y6UD!amHM_px mCMYp::vhNZMqex9j
VQ0qqPuIPYwuQeD2UDjGpKlrHZqXGwVY?QJWrtMIl|CdW8-RcGIQ_6u1e9hoQz#HGD1Prrn!H
WLqm:eKU2jtUkDEwAf1L2?I7xbe:gShmzfo2CgcUxL|jgqUmLhhetInURV|a_LSKVxjtDNna4
Qp73OmWkpry3wuxrveKyM-PLia5A3Hd#giIXzFe3PJqxEsTm+P2rNe6Euaa9_N0wvefCJiFCr
7:x!sRIUtHyZXI#:Gx4D97prCQ89mXZMD+?d+VesF:vPDblFyytLF6UdSI!84EBl9yIFKA4O
9F+3I6B#e65AEKQhDPrEDcbIVW9scy BcEnR?2ywFbhC2vpt2c:lf?HDudzNE0P-E2UiTnk46
GKir5CGmzJfE7FEBly6nQXfiH6PPv_6j5FsWa YK?HCPW6+dYc4#U+fK??FQVi+nyGnH1aFY
wc!:aa:PzUae88aBrc2zrAkqGXc|gOF5XwVfXr umGylJ4jxAL3TAX9+8k7e:yfPfIh:qAe10
2RIPO7LP|09zfg66O7gpSbDQ20?GEfW6Qg+B?TqUa+9GEEbrPz+RcCRfI2b?pD+rP4nNcdRj3
gJMzaz73_zlK2VlSALg qshMb7t5!UtlTQnZBm3qVcVrO3NtmwaeHA7BFJuJ2uLGezg4aXrs1
f mS+!RNg:xZ3OvGhIiLOARNN0j!8OK+ Kg620GbuOj!QDB+nKmcD0t44O|kAvBM?KIcL00TK
fK6QTTSc_QIMHA0?nU|w2!VqNq3R!hA2PExBz_w9KCKyC+ZxSOXEL3:i4 u+uDG6nKjN2KDWg
F_CF1GhM1FMvkGm4XmpGjdEZHA-xhmN4JQsgjdUVQPPx8zmU96pgRp5Vc|PidU6Jqpkf ylKs
gJ17?3TY3YHN?s5BurGPLhsVAl0AcgrHkJFKk3SdX MTYsJaVhR5wtlRmgDC? 5c8fG1US4!v
UW1j|o+|+jOHMrE68LsyYE33e4cOyS5k8xkWYnK3usy5r0kTpo:gt6yPu_55N0DdItdam+yy6
gJBma3L37mAcgrHkJFKk3SdX MTYsJaVhR5wtlRmgDC? 5c8fG1US4!vsBefg1n3ht7QlZOXS
bCYjqq#b?tbN?p FN-cyocxVu#HSLF-EncXQ?_290F3SJ--Gn5z69zAkwFF0S?Zn8Z aYzcBw
UahK||KUUKKUa5LDOTH_WkTK31PcyH!qt6Y4druSa8gt3Yo+OWnGkMw?da1LSppnBdQkWgG3k
R:rZbqHTDa:6Azhrq8Md OeBI::jAac!dc|xVOO Bq3A73+-yczUVq-fY3gnec5S7iorx|:4Y
As you can see, it looked different for the same order of 50 lines of text.
So, any ideas?
Any encryption method which relies on the secrecy of the algorithm is flawed. The attacker will always know the algorithm. See Kerckhoff's Principle for a longer explanation.
It is absurdly easy to write an algorithm that you yourself cannot break, anyone can do it. However, unless you are a professional cryptographer, a professional cryptographer will find it easy to break. Have you tested your algorithm against differential cryptanalysis? Do you even know what differential cryptanalysis is?
There are many excellent cyphers available already, suitable for many different purposes and with varying levels of complexity and security. Don't reinvent the wheel; use an existing cypher.
Related
This is related to this question on accesing the POD, but it goes further than that. You can easily access the Abstract Syntax Tree of a Perl 6 program using:
perl6 --target=ast -e '"Þor is mighty!".say'
This will print the whole Q abstract syntax tree. It's not too clear how to make this from your own program, or I haven't found how to do it. In fact, the CoreHackers::Q module runs that as an external script. But being able to access it from your own program, like
use QAST; # It does not exist
my $this-qast = QAST::Load("some-external-file.p6") # Would want something like this
would be great. I'm pretty sure it should be possible, at the NQP level and probably in a Rakudo-dependent way. Does someone know hot it goes?
Since QAST is not a part of the Perl 6 language specification, but an internal implementation detail of Rakudo, there's no official way to do this. Eventually there will be an AST form that is part of the language specification, but that doesn't yet exist (the 007 project which is working on exploring this area).
It is, however, possible to obtain the QAST tree by using:
use nqp;
my $ast = nqp::getcomp("perl6").eval("say 42", :target<ast>);
say $ast.dump();
I am a beginner to programming. I am trying to run a simulation of a combustion chamber using reactingFoam.
I have modified the counterflow2D tutorial.
For those who maybe don't know OpenFOAM, it is a programme built in C++ but it does not require C++ programming, just well-defining the variables in the files needed.
In one of my first tries I have made a very simple model but since I wanted to check it very well I set it to 60 seconds with a 1e-6 timestep.
My computer is not very powerful so it took me for a day aprox. (by this I mean I'd like to find a solution rather than repeating the simulation).
I executed the solver reactingFOAM using 4 processors in parallel using
mpirun -np 4 reactingFOAM -parallel > log
The log does not show any evidence of error.
The problem is that when I use reconstructPar it works perfectly but then I try to watch the results with paraFoam and this error is shown:
From function bool Foam::IOobject::readHeader(Foam::Istream&)
in file db/IOobject/IOobjectReadHeader.C at line 88
Reading "mypath/constant/reactions" at line 1
First token could not be read or is not the keyword 'FoamFile'
I have read that maybe some files are empty when they are not supposed to be so, but I have not found that problem.
My 'reactions' file have not been modified from the tutorial and has always worked.
edit:
Sorry for the vague question. I have modified it a bit.
A typical OpenFOAM dictionary file always contains a Foam::Istream named FoamFile. An example from a typical system/controlDict file can be seen below:
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object controlDict;
}
During the construction of the dictionary header, if this Istream is absent, OpenFOAM ceases its operation by raising an error message that you have experienced:
First token could not be read or is not the keyword 'FoamFile'
The benefit of the header is possibly to contribute OpenFOAM's abstraction mechanisms, which would be difficult otherwise.
As mentioned in the comments, adding the header entity almost always solves this problem.
If I begin with a wholly Japanese sentence and run it through MeCab, I get something like this:
$ echo "吾輩は猫である" | mecab
吾輩 名詞,代名詞,一般,*,*,*,吾輩,ワガハイ,ワガハイ
は 助詞,係助詞,*,*,*,*,は,ハ,ワ
猫 名詞,一般,*,*,*,*,猫,ネコ,ネコ
で 助動詞,*,*,*,特殊・ダ,連用形,だ,デ,デ
ある 助動詞,*,*,*,五段・ラ行アル,基本形,ある,アル,アル
EOS
If I smash together everything I get from the last column, I get "ワガハイワネコデアル", which I can then feed into a speech synthesis program and get output. Said program, however, doesn't handle English words.
I throw English into MeCab, it manages to tokenise it (probably naively at the spaces), but gives no reading:
$ echo "I am a cat" | mecab
I 名詞,固有名詞,組織,*,*,*,*
am 名詞,一般,*,*,*,*,*
a 名詞,一般,*,*,*,*,*
cat 名詞,固有名詞,組織,*,*,*,*
EOS
I want to get readings for these as well, even if they're not perfect, so that I can get something along the lines of "アイアムアキャット".
I have already scoured the web for solutions and whereas I do find a bunch of web sites which have transliteration that appears to be adequate, I can't find any way to do it in my own code. In a couple of cases, I emailed the site authors and got no response yet after waiting for a few weeks. (Just how far behind on their inboxes are these people?)
There are a number of directions I can go but I hit dead ends on all of them so far, so this is my compound question:
MeCab takes custom dictionaries. Is there a custom dictionary which fills in the English knowledge somewhat?
Is there some other library or tool that can take English and spit out Katakana?
Is there some library or tool that can take IPA (International Phonetic Alphabet) and spit out Katakana? (I know how to get from English to IPA.)
As an aside, I find that the software "VOICEROID" can speak English text (poorly, but adequately for my purposes). This software uses MeCab too (or at least its DLL and dictionary files are included in the install.) It also uses another library, Cabocha, which as far as I can tell by running it does the exact same thing as MeCab. It could be using custom dictionaries for either of these two libraries to do the job, or the code to do it could be in the proprietary AITalk library they are using. More research is needed and I haven't figured out how to run either tool against their dictionaries to test it out directly either.
In an effort to better understand RSA I've been fooling around with the source code for GunPG 1.4, specifically the RSA implementation in the rsa.c file. As the title says, I can't figure out where the padding is happening.
So typically in RSA, padding is done right before the encryption and is taken off during the decryption. Encryption first starts around line 409 where we see
int
rsa_encrypt( int algo, MPI *resarr, MPI data, MPI *pkey )
{
RSA_public_key pk;
if( algo != 1 && algo != 2 )
return G10ERR_PUBKEY_ALGO;
pk.n = pkey[0];
pk.e = pkey[1];
resarr[0] = mpi_alloc( mpi_get_nlimbs( pk.n ) );
public( resarr[0], data, &pk );
return 0;
}
That seems easy, it's giving data to "public" function higher up on line 220. Public is responsible for calculating the important (c = m^e mod n) process. That all looks like:
static void
public(MPI output, MPI input, RSA_public_key *pkey )
{
if( output == input ) { /* powm doesn't like output and input the same */
MPI x = mpi_alloc( mpi_get_nlimbs(input)*2 );
mpi_powm( x, input, pkey->e, pkey->n );
mpi_set(output, x);
mpi_free(x);
}
else
mpi_powm( output, input, pkey->e, pkey->n );
}
Wait a second...now it looks like public is passing the job of that calculation off to mpi_powm() located in the mpi-pow.c file. I'll spare you the details but that function gets really long.
Somewhere in all of this some sort of PKCS#1 padding and unpadding (or something similar) is happening but I can't figure out where for the life of me. Can anyone help me see where the padding happens?
In an effort to better understand RSA I've been fooling around with the source code for GnuPG 1.4, specifically the RSA implementation in the rsa.c file.
Since you’re looking at the older (< 2.0) stuff anyway, and since it’s only for learning purposes, I would rather advise you to check out “ye olde rsaref.c from gnupg.org” where the padding is implemented in a pretty obvious way.
… some sort of PKCS#1…
To be exact, GnuPG uses PKCS #1 v1.5 (specified in RFC 4880).
Can anyone help me see where the padding happens?
Hmmm, let’s see if I can wrap that up somewhat logically. GnuGP pads according to PKCS #1 v1.5, so it just adds random pad to satisfy length requirements.
If you take a look at the cipher/pubkey.c file (which includes the rsa.h file in its head), you’ll notice a pubkey_table_s struct which defines a list of elements that define the key. For padding reasons, random bytes are appended to that list (better: after that struct). It’s done that way because those random bytes can easily be stripped by looking for the end of the list. Keeping a long story short, that’s where random.c probably starts to make a bit more sense to you. Now, all that stuff (and a whole lot more) is compiled into a lib called libcipher… which in itself is compiled to be used by functions that add the padding and handle the RSA stuff the way you expected it. In the end, the compiled executables use the functions libcipher provides to take care of the padding – depending on the individual need for padding.
So what you currently expect to find in 1 or 2, maybe 3 files is actually spread out across more than half a dozen files… which I regard not to be the best base for your learning efforts. As said, for reference purposes, I’ld go for the old rsaref.c they once started out with.
Not sure if this actually provides all the details you wanted to get, but it should give you a first good heads-up… hope it helps.
GPG 1.4 doesn't use any padding at all. It encrypts the raw session key.
I have Vim 7.2 installed on Windows. In GVim, the <C-PageUp> and <C-PageDown> work for navigation between tabs by default. However, it doesn't work for Vim.
I have even added the below lines in _vimrc, but it still does not work.
map <C-PageUp> :tabp<CR>
map <C-PageDown> :tabn<CR>
But, map and works.
map <C-left> :tabp<CR>
map <C-right> :tabn<CR>
Does anybody have a clue why?
The problem you describe is generally caused by vim's terminal settings not knowing the correct character sequence for a given key (on a console, all keystrokes are turned into a sequence of characters). It can also be caused by your console not sending a distinct character sequence for the key you're trying to press.
If it's the former problem, doing something like this can work around it:
:map <CTRL-V><CTRL-PAGEUP> :tabp<CR>
Where <CTRL-V> and <CTRL-PAGEUP> are literally those keys, not "less than, C, T, R, ... etc.".
If it's the latter problem then you need to either adjust the settings of your terminal program or get a different terminal program. (I'm not sure which of these options actually exist on Windows.)
This may seem obvious to many, but konsole users should be aware that some versions bind ctrl-pageup / ctrl-pagedown as secondary bindings to it's own tabbed window feature, (which may not be obvious if you don't use that feature).
Simply clearing them from the 'Configure Shortcuts' menu got them working in vim correctly for me. I guess other terminals may have similar features enabeld by default.
I'm adding this answer, taking details from vi & Vim, to integrate those that are already been given/accepted with some more details that sound very important to me.
The alredy proposed answers
It is true what the other answer says:
map <C-PageUp> :echo "hello"<CR> won't work because Vim doesn't know what escape sequence corresponds to the keycode <C-PageUp>;
one solution is to type the escape sequence explicitly: map ^[[5^ :echo "hello"<CR>, where the escape sequence ^[[5^ (which is in general different from terminal to terminal) can be obtained by Ctrl+VCtrl+PageUp.
One additional important detail
On the other hand the best solution for me is the following
set <F13>=^[[5^
map <F13> :echo "hello"<CR>
which makes use of one of additional function key codes (you can use up to <F37>). Likewise, you could have a bunch of set keycode=escapesequence all together in a single place in your .vimrc (or in another dedicated file that you source from your .vimrc, why not?).