headers
Vishal Gupta | 11 Apr 2005 22:44
Picon
Favicon

New to this mailing list

Hi,
    A very good morning to all members. My name is Vishal Gupta. I'm an Indian & I aspire to someday provide for a secure internet for all. I'm a BSC graduate in IT. I have also done MCP along with CCNA. As such I have a bit of experience in the network field but i'm quite new to most technical terminologies I got to read on the IETF & RFC websites. Well you'll must be thinking what a novice like me is doing on a professional mailing list. So here's why :
 While doing my graduation course when i was learning all kinds of various languages apart from other stuff I realised how unsecure the web was. Actually i'm sure a very few people know about this. Well the point is I started doing my R & D on my computer & find that first of all I can change my identity on the internet. By identity i mean the IP as well as the MAC address of my system. So i can do anything on the web without anyone else knowing i did it. I also know that the system keeps quite a record of where we go & what we do on the internet. But there is a pretty simple workaround to that. There are plenty of softwares available on the internet that help us accomplish just that. In my case i prefer doing that manually. That way I know what's where. Well I dont know if any of you noticed this or not but the softwares that ar e available on the internet let them be firewalls or antivirus softwares all of them just! protect individual systems & not the information that's going out from the system.
    So the above two things combined I have a cracker who has access to the "NETWORK" spying on whatever i do. Come to think of it isnt the vulnerability built into our system so that it can be cracked??
   For a week i struggled on this one but finally i seem to have a few points that could be considered to improve security :
1> What if no one couldnt configure a ip address or a mac address on his/her system. Thinking logically no one actually needs to do that. All we require is a DHCP server to be mandatory on all netwoks. This will do two things (1) No one can forge his/her identity on the network. (2) No one can use any kind of mitm attacks to forge network configs.
2> The TCP/IP protocol needs to be redone completely. It's just to slow for today's networks & not much security either. I thought alot about this also & here's what I have :
   What we are aiming at is security on the network & not on the system alone so we obviiously need to encrypt the data that we send at all times. It does get encrypted but people are able to break that encryption too. A workaround for this could be if we were to use a random encryption which would be decided upon in the first handshake. Also along with this we need to reduce the amount of overhead TCP/IP causes on the network possibly something like a byte value where the first bit would say what encryption to use, the second would say if the data is compressed or not & so on. Just one or two bytes do the job for which TCP/IP takes a multiple of 32 bytes. Well you might say its a processing overhead for a PC but with the kind of systems available today that should not be a problem.
 
Well this is my first venture into a technical mailing list in a true sense. Please write to me any suggestions/comments that you may have for me.
 
Thanks

Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! 
<div>
<div>
<div>Hi,</div>
<div>&nbsp;&nbsp;&nbsp; A very good morning to all members. My name is Vishal Gupta. I'm an Indian &amp; I aspire to&nbsp;someday provide for&nbsp;a secure internet for all. I'm a BSC graduate in IT. I have also done MCP along with CCNA. As such I have a bit of experience in the network field but i'm quite new to most technical terminologies I got to read on the IETF &amp; RFC websites. Well you'll must be thinking what a novice like me is doing on a professional mailing list. So here's why :</div>
<div>&nbsp;While doing my graduation course when i was learning all kinds of various languages apart from other stuff I&nbsp;realised how unsecure the web was. Actually i'm&nbsp;sure a very few people&nbsp;know about this. Well the point is I started doing my R &amp; D on&nbsp;my computer &amp; find that first of all I can change my identity on the internet. By identity i mean the IP as well as the MAC address of my system. So i can do anything on the web without anyone else knowing i did it. I also know that the system keeps quite a record of where we go &amp; what we do on the internet. But there is a pretty simple workaround to that. There are plenty of softwares available on the internet that help us accomplish just that. In my case i prefer doing that manually. That way I know what's where. Well I dont know if any of you noticed this or not but the softwares that ar
 e available on the internet let them be firewalls or antivirus softwares all of them just!
  protect
 individual systems &amp; not the information that's going out from the system.</div>
