\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={Authorised Secure Host Communication under Data Provenance Verification-A Signcryption Based Contract Signing Protocol},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2012-01-15 (revised: 15 January 2012)}
\def\TheID{\makeatother }
\def\TheDate{2012-01-15}
\title{Authorised Secure Host Communication under Data Provenance Verification-A Signcryption Based Contract Signing Protocol}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Bolladi  Swathi}

             \affil[1]{  Sree Chaitanya College of Engineering, karimnagar}

\renewcommand\Authands{ and }

\date{\small \em Received: 8 December 2011 Accepted: 2 January 2012 Published: 15 January 2012}

\maketitle


\begin{abstract}
        


The wide qualities of distributed (ex: P2P networks) network has given us many advantages and threats for enhancement of distributed computing. The best way to reduce threats is adding a reputation-based globally trusted model. Many present trust models are failing to restrain effectively some behaviors like collusive attacks, but pay no heed towards the security of this mechanism.

\end{abstract}


\keywords{}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{Introduction}]{Introduction}\par
f late, distributed computing has become popular and well recognized in a wide range of applications, like file-sharing, digital content delivery, and distributed Grid computing \hyperref[b0]{[1]}. But the fact remains that, peer anonymity and autonomy make distributed networks easy towards attacks by any peer who is not rust worthy. The recent works \hyperref[b1]{[2]}\hyperref[b2]{[3]}\hyperref[b3]{[4]}\hyperref[b4]{[5]} are a benchmark to the fact that the trust theories in social networks construct well recognized trust models, to find a solution for these kinds of behaviors.\par
The present reputation-based trust model designs trusted rank of a peer based on its past transactions, and it's similar to the peer with full trust value is offered the role of the service provider. This method has some advantages on any malicious behaviors to a certain extent, but has a meager effect when it comes to complex attacks and when disturbances are created on these reputation systems, like collusions. The researches now a day focus on the design and working of the trust system in all sensible arenas, and barely care concerning the security difficulty it faces which can damage the tag -node consistency handling?. The security of node reliability handling is the most important element which assures a safe working of the trust management system (TMS). Thus, it is vital to develop and discuss about the security mechanism of the TMS.\par
Dealing by means of these research issues, we project node reliability based distributed trust model with the security mechanism that we refer as the secure node reliability information management (SNRIM), for distributed networks, which would scales better over node reliability information management(NRIM). 
\section[{II.}]{II.} 
\section[{Related work}]{Related work}\par
This sector gives a wide review of some of the present distributed node reliability systems, concentrating on problems like storage and veracity. We would like to at first give an outline of the node reliability systems. Kevin A. Burton designed an open privacy distributed node reliability system \hyperref[b4]{[5]} on p2p, which hails from the distributed trust model which brought to us the idea of node reliability network, which is made up of identities and certificates. Therefore, the certainty of the identities is appreciated from a visible sub-graph of the reputable network. P2PREP \hyperref[b5]{[6]}, which is a node reliability sharing protocol designed for Gnutella, where every peer keeps track and shares the node reliability of their peers. Reputation sharing is made by distributed polling protocol. Service requesters use this trust by polling peers. Karl Aberer et.al. \hyperref[b6]{[7]} Made a trust managing system on the distributed system which combines the trust and data management to construct a complete distributed architecture for information systems. The node reliabilities here are expressed as complaints; higher the complaints, less trustworthy it is. After every transaction, if there is dissatisfaction, a peer files a complaint stating the problem. To examine the node reliability of a peer involves searches for complaints about the peer. Kamvar et.al \hyperref[b7]{[8]} proposed a node reliability management system, for distributed file sharing systems such as Gnutella fighting against the spread of inauthentic file. Here, every peer has a global node reliability that shows experiences of every peer with it. Sit and Morris \hyperref[b8]{[9]} gave an idea for security of p2p networks. Their model permits nodes to make packets with arbitrary material, but lets the nodes not to intercept arbitrary traffic. They gave taxonomy of all varied attacks and at the routing layer, they find a node lookup, routing table preservation, division the network and virtualization as threat to security. They deal also with multilevel protocols, like file storage, where nodes need not have the necessary invariants, like storage replication. They work also on denial-of-service attacks, and rapidly joining and leaving the network, or arranging for various nodes which sends bulk volumes of data to overload a  
\section[{Node reliability systems}]{Node reliability systems}\par
A vital corollary of a good node reliability management is the online auction system eBay \hyperref[b8]{[9]}. Here, buyers and sellers rate each other post transaction, and the final node reliability of a contestant is the ratings he has over the last 6 months. This system depends on a central system to store and manage these ratings.\par
In varied areas nodes rate each other post transaction, like in eBay system. Like, every time peer I gets a file from peer j, it rates the transaction as positive (tr(i, j) = 1) or negative (tr(i, j) = ?1). Peer i can rate a download as negative, if he finds the file inauthentic or tampered with, or if interrupted. Like in the eBay approach, we may possibly characterize a local faith value ij s as the sum of the ratings of the individual transactions that node i has downloaded from node j :ij ij s ptr ? .\par
Similarly, every peer i can store many transactions it has had with node j , ( , ) sat i j and the number of intolerable transactions it has had with node j , ( , ) unsat i j . Then, ij s is defined:( , ) ( , ) ij s sat i j unsat i j ??\textbf{(1)}\par
Previous work in distributed node reliability systems \hyperref[b5]{[6,}\hyperref[b0]{1]}  Leechers are the ones who gain benefit from the system without giving anything to the system. The rogue nodes send malware in the network. Finally, nodes judge the quality before making Go/No-Go in every transaction and develop trust relationships mutually.\par
A good node reliability system gives the way to achieve the target. Any node reliability system is open to ballot stuffing and bad mouthing as told in  {\ref [18]}. A poor node reliability system naturally gives problems that exploit the attackers. Peers should have unique way to handle to which their node reliabilities are tagged. If they are absent in trusted central agency, an attacker gathers infinite identities and gives recommendations to itself. A node can alter the reliability data in the network to uplift its node reliability and there are problems that are in the picture based on how a given node reliability system is made. We discuss those problems and their mitigation in the sections where the design decision is made. 
\section[{b) Self-Certification}]{b) Self-Certification}\par
To participate in the node reliability system, a node should have handled. The reliability of a node is represented with handle. This handle is the -identity? of the node even if does not -discover? a node, i.e., it may not lead to the real-life identity of the peer. A node gets advices for every transaction, and all advices are stored together for calculation of the reliability of a node. In a central system, the head gives these identities. In a distributed node reliability system, selfcertification [33] divides the trusted entity among the nodes and gives their own identities. Every node has its own CA that gives the identity certificate(s) to the peer. All the certificates used here are same to SDSI certificates \hyperref[b5]{[6]}. The name of a node is with its identity and the node reliability of a CA is the node reliability.\par
Self-certification obviates the central trusted entity for giving identities in a central system. Peers having self-certified identities are pseudononymous in the system as there isn't a way to map the identity of a node in the system to its real-life. Though anonymity or at least pseudonymity is required in distributed networks, in a node reliability system it is a double edge sword. If there is no mapping between multiple identities and the owner (peer), the system is open to Sybil attack or Liar farms.\par
A node uses self-certification generating many identities and raises the node reliability of identities doing false transactions. The malicious node need not collude with distinct nodes to build its node reliability, but should generate a set of identities. The set of identities managed by one node is called an identity farm. The identities issuing a false recommendation are called a liar farm. These attacks are of the class of attacks named Sybil attacks. A node having an identity farm is as powerful subverting a node reliability system as a node colluded with many of other peers.\par
An identity farm is countered if, a node is not allowed to one identity or all the identities of a node are sent back the peer. A node can be stopped to one identity by mapping its identity to its real-life identity and leaving anonymity, or by making the identity generation resource high that the node cannot generate more identities. Identity generated is made resource intensive by traditional micro-payment method, although the resource restrictions have a varied impact based on every peer's resourcefulness.\par
In self-certification, we have a combination of approaches. Every node CA gives many identities. The advices received for a peer's identity from identities of peers, signed by the other peer's CA(s), are recognized as signed by the CA, and are made to counter the liar farms. In every transaction, the requester averages all the advices of the provider by CAs of the provider's last advisors. Hence, all the past advices owned by the provider are but they get averaged. Finally, it sums up the averages of each CA calculating the node reliability of the provider identity.\par
Hence, a peer should not use its own identities (all generated by the same CA) to advice its other identities.\par
A determined peer can begin many CAs and give groups of identities. In order to oppose a rogue node with multiple CAs, the nodes are made to batches on various grounds like a node can't be a part of many groups. For example, a distributed network in a city ensures the nodes by their zip codes. Every node gets its group certificate from the required head and attaches it to its CA. The certificate of a group head is publicly used by any node inside or outside the group. The node sends its credentials to the group and the head checks and signs the group certificate.\par
Unlike the traditional CA or distributed CA ways, grouping of nodes has the anonymity of the peers; when grouped with self-certification it curtails the happening of a Sybil attack. In opposition to the traditional CA, neither the group head nor the transacting nodes establish the identity of the peer. The certificate revocations are not necessary in the group-based way as the group head vouches for the real-life of the peer, unlike the traditional certificate-based approaches where many certificate attributes are attested by the head and need revocation. If a good identity is adjusted, its misuses are self destructive as its node reliability will go down if misused.\par
The node is named P while the head is denoted by A. Here P?A: X represents that the node (P) sends a message X to the head (A), here The logic in the group-based way is that in a distributed network, nodes are interested in the ranks of providers than only the value of the node reliabilities. The simulations tell that this way varies the name of nodes but it having least effect on the relative ranks of the peers. This approach is from the Google page rank idea in which the pages in proximity of other don't give the page rank of the target page in the pages at a distance  {\ref [34]}. The relative ranks don't object the nodes from adjusting thresholds. The thresholds depend on ranks. Adjusting the thresholds for absolute values are have a limited utility. Google has ranks instead of links pointing to/from pages. It is clear from the Google corollary that rank-based mechanisms can be measured. Debates between there might be some systems needing absolute values still take place. This paper is not into that, as use of absolute values is more complex and is specific information that is not a part of our discussion.\par
It is opposed and supported that this way is unjustified to nodes whose authentic advice are from ( nodes that are a part of a large group. We support the argument and our implementations display that the relative ranks of the providers change the least. Hence, the providers are least influenced (? Mean Rank Difference?14 for varied sizes groups) by the batches of advices. The requesters who give the advice to the providers can't be influenced by the batching of advices. 
\section[{c) Node Reliability Model}]{c) Node Reliability Model}\par
The standard Join methodology is made use of by peer to connect itself to a specific distributed network. The search appeal entails the peer supplicant to produce a list of nodes who have the demanded file(s) with them. RANGE indicates the count of nodes who tender a mentioned meticulous file. The peer supplicant chooses the provider with the peak status by instigating the cryptographic procedure which involves the peer supplicant making use of the Download methodology of the network for downloading the relevant file mentioned by the client, which again assists in validating the reliability, dependability and the value of the file. A proposal is then sent to the peer client between min -recommendation and maxrecommendation, which are limited to the restrictions ensuring that a single implication doesn't utterly annul or radically improve the meticulousness of a supplicant. On receiving the suggestions from the client, it averages the prior received implications and incorporates the recently received ones to estimate its repute.\par
The factors mentioned above can be assigned values by the means of Decision Theory, Game Theory, and Probability and function F() is identified on the basis of intensity levels of menace faced by nodes in the distributed network. The function F() in this paper is described as the arithmetic average of the suggestions that are collected by the peer supplicant. The recommended node reliability copy is self governing as compared to topology of the distributed network, nodal addressing formats, bootstrap procedures, joining and leaving protocols of the nodes present and the name service.\par
A negative suggestion may be issued by an applicant to the peer supplicant which may turn out to be hazardous concerning its node reliability even though the supplicant actually is worthy of a positive recommendation for a specified transaction. If in a way, only positive recommendations are accepted, then it would be tougher to distinguish between new and bad peers. Hence an assumption is made here that both positive and negative proposals are permitted and a given peer would no longer cooperate with those nodes who frequently deliver negative proposals. 
\section[{d) Contract signing between peers: a signcryption approach}]{d) Contract signing between peers: a signcryption approach}\par
The entire process starts here with the employment of RSA signature algorithm [42] otherwise known as Signcryption. At this point, the 1 st user divides his private key d into d1 and d2 such that 12 d d d ?? by following park  {\ref [40]}. The signature of this user has to be exchanged with the other and this signature is1 ( ) mod d A h m n ? ?\par
. The partial signature generated by the 1 st user is to assure that he has zero-knowledge base and this is done by Gennaro topology  {\ref [27]}.The relations we have are defective owed to network failure or router's attacks  {\ref [36]},  {\ref [46]}. But, TTP is reliable since the messages inserted reach the destination for sure but with some delay. 
\section[{i. Registration Protocol}]{i. Registration Protocol}\par
The receiver of the information has only to record i.e. merely the recording process of the initiator with TTP is enough. He then gets a long-term voucher along with CA. After this, the following processes are done: (for our convenience, let the sender be BOB and receiver as ALICE.) a. Alice first sets an RSA modulus n pq ? , where p and q are two -bit safe primes, i. iii.\par
After receiving the commitment r , Bob sends Alice the pair ( , ) ijto acknowledge that he is done with the challenge c properly. iv.\par
Alice verifies for correct preparation of c, that is ? . If all this do not happen, Bob seeks the help of TTP for connection before the expiry of the date. 
\section[{IV. Node reliability exchange protocol}]{IV. Node reliability exchange protocol}\par
The status swapping procedure is commenced with the node supplicant when the node applicant chooses the supplicant with the highest status. This procedure requires the applicant to be represented as R and the node supplicant is represented as P. As in R?P: X represents that the node sends a message X to the supplicant (P).denotes private key of node P while symbolizes blinding phrase with a key K. H(?) denotes a one way hash of the value ?. This procedure supposes that obtainable functions are inserting and search, but are not flexible enough for nodes which may not be proposed tag along the join and leave procedures of the network. The status swapping procedure contains the following phases:\par
Step 1: R?P: RTS \& IDR a REQUEST FOR TRANSACTION (RTS) is sent by the node applicant along with its own IDENTITY CERTIFICATE (IDR) to the node supplicant as it is required for authentication purposes in Step 7.\par
Step 2: P? R:IDP \& TID \& 2 k p E (H(TID)?RTS .\par
The peculiar IDENTITY CERTIFICATE (IDP), the CURRENT TRANSACTION ID (TID) and the signed TID, 2 k p E (H(TID)?RTS is sent by the node supplicant wherein signed TID is essential for the supplicant to avoid duplication of the usage of the same transaction id again. The applicant also applies for this signed TID and piles it up in the network at the end of the procedure for admission to other peers.\par
Step 3: R : LTID ( Max (Search(PK1? TID)). The value of the LAST TRANSACTION ID (LTID) that was used by the supplicant is gathered by the node applicant who then combines the public ke P of the node supplicant along with the string TID and a search operation is carried out. Any node present in the network responds only when it has the relevant TID that is specified by the applicant and the node applicant chooses the highest TID out of all the TIDs received. The highest TID value becomes the LTID. It is certainly possible that the node supplicant may conspire with the node who piled up its last LTID and may modify it, but this is impossible as the applicant registers relevant information. Step 4: R : IF(LTID? TID)GO TO Step 12 Foul play is presumed if the value of LTID initiated by the node applicant is originally from some other random transaction and applicant jumps to Step12. 
\section[{Volume XII Issue XV Version I}]{Volume XII Issue XV Version I}\par
Step 5: R?P: Past Recommendation Request \& r. If the step 4 check gives successful results, then applicant requests the supplicant for the earlier received proposals. If the current transaction being performed is, say Nth transaction, the applicant makes a head-on request for N-1th,N-2th,?.,N-nth proposals where r<N. The node applicant is solely responsible for deciding the value of r and is considered to be directly proportional to the applicant's venture in the transaction.\par
Step 6: P?R: CHAIN,2 K p E (CHAIN) CHAIN=(\{RE 1 N C ? ? 12 NK EZ ? (H(RE 1 N C ? )\}? \{RE 2 N C ? ? 22 NK Z E ? (H(RE 2 N C ? ,RE 1 N C ? ))\} ? \{RE 3 N C ? ? 32 NK Z E ? (H(RE 3 N C ? ,RE 2 N C ? ))\}? \{RE 4 N C ? ? 42 NK Z E ? (H(RE Nr C ? ,RE 1 Nr C ?? ))\})\par
The earlier received proposals RE1 N C ? , RE 2 N C ? ,??, RE 3 N C ? which were provided by nodes 1 N Z ? , 2 N Z ? ,?.., 3 N 
\section[{Z}]{Z}\par
.is sent by the supplicant. The CHAIN is singed so as to enable the applicant to hold supplicant responsible for the chain. The supplicant can, in no way, change the proposals that have been assessed by the earlier applicants. Consider an applicant (say 1 Z ) has signed both the (? th) and the previous (? -1th) recommendation using its private key2 K Z , as 2 K Zn E (H(RE 3 N C ? ? RE ( 1) N C ? ?? )\par
), in no way can a supplicant alter the CHAIN.\par
Step 7:R : Result=Verify(RE1 N C ? ;RE 2 N C ? RE Nr C ? ) If Result != Verified GO TO STEP 12\par
A simple public key cryptography protocol is employed by an applicant to authenticate the CHAIN. The authentication process is easier when a supplicant possesses certificates of all the nodes with whom it had connections earlier. In case it doesn't have one, it accumulates it from the supplicant itself. The provider had obtained its requester's certificate in Step 1. Liar farms (specified in Section 3.2, paragraph 2) are checked for by the applicant. The applicant jumps to Step 12 in case the authentication process fails.\par
Step 8: Contract signing between node selected under node reliability check and node that requesting the service Signature exchange protocol will get into action between Peer -SRP? that requesting the service and Peer -SPP? that selected as service provider by node reliability check.\par
Initially, the initiator SRP has to compute her partial signature Step 9: P?R : File or Service The file or service is afforded as per the obligation specified concerning search operation performed for the supplicants.\par
Step 10: R ?P : B1 =E Ka B (REC? TID? A BLINDING KEY (Ka) is produced by an applicant on receiving the service, who then combines the RECOMMENDATION (REC) and the TRANSACTION ID (TID) it had received in Step 2 and signs it. Consequently, the signed proposal is blinded along with the blinding key, Ka. This is done in order to entrust the supplicant to the proposal received before it actually knows the value, lest it disowns it on recognizing that it is low. It is also involves the fact that the supplicant made use of TID in a blinded suggestion from the node applicant, which is also authenticated by the applicant itself. The blinded proposal includes the Chain that is consequently used by the supplicant to certify its status to some other applicant.\par
Step 11: a. P ?R : B1? 2 K P E (H(B1),nonce),nonce b. R?P : Ka A NONCE is sent by the supplicant after signing the proposal even though it is unable to see the proposal and acknowledges it back to the applicant, who then authorizes the signature and sends blinding key Ka to the supplicant to unblind the received string in Step10a and confirms the received proposal.\par
Step 121: Insert(IDR;\{REC ?TID? 2 K R E \{H(REC) ? H(TID)\}\})\par
The proposal assigned to the supplicant (REC), the transaction id (TID), and its own identity certificate is verified by the applicant and is then accumulated in the network using Insert methodology of the distributed network which marks the end of the transaction.\par
Step 13: Step 12 is concerning the methodology executed by an applicant when foul play is anticipated.\par
ABORT PROTOCOL R: Insert (IDR; \{CHAIN ?TID?2 K R E \{H(CHAIN) ? H(TID)\}\})\par
If the authentication process in Step7 fails, the applicant takes the CHAIN that was verified b the supplicant and also the TID is taken into consideration after which, it is signed and the Insert methodology is preferred to be made use of to insert the chain and also its own identity certificate into the network. Subsequently, any suitable applicant wil be able to confirm with the statistics of the failed authentication efforts and a MIN RECOMMENDATION for that TID is presumed for the supplicant. Fafe proposals cannot be encouraged to be inserted into the network as TID is to initiated that is verified by the supplicant. If an applicant reaches Step 12 from Step 4 without any possible hindrances, it will then apply for the Chain form the supplicant and will then afterward execute R : Insert(IDR,\{CHAIN TID \{H(TID RTS))\}\}) ? ? ? .\par
V. 
\section[{Analysis of the protocol}]{Analysis of the protocol}\par
Only a single search request is supposed to be commenced in the network so as to gather the already received proposals that were previously received by the supplicant. Also able to prevent the tampering node reliability provided by SRP to SPP by nodes that in path. This process is required the accountability of tackling the issue of unbalanced nature of availability of nodes in the network, which is measured to be a main subject concerning distributed networks. 1. The supplicant unintentionally forwards the wrong TID in Step 2. Consider that id which the supplicant forwards as TID and the LTID be the last Transaction ID for the supplicant. The value of TID is always supposed to be equivalent to LTID + 1. If in case of TID' > LTID+1, there arises a situation wherein there will be inexplicable misplaced proposals. If again in case of TID' < LTID+1, then the supplicant will be caught up with in the Step 4 of the procedure, as the last id issued and used by the supplicant was made public and accessible to all the peers. The value of TID is considered as 0 if a node is for the first time donning the role of a supplicant. 2. The transaction in Step 8 will not be terminated by the supplicant. A supplicant is allowed to abandon the transaction after providing the applicant with the requested requisite information in Step 8 and also can abandon the transaction after Step 9. In both the cases, there is an absence of a proposal by the supplicant for the transaction id TID. The proposal in\par
Step 11 can be liberated by the applicant provided the supplicant fails to verify and sign the blinded proposal, without acquiring the supplicant's signature. In the next transaction, precisely TID+1, the supplicant again fails to illustrate the proposal for that relevant transaction, TID to the transaction's applicant, TID+1 and hence the new applicant entrusts itself with the job of scanning the network making use of Search methodology for TID. In case TID is found, the suggested proposals are also found out pertaining to the suppliant in the transaction. The applicant will then be responsible as the TID would by then have been signed b the supplicant, who will have to acknowledge the proposal as it comprises the signature of the supplicant, TID \& The influence of the conspiracy can be alleviated by classifying proposals on the basis of personage identities, substantiating agencies etc. The list of conspirators can be circulated, thereby, guarding the remaining nodes from an possible attack. Peers when recognized as conspirators will not be permitted to get back into the stream of network and hence they have an impetus next to conspiracy. The series of proposals of the plotters will aid in offering support that few nodes are conspiring, thereby, protecting good nodes and from the intrusion of bad nodes into the network. 4. Multiple requesters and concurrency. A supplicant in the presently used procedure will not be provided with the facility of making use of the same identity in the synchronized communication. The first option for process intensification is that the supplier identifies and familiarizes all its applicants with each other. As a result, the verification process performed in Step 4 is performed amidst a group of applicants and results are arranged in accordance with the fact that TID dissimilarity needs to be initiated due to more number of applicants. After integrating the augments, there would be a bi party procedure that would still be prevalent where the cluster of applicants is considered to the second party while the supplicant is supposed to be the first party. The figure \hyperref[fig_1]{1} explores the ability of the proposed model to prevent the false node reliability submitted by unauthorized nodes that acts as a service request node SRP.\par
We can observe that contract signing by signcryption approach is most effective to prevent the node reliability tampering attacks. Even node communication with contract signing also victimized few times but victimization occurred due to contract signing breakage. Hence if contract sign is alive then attacked to tamper the node reliability is almost null. The figure \hyperref[fig_0]{2} confirms the stable growth in execution time when considers this contract signing process, which was compared with node communication process without contract signing.\par
Hike at node communication execution time that is negligible when consider the improvement in prevention of node reliability tampering attack attempts.  
\section[{Conclusion}]{Conclusion}\par
Here in this paper we proposed a signcryption based contract signing for node communication based on node reliability check. The results are evident that proposed two way node reliability checking model is effective to avoid the node reliability tampering attack efforts. The planned model is screening a little hike in average process time of node communication, which can be negligible in the context of node reliability tampering attack avoidance. In future we plan to find a solution to avoid the contract sign breaching.\begin{figure}[htbp]
\noindent\textbf{2}\includegraphics[]{image-2.png}
\caption{\label{fig_0}2 kPI}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-3.png}
\caption{\label{fig_1}1 kP}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-4.png}
\caption{\label{fig_2}}\end{figure}
    \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.85\textwidth}}
