These keys can be used in the same way as normal PGP keys - to sign, verify,
encrypt and decrypt files and data.
% cp configure a
% sudo netpgp --ssh-keys --sign --userid 1e00404a a
Password:
pub 1024/RSA (Encrypt or Sign) 040180871e00404a 2008-08-11
Key fingerprint: c4aa b385 4796 e6ce 606c f0c2 0401 8087 1e00 404a
% sudo chmod 644 a.gpg
% netpgp --ssh-keys --verify a.gpg
netpgp: default key set to "C0596823"
can't open '/etc/ssh/ssh_host_rsa_key'
Good signature for a.gpg made Fri Dec 4 23:04:36 2009
using RSA (Encrypt or Sign) key 040180871e00404a
pub 1024/RSA (Encrypt or Sign) 040180871e00404a 2008-08-11
Key fingerprint: c4aa b385 4796 e6ce 606c f0c2 0401 8087 1e00 404a
uid osx-vm1.crowthorne.alistaircrooks.co.uk (/etc/ssh/ssh_host_rsa_key.pub) <root@osx-vm1.crowthorne.alistaircrooks.co.uk>
% uname -a
NetBSD osx-vm1.crowthorne.alistaircrooks.co.uk 5.99.20 NetBSD 5.99.20 (ISCSI) #0: Wed Oct 7 17:16:33 PDT 2009 agc@osx-vm1.crowthorne.alistaircrooks.co.uk:/usr/obj/i386/usr/src/sys/arch/i386/compile/ISCSI i386
%
The ssh host keys do not need to be manipulated in any way - the information
is read from existing files.
racoon uses a wrong IPsec-SA handle that is for other peer in case it
receives a ISAKMP message for IPsec-SA that has the same message-id as
the message-id that is received before.
racoon uses message-id to find the handle of IPsec-SA. The message-id
is a unique number for each peer, but different peers may use the same
value.
Different Windows Vista or Windows 7 peers seem to use the same
message-id. racoon can handle the first Windows's Phase-2, but it
cannot handle the second Windows. Because racoon misunderstands the
message for the second Windows as the message for the first Windows.
>Category: bin
>Synopsis: racoon uses a wrong IPsec-SA that is for different peer
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Nov 22 18:25:00 +0000 2009
>Originator: yasuoka@iij.ad.jp
the write function stack for the body of the message as well as the
headers.
This means that an ascii-armoured signed file created by netpgp conforms
to RFC 4880 (and 2440, thanks, moof[1]), and can be verified by gpg now, as
well as netpgp.
[1] Are there any other RFCs which are superceded by their double?
+ add a netpgp library function - netpgp_get_key(3) - to print a
specific key
+ add functionality to call this function in netpgpkeys(1)
+ add test for netpgp_get_key
+ add a verbose switch to the tst script
+ add netpgp functions to expose the memory signing and verification
functions - netpgp_sign_memory(3) and netpgp_verify_memory(3)
+ coalesced signing and verification ops file functions
Revamp hash initialisation to return a success/failure error code.
Document places where we prefer to continue with a NULL buffer,
rather than silently continue with possibly erroneous results.