<div>&nbsp;&nbsp;&nbsp; So the above two things combined I have a cracker who has access to the "NETWORK" spying on whatever i do. Come to think of it isnt the vulnerability built into our system so that it can be cracked??</div>
<div>&nbsp;&nbsp; For a week i struggled on this one but finally i seem to have a few points that could be considered to improve security :</div>
<div>1&gt; What if no one couldnt configure a ip address or a mac address on his/her system. Thinking logically no one actually needs to do that. All we require is a DHCP server to be mandatory on all netwoks. This will do two things (1) No one can forge his/her identity on the network. (2) No one can use any kind of mitm attacks to forge&nbsp;network configs.</div>
<div>2&gt; The TCP/IP protocol needs to be redone completely. It's just to slow for today's networks &amp; not much security either. I thought alot about this also &amp; here's what I have :</div>
<div>&nbsp;&nbsp; What we are aiming at is security on the network &amp; not on the system alone so we obviiously need to encrypt the data that we send at all times. It does get encrypted but people are able to break that encryption too. A workaround for this could be if we were to use a random encryption which would be decided upon in the first handshake. Also along with this we need to reduce the amount of overhead TCP/IP causes on the network possibly something like a byte value where the first bit would say what encryption to use, the second would say if the data is compressed or not &amp; so on. Just one or two bytes do the job for which TCP/IP takes a multiple of 32 bytes. Well you might say its a processing overhead for a PC but with the kind of systems available today that should not be a problem.</div>
<div>&nbsp;</div>
<div>Well this is my first venture into a technical mailing list in&nbsp;a true sense. Please write to me any suggestions/comments that you may have for me.</div>
<div>&nbsp;</div>
<div>Thanks</div>
</div>
<p>
		</p>Do you Yahoo!?<br> 
Yahoo! Small Business - <a href="http://us.rd.yahoo.com/evt=31637/*http://smallbusiness.yahoo.com/resources/">Try our new resources site!</a>
</div>
Permalink | Reply | 0 comments |
headers
Brian Weis | 16 Apr 2005 02:17
Picon
Favicon

RSA Signature padding recommendations

When an RSA signature is created, the signature algorithm input 
encapsulates the hash output with a padding method. RFC 3447 (PKCS #1 
v2.1) specifies two methods of padding: EMSA-PKCS1-v1_5 and EMSA-PSS. 
EMSA-PKCS1-v1_5 is the traditional method of padding, but since attacks 
have been found on that method PSS was added to PKCS#1 v2.1.

Due to its improved security properties, new protocols using RSA 
signatures are being given the advice to adopt PSS as a MUST. However, 
there are some complications with using PSS.

1. The base PSS specification has intellectual property claimed on it. 
Whether or not the construction of PSS specified in RFC 3447 is covered 
is not clear. (No IPR disclosure has been filed with the IETF. However, 
the only publicly available statement regarding licensing its use 
applies to IEEE P1363, not the IETF.)

2. Commonly used crypto toolkits and RSA hardware accelerators that I 
have investigated do not typically support PSS padding.

So while PSS padding is a better security method, specifying it as a 
required method will likely not result in those standards being adopted 
until these issues are sorted out.

RFC 3447 suggests that no known attacks are known against the 
EMSA-PKCS-v1_5 encoding method, yet "a gradual transition to EMSA-PSS is 
recommended as a precaution against future developments". It doesn't 
seem to me as if such a transition is yet possible, but I'd be 
interested in other hearing other opinions.

Thanks,
Brian

--

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew <at> cisco.com
Permalink | Reply | 0 comments |
headers
Paul Hoffman | 19 Apr 2005 18:32

Re: Attacks on Cryptographic Hashes in Internet Protocols

Greetings again. Bruce Schneier and I have updated our draft on the 
status of hashes in protocols based on the recent attacks. The -02 
version can be found at 
<http://www.ietf.org/internet-drafts/draft-hoffman-hash-attacks-02.txt>. 
(The -01 draft had a bad typo in it and was quickly replaced...)

We definitely appreciate the comments we received on the -00, and we 
continue to welcome comments on the draft.

--Paul Hoffman, Director
--VPN Consortium
Permalink | Reply | 0 comments |
headers
Vishal Gupta | 20 Apr 2005 19:23
Picon
Favicon

Re: saag Digest, Vol 27, Issue 3 - probable solution

Hi,
   I read with great admiration of how quickly things
are worked out and put into place. Most of us dont
even know what goes on behind the scenes.
   Till date what has been happening is that the
complexity of the algos/hashes has increased but the
implementation remains the same. So its actually just
a matter of how much time a person has before he will
give up on trying to break it. Eventually it will
break. That is actually the moral of the story that
its time that we change the way these algos or hashes
are implemented in protocols. What i mean to say is
that probably we could use a random hash/algo which
only the source & destination would know about. Here
the algo/hash traits would be stored on the local
computers in an encrypted format using a "user
unknown" or in other words "undocumented" hash/algo.
The user actually doesnt need to know about this & nor
does anyone else. Actually even if talk of a
programmer he too needs to be concerned about the
functions in the protocols & not how they are being
implemented by the functions. The fact is not even we
will be able to tell which one is being used here.
Also in this there will be a fixed order in which
these algos will be stored & only the order will be
sent over the internet & the processing & unencrypting
part of it will be left to the destination computer.
As it is today the average processing power of the
computer is sufficient & that should not be a problem.
    Please do provide me with any comments or feedback