Authorised Secure Host Communication under Data Provenance Verification-A Signcryption Based\\
Contract Signing Protocol\\
victim's network connection (i.e., distributed denial of\\
service attacks).\\
2012\\
Year\\
D D D D ) E\\
(\end{longtable} \par
  {\small\itshape [Note: \hyperref[b11]{[13]}. The replicas are run using a state machine replication algorithm like BFT [14] that can sustain faults like Byzantine. BFT can replicate arbitrary state machines and, therefore, it can look like Pastry's routing table maintenance and forwarding protocols. Here, we look into Reputation Systems for distributed networkshighly useful design which protects the distributed network without a central component, and amplifies all the advantages of the distributed network.III.]} 
\caption{\label{tab_0}}\end{figure}
 			\footnote{© 2012 Global Journals Inc. (US)} 			\footnote{© 2012 Global Journals Inc. (US)Global Journal of Computer Science and Technology} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Saroiu et al. (2002)]{b4}\label{b4} 	 		‘\textbackslash A measurement study of peer-to-peer sharing systems’.  		 			S Saroiu 		,  		 			P K Gummadi 		,  		 			S D Gribble 		.  	 	 		\textit{SPIE Conference on Multimedia Computing and Networking (MMCN)},  				Jan. 2002.  	 
\bibitem[Damiani et al. (2002)]{b6}\label{b6} 	 		‘\textbackslash A reputation-based approach for choosing reliable resources in peer-to-peer networks’.  		 			E Damiani 		,  		 			S De Capitani Di Vimercati 		,  		 			S Paraboschi 		,  		 			P Samarati 		,  		 			F Violante 		.  	 	 		\textit{9th ACM Conference on Computer and Communications Security},  				Nov. 2002.  	 
\bibitem[Ratnasamy et al. (2001)]{b1}\label{b1} 	 		‘\textbackslash A scalable content addressable network’.  		 			S Ratnasamy 		,  		 			P Francis 		,  		 			M Handley 		,  		 			R Karp 		,  		 			S Shenker 		.  	 	 		\textit{ACM SIGCOMM},  				Aug. 2001.  	 
\bibitem[Chu et al. (2002)]{b11}\label{b11} 	 		‘\textbackslash Availability and locality measurements of peer-to-peer le systems’.  		 			J Chu 		,  		 			K Labonte 		,  		 			B N Levine 		.  	 	 		\textit{ITCom: Scalability and Trac Control in IP Networks},  				July 2002. 4868.  	 	 (of Proceedings of SPIE, Proceedings of SPIE) 
\bibitem[Xiong and Liu (2002)]{b9}\label{b9} 	 		‘\textbackslash Building trust in decentralized peer-to-peer communities’.  		 			L Xiong 		,  		 			L Liu 		.  		 \url{http://www.gnucleus.com/}  	 	 		\textit{International Conference on Electronic Commerce Research (ICECR-5)},  				Oct. 2002. 11.  	 	 (\textbackslash Gnucleus home page) 
\bibitem[Stoica et al. (2001)]{b2}\label{b2} 	 		‘\textbackslash Chord: A scalable Peer-To-Peer lookup service for internet applications’.  		 			I Stoica 		,  		 			R Morris 		,  		 			D Karger 		,  		 			F Kaashoek 		,  		 			H Balakrishnan 		.  	 	 		\textit{ACM SIGCOMM},  				Aug. 2001. p. .  	 
\bibitem[Lee et al. (2003)]{b8}\label{b8} 	 		‘\textbackslash Cooperative peer groups in nice’.  		 			S Lee 		,  		 			R Sherwood 		,  		 			B Bhattacharjee 		.  	 	 		\textit{IEEE INFOCOM},  				Apr. 2003.  	 
\bibitem[Adar and Huberman ()]{b3}\label{b3} 	 		‘\textbackslash Free riding on Gnutella’.  		 			E Adar 		,  		 			B A Huberman 		.  	 	 		\textit{Tech. Rep}  		2000.  	 
\bibitem[Aberer and Despotovic (2001)]{b5}\label{b5} 	 		‘\textbackslash Managing trust in a peer-2-peer information system’.  		 			K Aberer 		,  		 			Z Despotovic 		.  	 	 		\textit{Ninth International Conference on Information and Knowledge Management (CIKM)},  				Nov. 2001.  	 
\bibitem[Ripeanu et al. ()]{b0}\label{b0} 	 		‘\textbackslash Mapping the Gnutella network: Properties of large-scale peerto-peer systems and implications for system design’.  		 			M Ripeanu 		,  		 			I Foster 		,  		 			A Iamnitchi 		.  	 	 		\textit{IEEE Internet Computing Journal}  		2002. 6  (1) .  	 
\bibitem[Sripanidkulchai (2001)]{b10}\label{b10} 	 		 			K Sripanidkulchai 		.  		 \url{http://www.openp2p.com/}  		\textit{\textbackslash The popularity of gnutella queries and its implications on scalability},  				Feb. 2001.  	 
\bibitem[Kamvar et al. ()]{b7}\label{b7} 	 		‘Unpublished work’.  		 			S D Kamvar 		,  		 			M Schlosser 		,  		 			H Garcia-Molina 		.  	 	 		\textit{\textbackslash Eigenrep: Reputation management in p2p networks},  				2003.  	 
\end{bibitemlist}
 			 		 	 
\end{document}
