At 04:24 PM 2/4/2002 -0800, Bill Frantz wrote:
>At 2:09 PM -0800 2/4/02, [EMAIL PROTECTED] wrote:
> >1) A typical message would have a 20-byte nonce random number, which
> >computed to a 20-byte SHA1 and then encrypted with RSA resulting in 20-byte
> >signature (basic message plus 40-byte infrastr
With regards to the storage requirements in order to capture the massive
amounts of data in Rabin's system, has anyone correlated the growth rate
in mass storage devices against the network bandwidth speeds available?
Ie, is there a point at which we'll have cheap enough storage to make
such a
At 2:09 PM -0800 2/4/02, [EMAIL PROTECTED] wrote:
>One could claim that one of the reasons for using RSA digital signatures
>with smart cards rather than DSA or EC/DSA is the DSA & EC/DSA requirement
>for quality random number generation as part of the signature process.
>
>A lot of the RSA digita
At 11:00 AM -0500 2/4/02, Trei, Peter wrote:
>Don't forget that the MITM attack (which Schneier claims
>takes 2^(2n) = 2^112 time), also requires 2^56 blocks
>of storage. That's a lot, and the attack ceases to be
>parallelizable, unlike the straight brute-force attack.
>In fact, it's utterly intra
One could claim that one of the reasons for using RSA digital signatures
with smart cards rather than DSA or EC/DSA is the DSA & EC/DSA requirement
for quality random number generation as part of the signature process.
A lot of the RSA digital signatures have the infrastructure that creates
the
I'm not the local expert on this, but there are SCs with
built-in crypto accelerators. They are designed for the
use I described:
* Generate an RSA key pair on board,
* export the public key,
* re-import the certificate,
* wrap/unwrap a data block
(typically a session key or hash for signi
An 8-bit 1/2 MIP smart card can generate 1024 bit RSA key
pair in about 20 seconds and 512 bit key pair in less
than 5 seconds.
Since this isn't typically done in the checkout lane
this is certainly an acceptable time/security trade-off
by many lights. A device that can't generate a key pair
p
At 10:20 AM -0800 2/4/02, Bill Stewart wrote:
>There are special cases where the user's machine doesn't have
>the CPU horsepower to generate a key - PCs are fine,
>but perhaps Palm Pilots and similar handhelds are too slow
>(though a typical slow 33MHz 68000 or Dragonball is faster
>than the 8086/
This suffers from the same flaw as the last proposal: the security lies
in the idea that you can't store the data for long enough to be able to
decrypt the message that says where in the bitstream your data is.
However, this is defeatable by a delay line of sufficient length, just
like the last id
> From:Jaap-Henk Hoepman[SMTP:[EMAIL PROTECTED]]
>
> It's worse: it's even accepted practice among certain security
> specialists. One of them involved in the development of a CA service
> once told me that they intended the CA to generate the key pair.
> After regaining consciousnes
There are plenty of 'thought experiment' crypto systems which
are utterly infeasible in practice. Rabin's is one.
It does have perfect forward secrecy in that if Eve doesn't know
ahead of transmission time what part of the keystream to grab,
she can't later decrypt the message.
But, as Nicholas
Joshua Hill wrote:
>
> marius wrote:
> > Not quite true. Encrypting each message twice would not increase the
> > "effective" key size to 112 bits.
> > There is an attack named "meet in the middle" which will make the
> > effective key size to be just 63 bits.
>
> Peter Trei wrote:
> > Don't for
> Joshua Hill[SMTP:[EMAIL PROTECTED]] wrote:
>
>
> marius wrote:
> > Not quite true. Encrypting each message twice would not increase the
> > "effective" key size to 112 bits.
> > There is an attack named "meet in the middle" which will make the
> > effective key size to be just 63 bits.
>
> Pe
marius wrote:
> Not quite true. Encrypting each message twice would not increase the
> "effective" key size to 112 bits.
> There is an attack named "meet in the middle" which will make the
> effective key size to be just 63 bits.
Peter Trei wrote:
> Don't forget that the MITM attack (which Schnei
In article <[EMAIL PROTECTED]>,
Nicholas Brawn <[EMAIL PROTECTED]> wrote:
>What are people's thoughts on CFS vs. loopback encryption? I've used CFS
>in the past and found it quite useful, though as Matt said - a little
>long in the tooth. Never really looked into loopback encryption (which
>I'
ignoring for the moment the question of why certificates would be needed at
all
then public/private key technology is currently being used for (at least)
two distinct & different business processes
1) authentication
2) encryption
The business process of human person authentication has som
You sound surprised? I recently asked my bank[1] for a solvency
statement on a personal account and they responded that they were not
allowed to provide such statements. When pressed for an explanation I
was told that handing out those statements caused them too much
litigation. Apparently wh
One other scheme I've seen, and which, while it doesn't give me
warm fuzzies, seems reasonable, is to issue the
the enduser a smartcard with a keypair on it. The SC generates
the pair onboard, and exports only the public half. The private
half never leaves the SC (there is no function on the card
I read the article (in the dead tree edition), and despite it's
technical inaccuracies, thought it was generally
pretty good.
Don't forget that the MITM attack (which Schneier claims
takes 2^(2n) = 2^112 time), also requires 2^56 blocks
of storage. That's a lot, and the attack ceases to be
paral
It's worse: it's even accepted practice among certain security specialists. One
of them involved in the development of a CA service once told me that they
intended the CA to generate the key pair. After regaining consciousness I asked
him why he thought violating one of the main principles of pub
--- begin forwarded text
Status: U
Date: Mon, 4 Feb 2002 00:29:30 -0600 (CST)
From: InfoSec News <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [ISN] Microsoft taps former DOJ cybercop for top security slot
Sender: [EMAIL PROTECTED]
Reply-To: InfoSec News <[EMAIL PROTECTED]>
http://www.co
Correct me if I'm wrong, but isn't such a system feasible by:
1. Having the network infrastructure available to support the continuous
traffic loads.
2. Having a suitable RNG source that can cope with the reseeding/etc
requirements of encrypting bulk data.
3. Having a mechanism to insert genuin
--- begin forwarded text
Status: U
Date: Sun, 3 Feb 2002 19:06:49 -0800 (PST)
From: Declan McCullagh <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: FC: Int'v with Microsoft's Scott Charney on benefits of key escrow
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Politech archive on
23 matches
Mail list logo
