CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: ajacou...@cvs.openbsd.org 2012/06/29 22:16:06 Modified files: openbgpd/ru: ftp.html goals.html index.html manual.html papers.html users.html opencvs/ru : goals.html index.html manual.html press.html openntpd/ru: goals.html index.html manual.html papers.html portable.html openssh/ru : features.html ftp.html goals.html history.html index.html java.html list.html macos.html manual.html openbsd.html palmos.html portable.html report.html security.html tshirts.html unix.html users.html windows.html ru : anoncvs.html crypto.html ftp.html goals.html hackathons.html index.html mac68k.html mail.html plat.html porting.html report.html security.html smp.html stable.html why-cvs.html Log message: Sync with Steelix CVS
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: mi...@cvs.openbsd.org 2012/06/29 18:16:15 Modified files: sys/net: if_pfsync.c Log message: Fix a number of problems introduced by the link state handling commit: 1) demote by 32 on the first bulk update to prevent failovers w/o having a full state table; 2) don't do any demotion adjustments on the link up event and undemote when bulk update finishes (or times out) preventing a race between nodes getting a link state update asynchronously. With phessler; tested by phessler and Kapetanakis Giannis. Thanks! Looked through by henning and dlg. Now the correct version.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: mi...@cvs.openbsd.org 2012/06/29 18:14:23 Modified files: sys/net: if_pfsync.c Log message: backout rev1.185 as it's not what i have intended to commit
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: jmatt...@cvs.openbsd.org2012/06/29 16:21:40 Modified files: sys/dev/pci: ahci.c Log message: fix obvious panic on resume with AHCI_DEBUG enabled ok dlg@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: jas...@cvs.openbsd.org 2012/06/29 09:17:32 Modified files: sys/dev/pci: ichiic.c Log message: match on the 7SERIES_SMB reminded by jsg@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: mi...@cvs.openbsd.org 2012/06/29 09:12:21 Modified files: sys/net: if_pfsync.c if_pfsync.h Log message: add ESN-related bits missed in the previous commit
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: mi...@cvs.openbsd.org 2012/06/29 09:05:49 Modified files: sbin/iked : iked.h ikev2.c ikev2.h parse.y pfkey.c Log message: Add missing ESN bits
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: mi...@cvs.openbsd.org 2012/06/29 09:01:07 Modified files: sbin/ipsecctl : ipsecctl.c ipsecctl.h pfkdump.c Log message: Print esn flag when dumping SAs with ESN enabled
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: mi...@cvs.openbsd.org 2012/06/29 08:48:04 Modified files: sys/crypto : cryptodev.h cryptosoft.c sys/net: if_pfsync.h pfkeyv2.h pfkeyv2_convert.c pfkeyv2_parsemessage.c sys/netinet: ip_ah.c ip_esp.c ip_ipsp.h Log message: Add support for the Extended (64-bit) Sequence Number as defined in RFC4302 and RFC4303. Right now only software crypto engine is capable of doing it. Replay check was rewritten to implement algorithm described in the Appendix A of RFC4303 and the window size was increased to 64. Tested against OpenBSD, Linux (strongswan) and Windows. No objection from the usual suspects.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: jas...@cvs.openbsd.org 2012/06/29 08:38:00 Modified files: sys/dev/pci: pcidevs.h pcidevs_data.h Log message: regen
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: jas...@cvs.openbsd.org 2012/06/29 08:37:19 Modified files: sys/dev/pci: pcidevs Log message: add a bunch of intel 7 series id's for devices found in the thinkpad x230 ok kettenis@
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: ajacou...@cvs.openbsd.org 2012/06/29 08:35:07 Modified files: de : sgi.html faq/de : faq14.html faq/nl : faq14.html openntpd/ru: ftp.html Log message: Sync with Steelix CVS
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: na...@cvs.openbsd.org 2012/06/29 07:57:25 Modified files: usr.bin/ssh: ssh_config.5 sshd_config.5 Log message: match the documented MAC order of preference to the actual one; ok dtucker@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org2012/06/29 06:56:21 Modified files: share/man/man5 : pf.conf.5 Log message: tcp/udp mandatory for "user"; from ti zed ok henning
Re: CVS: cvs.openbsd.org: src
Ted Unangst wrote: > > Using the names hmac-sha2-256-96 and hmac-sha2-512-96 is a violation of > > the spec since that namespace is managed by IANA. They could be > > implemented as vendor extensions (hmac-sha2-256...@openssh.com and > > hmac-sha2-512...@openssh.com). > > Any reason to do so? Are the truncated hashes particularly > beneficial? Probably not. You may remember from a number of releases back that we used to support HMAC-SHA2-256-96 in IPsec after an early draft, but had to change this to HMAC-SHA2-256-128 to comply with RFC4868 when people belatedly remembered that the HMAC result shouldn't be truncated further than half the length of the hash output, as per RFC2104. Now, that is 15-year-old advice. In his 2011 overview, http://www.cs.ucdavis.edu/~rogaway/papers/modes.pdf Rogaway writes: 9.7. Truncation. HMAC truncated to t bits is, inevitably, subject to an attack that forges with probability q_v/2^t in q_v verification attempts; as a consequence, the parameter t should, in most cases, be kept fairly large. Why, then, truncate at all? One reason for allowing MAC truncation is the obvious one, to lessen bandwidth or storage costs. More interestingly, truncation appears to make the birthday attack less effective, because internal collisions can no longer be identified by collisions in the HMAC outputs. A little truncation may thus improve security. We emphasize, however, that while there are proofs that truncation will not degrade security by more than the addition of the term that we just mentioned, there is no known proof that truncation can improve security--not even in the random-oracle model. We suspect, however, that this is more indicative of technical difficulties in the proof--or the lack of a really serious effort--than the absence of a quantifiable improvement. We emphasize that the concrete security loss from truncation is "only" the q_v/2^t term that one "must" be for truncation; we are not speaking of the more severe drop in security as one sees when truncating tags with GMAC (10.6) or GCM (12.6). -- Christian "naddy" Weisgerber na...@mips.inka.de
