All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Kevin Coffman <kwc@citi.umich.edu>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 06/19] Use get_random_bytes() to create confounder
Date: Wed, 12 Mar 2008 12:50:38 -0500	[thread overview]
Message-ID: <1205344238.11354.59.camel@calx> (raw)
In-Reply-To: <20080312164616.GF10015@fieldses.org>


On Wed, 2008-03-12 at 12:46 -0400, J. Bruce Fields wrote:
> On Thu, Feb 21, 2008 at 01:44:17PM -0500, Kevin Coffman wrote:
> > Instead of using an incementing value for the confounder, use
> > get_random_bytes() which gives us the desired unpredictable value.
> 
> OK, admittedly I was probably nuts to substitute a predictable number
> for a random number in any cryptographic protocol, even if I was pretty
> sure it didn't matter in our case--so thanks for doing this.
> 
> But my impression is that other callers of this function are using it on
> a per-connection basis instead of (as in our case) a per-rpc basis.  Is
> there any problem with calling it that frequently?  Is it fast enough?
> Will it deplete some common entropy pool?

get_random_bytes is in the many megabytes/second range, so it's fast
enough for most things, but considered too slow for per-socket use
(which means the comment above it is quite stale!). If per-rpc means
once per every stat over NFS, then definitely too expensive. It draws
from the non-blocking pool, so no worries about entropy depletion.

Take a look at lib/random32.c for a moderately stong and fast PRND.
Reseeding that periodically with get_random_bytes might be sufficient.
Or look at secure_tcp_sequence_number in random.c for a more ad-hoc
approach.

-- 
Mathematics is the supreme nostalgia of our time.


  reply	other threads:[~2008-03-12 17:50 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-21 18:43 [PATCH 00/19] RFC add kernel support for newer encrytpion types Kevin Coffman
     [not found] ` <20080221184208.19195.94518.stgit-zTNJhAanYLVZN1qrTdtDg5Vzexx5G7lz@public.gmane.org>
2008-02-21 18:43   ` [PATCH 01/19] crypto: Add CTS mode required for Kerberos AES support Kevin Coffman
2008-02-21 18:43   ` [PATCH 02/19] rpc: gss: Add oid values to the gss_api mechanism structures Kevin Coffman
2008-02-21 18:44   ` [PATCH 03/19] sunrpc: make token header values less confusing Kevin Coffman
     [not found]     ` <20080221184402.19195.57873.stgit-zTNJhAanYLVZN1qrTdtDg5Vzexx5G7lz@public.gmane.org>
2008-03-12 16:31       ` J. Bruce Fields
2008-03-12 16:44         ` Kevin Coffman
2008-02-21 18:44   ` [PATCH 04/19] Add new pipefs file indicating which Kerberos enctypes the kernel supports Kevin Coffman
     [not found]     ` <20080221184407.19195.62074.stgit-zTNJhAanYLVZN1qrTdtDg5Vzexx5G7lz@public.gmane.org>
2008-03-12 16:37       ` J. Bruce Fields
2008-02-21 18:44   ` [PATCH 05/19] Correct grammer/typos in dprintks Kevin Coffman
     [not found]     ` <20080221184412.19195.93743.stgit-zTNJhAanYLVZN1qrTdtDg5Vzexx5G7lz@public.gmane.org>
2008-03-12 16:38       ` J. Bruce Fields
2008-02-21 18:44   ` [PATCH 06/19] Use get_random_bytes() to create confounder Kevin Coffman
     [not found]     ` <20080221184417.19195.55123.stgit-zTNJhAanYLVZN1qrTdtDg5Vzexx5G7lz@public.gmane.org>
2008-03-12 16:46       ` J. Bruce Fields
2008-03-12 17:50         ` Matt Mackall [this message]
2008-03-12 18:03           ` J. Bruce Fields
2008-03-12 18:37             ` Kevin Coffman
     [not found]               ` <4d569c330803121137w755c5c76j4b692aac53d54619-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-03-12 18:39                 ` J. Bruce Fields
2008-03-12 18:53                   ` Matt Mackall
2008-02-21 18:44   ` [PATCH 07/19] Don't expect blocksize to always be 8 when calculating padding Kevin Coffman
2008-02-21 18:44   ` [PATCH 08/19] Remove define for KRB5_CKSUM_LENGTH, which will become enctype-dependent Kevin Coffman
     [not found]     ` <20080221184427.19195.16243.stgit-zTNJhAanYLVZN1qrTdtDg5Vzexx5G7lz@public.gmane.org>
2008-03-12 18:54       ` J. Bruce Fields
2008-02-21 18:44   ` [PATCH 09/19] gss_krb5: split up functions in preparation of adding new enctypes Kevin Coffman
2008-02-21 18:44   ` [PATCH 10/19] gss_krb5: prepare for new context format Kevin Coffman
2008-02-21 18:44   ` [PATCH 11/19] gss_krb5: introduce encryption type framework Kevin Coffman
2008-02-21 18:44   ` [PATCH 12/19] gss_krb5: add ability to have a keyed checksum (hmac) Kevin Coffman
2008-02-21 18:44   ` [PATCH 13/19] gss_krb5: import functionality to derive keys into the kernel Kevin Coffman
2008-02-21 18:44   ` [PATCH 14/19] gss_krb5: use a global static OID value for krb5 Kevin Coffman
2008-02-21 18:45   ` [PATCH 15/19] gss_krb5: handle new context format from gssd Kevin Coffman
2008-02-21 18:45   ` [PATCH 16/19] gss_krb5: add support for triple-des encryption Kevin Coffman
2008-02-21 18:45   ` [PATCH 17/19] xdr: add a new utility function to shift the head data of an xdr buffer Kevin Coffman
2008-02-21 18:45   ` [PATCH 18/19] gss_krb5: add support for new token formats in rfc4121 Kevin Coffman
2008-02-21 18:45   ` [PATCH 19/19] gss_krb5: add remaining pieces to enable AES encryption support Kevin Coffman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1205344238.11354.59.camel@calx \
    --to=mpm-vdjraj4gl5zbdgjk7y7tuq@public.gmane.org \
    --cc=bfields@fieldses.org \
    --cc=kwc@citi.umich.edu \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.