Re: Russian Duma Adopts Law On Digital Signatures

[Pawel Krawczyk]

> It does not mean the bill is "good"; in fact, it is "bad" from many
> aspects. Its preparation and lobbying was a real mess, four years long
> with undercarpet struggle. Its language is unclear, many definitions
> are elusive and many articles in fact endorse ambiguous
> interpretation. Unfortunately I have not several hours needed to
> translate the text and comments :(

Interesting how laws are passed in the part of world, as Polish digital
signature law was also passed with lots of private businesses being
done in both Parliament and Senate, against advice of the expert
comission created by the Parliament itself (sic!)  and agains the EU
recommendations. So we have the law enacted, but everyone is expecting
that to be changed soon to become usable, and definitely to make it
compliant with EU law.

-- 
Pawel Krawczyk
Krakow, POLAND
http://ipsec.pl/



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: chip-level randomness?

[Pawel Krawczyk]

On Wed, Sep 19, 2001 at 05:17:18PM -0400, Theodore Tso wrote:

> One of the things which I've always been worried about with the 810
> hardware random number generators in general is how to protect against
> their failing silently.  My original design intention here was that
> this be done in a user-mode process that could run FFT's, and do other
> kinds of analysis on the output of the hardware random number
> generator, and then if it passed, it could use an already-existing
> interface to atomically add the random bytes to the entropy pool and
> give credit to the entropy counter.

The rngd daemon by Philipp Rumpf I mentioned in previous posts does almost
exactly that. It runs a loop, that first reads 2500 bytes from i810,
then runs several FIPS 140-1 tests on the data and if it returns success,
it uses RNDADDENTROPY ioct to add this data to the kernel pool. Then it
checks current state of the pool with RNDGETPOOL and either sleeps for
some time or repeats the process. Seems to be reasonable both from the
security and performance perspective...

-- 
Paweł Krawczyk *** home: 
security:   *** fidonet: 2:486/23



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: chip-level randomness?

[Pawel Krawczyk]

On Wed, Sep 19, 2001 at 01:12:44AM -0700, Bram Cohen wrote:

> > not necessary in general case
> Since most applications reading /dev/random don't want random numbers
> anyway?

Here I meant exactly what you said about /dev/random religion. On the
other hand feeding the /dev/random with i810 during normal system
operation is not bad idea, as /dev/random is not a PRNG but pool,
that can be emptied if not feed enough from other semi-random events
(interrupts, keyboard).

> At startup and with 200 bits of data would be fine.
> Of course, there's the religion of people who say that /dev/random output
> 'needs' to contain 'all real' entropy, despite the absolute zero increase
> in security this results in and the disastrous effect it can have on
> performance.

Ok, I get your point now. I'm not sure if reading a blocking device
(i810) from kernel is a very good idea, however. That's sort of things
that is very good suited for userland, when the system goes multiuser
and multiprocess.

Actually, it would be a quite good idea for the Linux distribution
vendors to add a "dd if=/dev/intel_rng of=/dev/random bs=1k count=1" to
the PRNG initialization scripts. If it fails, then you probably don't
have i810 and everything works the old way... Maybe it's even already
done, as the author of i810 daemon seems to be from MandrakeSoft.

-- 
Paweł Krawczyk *** home: 
security:   *** fidonet: 2:486/23



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: chip-level randomness?

[Pawel Krawczyk]

On Mon, Sep 17, 2001 at 01:44:57PM -0700, Bram Cohen wrote:

> > What is important, it *doesn't* feed the built-in Linux kernel PRNG
> > available in /dev/urandom and /dev/random, so you have either to only
> > use the hardware generator or feed /dev/urandom yourself.
> That's so ... stupid. Why go through all the work of making the thing run
> and then leave it unplugged?

It's not that stupid, as feeding the PRNG from i810_rng at the kernel
level would be resource intensive, not necessary in general case and
would require to invent some defaults without any reasonable arguments
to rely on. Like how often to feed the PRNG, with how much data etc.

On the other hand, the authors provide a `rngd' daemon, running in
userland, that reads the i810_rng device and feeds the data into kernel
PRNG. It seems to be reasonably written, with all the possible caveats
in mind, and you can control the feeding interval, block size and other
parameters.

URI: http://sourceforge.net/project/showfiles.php?group_id=3242&release_id=28349

-- 
Paweł Krawczyk *** home: 
security:   *** fidonet: 2:486/23



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: chip-level randomness?

[Pawel Krawczyk]

On Sat, Sep 15, 2001 at 10:16:27AM -0700, Carl Ellison wrote:

> I'm told that the LINUX 2.4 kernel comes with the RNG driver
> built-in, but I haven't tried that.

It works almost out of box, kernel detects the chip and if you have the
necessary device file created (character 10,183 AFAIK) you can use it to
read random data streams. It blocks sometimes when you read long blocks,
but it's quite obvious and it returns as soon as it collects enough data
to satisfy your request. What is important, it *doesn't* feed the built-in
Linux kernel PRNG available in /dev/urandom and /dev/random, so you have
either to only use the hardware generator or feed /dev/urandom yourself.

-- 
Paweł Krawczyk *** home: 
security:   *** fidonet: 2:486/23



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: South Africa moves to increase Net-surveillance, limit crypto

[Pawel Krawczyk]

On Tue, Aug 14, 2001 at 11:34:40AM +0100, Clive D. W. Feather wrote:

> I suspect that it's aimed at link-layer encryption. In other words, 
> where the ISP/telco runs one end of the encryption themselves, but the 
> most convenient point to tap happens to be on the encrypted part of the 
> link.

This is very similiar to the requirement that appeared
in Polish Internet surveillance law, described at Cryptome
(http://cryptome.org/pl-sorm-rip.htm). This requirement is targeted at
ISP that provide encryption facility for customer either as outsorcing
or included in PVC subscription etc.

Although I don't like the law and it would have catastrophical effect
on Polish Internet services market, this seems to be a quite logical
requirement. Its state is still unknown and probably won't be known
before the September Parliament election. And probably after that those
guys will have more serious problems to solve than surveillance, with
current predicions for budget deficit...

-- 
Paweł Krawczyk *** home: 
security:   *** fidonet: 2:486/23



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]