regarding this.

Thank You

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com
Permalink | Reply | 1 comment |
headers
Sam Hartman | 24 Apr 2005 17:32
Picon
Favicon

Re: Re: saag Digest, Vol 27, Issue 3 - probable solution

>>>>> "Vishal" == Vishal Gupta <genious_2k1 <at> yahoo.co.in> writes:

    Vishal> Hi, I read with great admiration of how quickly things are
    Vishal> worked out and put into place. Most of us dont even know
    Vishal> what goes on behind the scenes.  Till date what has been
    Vishal> happening is that the complexity of the algos/hashes has
    Vishal> increased but the implementation remains the same. So its
    Vishal> actually just a matter of how much time a person has
    Vishal> before he will give up on trying to break it. Eventually
    Vishal> it will break. That is actually the moral of the story
    Vishal> that its time that we change the way these algos or hashes
    Vishal> are implemented in protocols. What i mean to say is that
    Vishal> probably we could use a random hash/algo which only the
    Vishal> source & destination would know about. Here the algo/hash
    Vishal> traits would be stored on the local computers in an
    Vishal> encrypted format using a "user unknown" or in other words
    Vishal> "undocumented" hash/algo.  The user actually doesnt need
    Vishal> to know about this & nor does anyone else. 

The security community has a strong and justified bias against closed
or undisclosed algorithms.  The problem is that without being subject
to cryptanalysis in the public community we do not know whether the
algorithm is strong enough.

Trying all the algorithms available only increases the work factor by
the number of algorithms.  If you have 5, that's only 5 times harder,
which isn't much.  If you have 2^128 algorithms to choose from, that's
interesting.  However you don't have code space for 2^128 unrelated
algorithms.

One thing you can do which makes excellent cryptographic sense is to
choose from a family of hash functions paramaterized on some random
variable.  This is similar to what people have been talking about when
they say randomized hashing.  Depending on what you can prove about
the particular strategy you are using to randomize a normal hash
function and about the hash function that is being randomized, they
may end up being the same.

--Sam
Permalink | Reply | 0 comments |
headers
Jeff Williams | 26 Apr 2005 07:03
Picon

From: NIST SP 800-53 Errata Sheet (through 04/22/05)

All,

 The following may be of interest to some of you:

 *** The following message is from the NIST FISMA Implementation Project
***

Subject: NIST SP 800-53 Errata Sheet (through 04/22/2005)

A listing of minor changes to NIST Special Publication 800-53,
Recommended
Security Controls for Federal Information Systems, February 2005
(including
updates through 04-22-2005) is now available at the Computer Security
Division website, http://csrc.nist.gov/publications/ . From this site,
go
to Special Publications and then to 800-53.  The errata sheet is on page
v
of SP 800-53 noting the changes incorporated into the document.  The
majority of the changes to NIST SP 800-53 in this errata sheet are
updates
to Appendix G, Security Control Mapping Table for Special Publication
800-26, Security Self-Assessment Guide for Information Technology
Systems.

As we move towards the implementation of FIPS 200, we may periodically
make
minor changes to the NIST Special Publication 800-53, Recommended
Security
Controls for Federal Information Systems. Any changes will be documented
in
an updated errata sheet and an announcement will be posted to this
mailing
list as well as to the website, http://csrc.nist.gov/sec-cert .

Arnold Johnson for Ron Ross
FISMA Implementation Project

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 <at> ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827
Permalink | Reply | 0 comments |
headers
Tim Polk | 28 Apr 2005 23:26
Favicon

Fwd: Cryptographic Hash Workshop - Call for Participation


Folks,

Based on the traffic on this list over the last two months, I believe this announcement will be of some interest...

NIST has just announced a Cryptographic Hash Workshop this Fall.  This workshop will address a broad range of technical and policy issues ranging from attacks on the NIST approved algorithms to migration strategies.  We will look to the results of this workshop to establish direction for future NIST hash initiatives.  For details, please see Shu-jen Chang's email, below, and the attached call for participation.

I hope that many of you will participate, so that the needs of current and future Internet protocols are adequately represented in this process!

Thanks,

Tim Polk

X-Sieve: CMU Sieve 2.2
X-Sender: sjchang <at> email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Thu, 28 Apr 2005 13:54:13 -0400
To: shu-jen.chang <at> nist.gov
From: Shu-jen Chang <shu-jen.chang <at> nist.gov>
Subject: Cryptographic Hash Workshop - Call for Participation
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: shu-jen.chang <at> nist.gov

Cryptographic Hash Workshop
NIST Gaithersburg, MD (Green Auditorium)
Oct. 31-Nov. 1, 2005
Submission Deadline: July 15, 2005 (Workshop without Proceedings)

