Below is a patch to update the broken web addresses, in crypto/*
that I could locate. Some are just simple typos that needed to be
fixed, and some had a change in location altogether..
let me know if any of them need to be changed and such.
Signed-off-by: Justin P. Mattock
---
crypto/Kconfig |
On Mon, Sep 6, 2010 at 17:11, Nikos Mavrogiannopoulos
wrote:
> I suppose you mean the reference to the internal representation of the
> key. This might be valid for few seconds until the required operation is
> over.
>
> This is not really what I would call storage. The storage and retrieval
> of
Nikos Mavrogiannopoulos wrote:
> Hello,
> I was checking the crypto_xor() function and it is for some reason
> limited to 32 bit integers. Why not make it depend on the architecture
> by replacing the u32 with unsigned long? That way 64bit machines should
> perform xor with less instructions...
W
- "Kyle Moffett" wrote:
> On Mon, Sep 6, 2010 at 11:50, Miloslav Trmac wrote:
> > - "Herbert Xu" wrote:
> >> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
> >> > I have seriously considered the keyring API, and this is what I
> came
> >> up with - but I'd love to be sho
On 09/06/2010 10:42 PM, Kyle Moffett wrote:
>>> The problem with the approach you're proposing is that we then have
>>> two entirely separate classes of keys. First we have the existing
>>> keyring class, which can be securely and revokably passed between
>>> different processes with limited righ
On Mon, Sep 6, 2010 at 15:13, Nikos Mavrogiannopoulos
wrote:
> On 09/06/2010 08:00 PM, Kyle Moffett wrote:
>>> The kernel keyring service is basically a system-wide data storage
>>> service. /dev/crypto needs a quick way to refer to short-lived,
>>> usually process-local, kernel-space data struct
On 09/06/2010 08:00 PM, Kyle Moffett wrote:
>> The kernel keyring service is basically a system-wide data storage
>> service. /dev/crypto needs a quick way to refer to short-lived,
>> usually process-local, kernel-space data structures from
>> userspace.
> The problem with the approach you're pro
On Mon, Sep 6, 2010 at 11:50, Miloslav Trmac wrote:
> - "Herbert Xu" wrote:
>> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
>> > I have seriously considered the keyring API, and this is what I came
>> up with - but I'd love to be shown a better way.
>>
>> FWIW adding a seco
- "Herbert Xu" wrote:
> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
> >
> > I can see almost no overlap between the two sets of requirements.
> Probably the only common use case is handling session keys (e.g. keys
> used in a kerberos ticket), which should be stored in the
help
--
JFCh
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/06/2010 02:17 PM, Herbert Xu wrote:
> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
>>
>> I can see almost no overlap between the two sets of requirements. Probably
>> the only common use case is handling session keys (e.g. keys used in a
>> kerberos ticket), which should
On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
>
> I can see almost no overlap between the two sets of requirements. Probably
> the only common use case is handling session keys (e.g. keys used in a
> kerberos ticket), which should be stored in the kernel for the duration of
>
12 matches
Mail list logo
