[EMAIL PROTECTED] wrote:
> On Mon, May 21, 2007 at 04:32:10PM -0400, Victor Duchovni wrote:
>> On Mon, May 21, 2007 at 02:44:28PM -0400, Perry E. Metzger wrote:
>>> My take: clearly, 1024 bits is no longer sufficient for RSA use for
>>> high value applications, though this has been on the horizon f
[EMAIL PROTECTED] wrote:
Why bother with all this? There is OTP for gaim, and it works just fine
(not to mention it comes from a definitely clueful source).
/ji
I meant, of course, OTR (off-the-record). And to think that I was using
it in another window as I was typing this!
Thanks to
On Tue, Oct 09, 2007 at 06:08:44PM +1300, Peter Gutmann wrote:
> how do you want access to the keys controlled? ACLs? Who sets the ACLs? Who
> can manage them? How are permissions managed? What's the UI for this? Under
> what conditions is sharing allowed? If sharing is allowed, how do you h
On Mon, May 21, 2007 at 04:32:10PM -0400, Victor Duchovni wrote:
> On Mon, May 21, 2007 at 02:44:28PM -0400, Perry E. Metzger wrote:
> > My take: clearly, 1024 bits is no longer sufficient for RSA use for
> > high value applications, though this has been on the horizon for some
> > time. Presumably
At 10:55 PM +0200 10/8/07, Ian G wrote:
A slightly off-topic question: if we accept that current processes
(FIPS-140, CC, etc) are inadequate indicators of quality for OSS
products, is there something that can be done about it?
Highly doubtful. The institutional inertia at DoD/NIST is too gre
> Out of curiousity, Vista (BitLocker) was not mentioned?
BitLocker lacks centralized management, and has very limited key
recovery capability. Also it is limited to Vista Business or Ultimate
Edition.
BitLocker, if you are not using a external USB device to store the
key, falls back to volume le
[EMAIL PROTECTED] writes:
>On Mon, May 21, 2007 at 01:44:23PM +1200, Peter Gutmann wrote:
>> >Ignoring special-purpose hardware, does anyone have thoughts on what the
>> >requirements for a kernel-level key management subsystem should be?
>>
>> Yes, but first you'd have to tell me what you're tryin
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Leichter, Jerry
> Sent: Monday, October 08, 2007 11:48 AM
> To: Alex Pankratov
> Cc: cryptography@metzdowd.com
> Subject: RE: Trillian Secure IM
>
> | > But, opportunistic cryptography is even more
> -Original Message-
> From: pgut001 [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 08, 2007 7:52 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: cryptography@metzdowd.com
> Subject: Re: Trillian Secure IM
>
> Marcos el Ruptor <[EMAIL PROTECTED]> writes:
>
> >I found those thre
Marcos el Ruptor <[EMAIL PROTECTED]> writes:
>I found those threads:
>
>http://forums.ceruleanstudios.com/showthread.php?t=53433
>
>http://forums.ceruleanstudios.com/showthread.php?t=56207
One of them contains a link to an older thread:
http://www.ceruleanstudios.com/forums/showthread.php?s=&thr
On Oct 8, 2007, at 4:27 AM, Steven M. Bellovin wrote:
On Mon, 18 Jun 2007 22:57:36 -0700
"Ali, Saqib" <[EMAIL PROTECTED]> wrote:
US Government has select 9 security vendors that will product drive
and file level encryption software.
See:
http://security-basics.blogspot.com/2007/06/fde-fde-so
Stephan Somogyi <[EMAIL PROTECTED]> writes:
>FIPS 140(-2) is about validating cryptographic implementations. It is not
>about certifying entire products that contain ample functionality well
>outside the scope of cryptographic evaluation. That's more of a Common
>Criteria thing.
Not necessarily.
Ian G <[EMAIL PROTECTED]> writes:
>Peter Gutmann wrote:
>> "Alex Pankratov" <[EMAIL PROTECTED]> writes:
>>> SecureIM handshake between two version 3.1 (latest) clients takes about ..
>>> 48
>>> bytes. That's altogether, 32 bytes in one direction, and 16 in another. And
>>> that's between the clien
| A slightly off-topic question: if we accept that current processes
| (FIPS-140, CC, etc) are inadequate indicators of quality for OSS
| products, is there something that can be done about it? Is there a
| reasonable criteria / process that can be built that is more suitable?
Well, if you believ
On Mon, May 21, 2007 at 01:44:23PM +1200, Peter Gutmann wrote:
> >Ignoring special-purpose hardware, does anyone have thoughts on what the
> >requirements for a kernel-level key management subsystem should be?
>
> Yes, but first you'd have to tell me what you're trying to do.
Protect keys in kern
Why bother with all this? There is OTP for gaim, and it works just fine
(not to mention it comes from a definitely clueful source).
/ji
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMA
On 8 Oct 2007 10:12:58 -0700, Stephan Somogyi wrote:
> At 02:11 +1300 09.10.2007, Peter Gutmann wrote:
>
>> But if you build a FDE product with it you've got to get the entire product
>> certified, not just the crypto component.
>
> I don't believe this to be the case.
>
> FIPS 140(-2) is about
17 matches
Mail list logo