Recently a team of researchers reported that the SHA-1 function offers significantly less collision resistance than could be expected from a cryptographic hash function of its output size.  NIST plans to host a Cryptographic Hash Workshop on Oct. 31-Nov. 1, 2005 to solicit public input in how best to respond to the current state of research in this area.  The workshop has the following goals:

·       Assess the status of the current NIST-approved hash functions, i.e., the SHA-256 and SHA-512 families in        addition to SHA-1;
·       Discuss short term actions to mitigate the potential problems with the various applications of the approved     hash functions;
·       Discuss the conditions that would warrant an early transition away from any of the approved hash functions;
·       Discuss the potential replacement options for any of the approved hash functions;
·       Clarify the properties of unkeyed cryptographic hash functions required for different applications such as      digital signatures, key derivation, message authentication, and random number generation.

NIST solicits papers, presentations, case studies, panel proposals, and participation from any interested parties, including researchers, systems architects, vendors, and users.  NIST will post the accepted papers and presentations on the workshop web site and include these in a workshop handout. However, no formal workshop proceedings will be published. NIST encourages presentations and reports on preliminary work that participants plan to publish elsewhere. Topics for submissions are included in the attached document, and details about the workshop will be available at the following web site shortly: http://www.nist.gov/hash-function


Shu-jen Chang
Computer Security Division
NIST
Attachment (Cryptographic Hash Workshop CFP.pdf): application/pdf, 30 KiB
<div>
<br>
Folks,<br><br>
Based on the traffic on this list over the last two months, I believe
this announcement will be of some interest...<br><br>
NIST has just announced a Cryptographic Hash Workshop this Fall.&nbsp;
This workshop will address a broad range of technical and policy issues
ranging from attacks on the NIST approved algorithms to migration
strategies.&nbsp; We will look to the results of this workshop to
establish direction for future NIST hash initiatives.&nbsp; For details,
please see Shu-jen Chang's email, below, and the attached call for
participation.<br><br>
I hope that many of you will participate, so that the needs of current
and future Internet protocols are adequately represented in this
process!<br><br>
Thanks,<br><br>
Tim Polk<br><br><blockquote type="cite" class="cite" cite>X-Sieve: CMU Sieve 2.2<br>
X-Sender: sjchang <at> email.nist.gov<br>
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1<br>
Date: Thu, 28 Apr 2005 13:54:13 -0400<br>
To: shu-jen.chang <at> nist.gov<br>
From: Shu-jen Chang &lt;shu-jen.chang <at> nist.gov&gt;<br>
Subject: Cryptographic Hash Workshop - Call for Participation<br>
X-NIST-MailScanner: Found to be clean<br>
X-MailScanner-From: shu-jen.chang <at> nist.gov<br><br>Cryptographic Hash
Workshop<br>
NIST Gaithersburg, MD (Green Auditorium)<br>
Oct. 31-Nov. 1, 2005<br>Submission Deadline:
July
15, 2005 (Workshop without Proceedings)<br><br>Recently a team of
researchers reported that the SHA-1 function offers significantly less
collision resistance than could be expected from a cryptographic hash
function of its output size.&nbsp; NIST plans to host a Cryptographic
Hash Workshop on Oct. 31-Nov. 1, 2005 to solicit public input in how best
to respond to the current state of research in this area.&nbsp; The
workshop has the following goals:<br><br>&middot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Assess
the status of the current NIST-approved hash functions, i.e., the SHA-256
and SHA-512 families in
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;addition to
SHA-1;<br>&middot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Discuss
short term actions to mitigate the potential problems with the various
applications of the approved &nbsp;&nbsp;&nbsp;&nbsp;hash
functions;<br>&middot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Discuss
the conditions that would warrant an early transition away from any of
the approved hash functions;<br>&middot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Discuss
the potential replacement options for any of the approved hash
functions;<br>&middot;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Clarify
the properties of unkeyed cryptographic hash functions required for
different applications such as
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;digital signatures, key
derivation, message authentication, and random number
generation.<br><br>
NIST solicits papers, presentations, case studies, panel proposals, and
participation from any interested parties, including researchers, systems
architects, vendors, and users.&nbsp; NIST will post the accepted papers
and presentations on the workshop web site and include these in a
workshop handout. However, no formal workshop proceedings will be
published. NIST encourages presentations and reports on preliminary work
that participants plan to publish elsewhere. Topics for submissions are
included in the attached document, and details about the workshop will be
available at the following web site shortly:
<a href="http://www.nist.gov/hash-function" eudora="autourl">http://www.nist.gov/hash-function</a><br><br><br>Shu-jen Chang<br>
Computer Security Division<br>
NIST<br>
</blockquote>
</div>
Permalink | Reply | 0 comments |

Gmane