GnuPG 1.4 RSA: Where's the Padding? - encryption

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.

Related

Plothraw PARIGP (or similar) doesn't work (latexit crash)

I'm a new user of PARI/GP, and after writing my script, I wanted to make a graph of it. As my function take an integer and return a number, it's closer to a sequence. Actually, I didn't know how to do it, so I read the documentation of PARI/GP, and after that I made some test in order to obtain a graph from a list.
After reading an answer in stackoverflow (Plotting multiple lists in Pari), I wanted to test with the following code:
plothraw([0..200], apply(i->cos(i*3*Pi/200), [0..200]), 0);
But when I do it, it tries to open something on latexit, but then it crash and give me a problem report.
I didn't even know that I had an app named latextit, maybe it was install during the installation of PARI/GP. Anyway, how can I fix this?
PARI/GP definitely doesn't install latexit.
The way hi-res graphics work on the Win32 version of PARI/GP is to write down an Enhanced Metafile (.EMF) in a temp directory and ask the system to
"open" it. When you installed latexit it probably created an association in the registry to let it open .EMF files
i3Pi does not mean what you think, it just creates a new variable with that name. You want i * 3 * Pi instead.
The following constructions both work in my setup
plothraw([0..200], apply(i->cos(i*3*Pi/200), [0..200]), 0);
plothraw([0..200], apply(i->cos(i*3*Pi/200), [0..200]), 1);
(the second one being more readable because a red line is drawn between successive points; I have trouble seeing the few tiny blue dots)
Instead of apply, you can use a direct constructor as in
vector(201, i, cos((i-1) * 3 * Pi / 200))
which of course can be computed more efficiently as
real( powers(exp(3*I*Pi/200), 200) )
(of course, it doesn't matter here, but compare both commands at precision \p10000 or so ...)

XC8 builds font tables from top ROM

I wrote a barebone progran template in XC8 (1.37) that I use to develop and test new GLCD functions for the 18F family. Programming is done via a PICkit3. Since I need to quicky reprogram several times the code it is really important that programming is faster as much as possible.
Tipically, the code size is around 2K and it takes less than 10 sec to program,
Everiything is fine until I must use a font table, defined as:
const char font8[] = {....
Now, with just $400 bytes added, the compiler place the table at the ROM's end and the programming of 64K memory takes more than 1 minute.
Is there any way to avoid this?
I tried to manually limit the memory range in the MPLABX options, but this is annoying and a little unsafe (sometimes part of code is truncated).
A while back I had to write some code for emissions testing, where I needed to copy data between extreme ends of RAM. To do that I needed to specify the exact memory addresses. You can also use the C extension __at() construct. http://ww1.microchip.com/downloads/en/DeviceDoc/50002053F.pdf#page=27
int scanMode __at(0x200);
const char keys[] __at(123) = { ’r’, ’s’, ’u’, ’d’};
int modify(int x) __at(0x1000) {
return x * 2 + 3;
}

How to obtain an xmlBuf for use with xmlBufGetNodeContent/xmlBufNodeDump etc.?

The description of xmlNodeDump() (which takes an xmlBufferPtr) states:
Since this is using xmlBuffer structures it is limited to 2GB and somehow deprecated, use xmlBufNodeDump() instead.
Fair enough, but since xmlBufNodeDump() (and e.g. xmlBufGetNodeContent) takes an xmlBufPtr my question: How to create such an xmlBuf buffer?
I can't find anything obvious.
And how to free it?
I mean, for xmlBuffer there is e.g. xmlBufferCreate().
Or is one supposed to obtain an xmlOutputBuffer via xmlAllocOutputBuffer() and use its xmlOutputBuffer::buffer attribute (of type xmlBuf*) for xmlBufNodeDump()?
For those who need an answer:
xmlBufferPtr buffer;
buffer = xmlBufferCreate();
xmlBufPtr buf;
buf = xmlBufFromBuffer(buffer);

Need ideas and testing a new encryption method I developed

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.

Unix write() function (libc)

I am making a C application in Unix that uses raw tty input.
I am calling write() to characters on the display, but I want to manipulate the cursor:
ssize_t
write(int d, const void *buf, size_t nbytes);
I've noticed that if buf has the value 8 (I mean char tmp = 8, then passing &tmp), it will move the cursor/pointer backward on the screen.
I was wondering where I could find all the codes, for example, I wish to move the cursor forward but I cannot seem to find it via Google.
Is there a page that lists all the code for the write() function please?
Thank you very much,
Jary
8 is just the ascii code for backspace. You can type man ascii and look at all the values (the man page on my Ubuntu box has friendlier names for the values). If you want to do more complicated things you may want to look at a library like ncurses.
You have just discovered that character code 8 is backspace (control-H).
You would probably be best off using the curses library to manage the screen. However, you can find out what control sequences curses knows about by using infocmp to decompile the terminfo entry for your terminal. The format isn't particularly easy to understand, but it is relatively comprehensive. The alternative is to find a manual for the terminal, which tends to be rather hard.
For instance, I'm using a color Xterm window; infocmp says:
# Reconstructed via infocmp from file: /usr/share/terminfo/78/xterm-color
xterm-color|nxterm|generic color xterm,
am, km, mir, msgr, xenl,
colors#8, cols#80, it#8, lines#24, ncv#, pairs#64,
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, bold=\E[1m, clear=\E[H\E[2J, cr=^M,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
el=\E[K, enacs=\E)0, home=\E[H, ht=^I, hts=\EH, il=\E[%p1%dL,
il1=\E[L, ind=^J,
is2=\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8, kbs=^H,
kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
kdch1=\E[3~, kf1=\E[11~, kf10=\E[21~, kf11=\E[23~,
kf12=\E[24~, kf13=\E[25~, kf14=\E[26~, kf15=\E[28~,
kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, kf19=\E[33~,
kf2=\E[12~, kf20=\E[34~, kf3=\E[13~, kf4=\E[14~,
kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
kfnd=\E[1~, kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
kslt=\E[4~, meml=\El, memu=\Em, op=\E[m, rc=\E8, rev=\E[7m,
ri=\EM, rmacs=^O, rmcup=\E[2J\E[?47l\E8, rmir=\E[4l,
rmkx=\E[?1l\E>, rmso=\E[m, rmul=\E[m,
rs2=\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8, sc=\E7,
setab=\E[4%p1%dm, setaf=\E[3%p1%dm, sgr0=\E[m, smacs=^N,
smcup=\E7\E[?47h, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m,
smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n,
u8=\E[?1;2c, u9=\E[c,
That contains information about box drawing characters, code sequences generated by function keys, various cursor movement sequences, and so on.
You can find out more about X/Open Curses (v4.2) in HTML. However, that is officially obsolete, superseded by X/Open Curses v7, which you can download for free in PDF.
If you're using write just so you have low-level cursor control, I think you are using the wrong tool for the job. There are command codes for many types of terminal. VT100 codes, for example, are sequences of the form "\x1b[...", but rather than sending raw codes, you'd be much better off using a library like ncurses.

Resources