Re: Slow zone signing with ECDSA

[hasibuzzaman]

sir can you help me by showing the code to implement the RSASHA3 method in
the zone?



--
Sent from: http://bind-users-forum.2342410.n4.nabble.com/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Slow zone signing with ECDSA

[Mukund Sivaraman]

On Thu, Apr 20, 2017 at 04:03:21PM +0100, Chris Thompson wrote:
> On Apr 20 2017, Tony Finch wrote:
> 
> > Mark Andrews  wrote:
> > > 
> > > DSA requires random values as part of the signing process.
> > 
> > Traditionally, yes, but it isn't actually required -
> > https://tools.ietf.org/html/rfc6979
> 
> There is a great deal to be said for using deterministic DSA even if
> your random number source is both trustworthy and fast.
> 
> The EdDSA standards (RFCs 8032 & 8080) mandate deterministic signatures
> and this is certainly intentional. Of course, there are also many other
> ways in which they are improvements on the earlier NIST-based ECDSA
> standards, and we should all be looking forward to the time when BIND,
> inter alia, supports them...

As there's some discussion on use of entropy during signing, allow me to
talk about other draft RRSIG algorithms.

When preparing support for SHA-3 algorithms, the RSASSA-PSS signature
scheme was chosen for RSA RRSIGs as it is a more robust scheme than
RSASSA-PKCS1-v1_5:

https://tools.ietf.org/html/draft-muks-dnsop-dnssec-sha3-01

Unlike the existing RSA DNSKEY/RRSIG algorithms, RSASSA-PSS uses a
"salt" input (per signature), but we made its randomness requirement a
"SHOULD" in the draft. This allows signing in environments where an
entropy source is not available, however, where one is available, a PRNG
ought to be sufficient for signing purposes. The non-randomness of the
salt is not crucial (see full domain hash vs. RSA PSS in "The Exact
Security of Digital Signatures - How to Sign with RSA and Rabin",
Bellare and Rogaway.) However, with a random salt, the scheme has exact
security and a similar security guarantee is achieved with a smaller RSA
modulus size.

The draft also covers ECDSA(SHA-3()).

Mukund


signature.asc
Description: PGP signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Slow zone signing with ECDSA

[Chris Thompson]

On Apr 20 2017, Tony Finch wrote:


Mark Andrews  wrote:


DSA requires random values as part of the signing process.


Traditionally, yes, but it isn't actually required -
https://tools.ietf.org/html/rfc6979


There is a great deal to be said for using deterministic DSA even if
your random number source is both trustworthy and fast.

The EdDSA standards (RFCs 8032 & 8080) mandate deterministic signatures
and this is certainly intentional. Of course, there are also many other
ways in which they are improvements on the earlier NIST-based ECDSA
standards, and we should all be looking forward to the time when BIND,
inter alia, supports them...

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Slow zone signing with ECDSA

[Daniel Stirnimann]

>> DSA requires random values as part of the signing process.
> 
> Traditionally, yes, but it isn't actually required -
> https://tools.ietf.org/html/rfc6979

This is only implemented in openssl 1.1.0:
https://github.com/openssl/openssl/commit/190c615d4398cc6c8b61eb7881d7409314529a75

As I've read today BIND 9.11.1 can be used with openssl 1.1.0

Daniel

-- 
SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 24
daniel.stirnim...@switch.ch, http://www.switch.ch
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Slow zone signing with ECDSA

[Tony Finch]

Mark Andrews  wrote:
>
> DSA requires random values as part of the signing process.

Traditionally, yes, but it isn't actually required -
https://tools.ietf.org/html/rfc6979

(PuTTY has been using deterministic DSA since 2001, because of
problems with obtaining random numbers on old versions of Windows.
https://git.tartarus.org/?p=simon/putty.git;a=commit;h=d345ebc2a5)

You should always use /dev/urandom to get random numbers unless your
system has a better API like getrandom(2) or getentropy(2). On Linux,
gaveged is a good way to stop /dev/random blocking unenlightened software.
https://www.2uo.de/myths-about-urandom/
https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Rockall, Malin, Hebrides: Westerly or southwesterly, veering northwesterly
later in north Rockall and Hebrides, 4 or 5, increasing 6 at times. Moderate
or rough, becoming very rough in north Hebrides. Rain at times. Good,
occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Slow zone signing with ECDSA

[Paul Kosinski]

"The tinfoil hat brigade in some distributions has resisted using them,
fearing some conspiracy to provide not-so-random numbers."

I think the NSA *did*, in fact, compromise the "Dual Elliptic Curve
Deterministic Random Bit Generator" and paid RSA to make it the default
in one of their products -- https://en.wikipedia.org/wiki/Dual_EC_DRBG.


On Wed, 19 Apr 2017 22:09:28 -0400
Timothe Litt  wrote:

> 
> On 19-Apr-17 21:43, Mark Andrews wrote:
> > ...
> > DSA requires random values as part of the signing process.  Really
> > all CPU's should have real random number sources built into them
> > and new genuine random values should only be a instruction code
> > away.
> >
> > Mark
> Most recent ones do.  See RDRAND for Intel (and AMD).  Even Raspberry
> Pi.
> 
> The tinfoil hat brigade in some distributions has resisted using them,
> fearing some conspiracy to provide not-so-random numbers.  (Despite
> the fact that /dev/random hashes/whitens the inputs to the entropy
> pool.) You may need to take a positive action to enable use of the
> hardware source.  Google RDRAND for plenty of entertainment.
> 
> There are also fairly inexpensive (~usd 50) USB devices that provide
> reasonable entropy quality at decent speeds.  (But much lower than
> RDRAND.)  They're good for the old hardware that you recycle for
> single-purpose servers.
> 
> Systems that have low activity/low entropy can benefit from
> entropybroker (https://www.vanheusden.com/entropybroker/).  Use it to
> distribute entropy from those who have to those who don't.  It's
> really handy for VMs, and for that isolated system that you use for
> your root keys.
> 
> For most uses, use /dev/urandom - which doesn't block.  /dev/random
> will block if the entropy pool is depleted.  (However, if you have a
> hardware source, very, very rarely.)  /dev/random is recommended for
> long lived keys - which usually includes KSKs, and may include ZSKs.
> I don't believe named makes a distinction...you get to pick one for
> everything.
> 
> Timothe Litt
> ACM Distinguished Engineer
> --
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed. 
> 
> 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Re: Slow zone signing with ECDSA

[Timothe Litt]

On 19-Apr-17 21:43, Mark Andrews wrote:
> ...
> DSA requires random values as part of the signing process.  Really
> all CPU's should have real random number sources built into them
> and new genuine random values should only be a instruction code away.
>
> Mark
Most recent ones do.  See RDRAND for Intel (and AMD).  Even Raspberry Pi.

The tinfoil hat brigade in some distributions has resisted using them,
fearing some conspiracy to provide not-so-random numbers.  (Despite the
fact that /dev/random hashes/whitens the inputs to the entropy pool.) 
You may need to take a positive action to enable use of the hardware
source.  Google RDRAND for plenty of entertainment.

There are also fairly inexpensive (~usd 50) USB devices that provide
reasonable entropy quality at decent speeds.  (But much lower than
RDRAND.)  They're good for the old hardware that you recycle for
single-purpose servers.

Systems that have low activity/low entropy can benefit from
entropybroker (https://www.vanheusden.com/entropybroker/).  Use it to
distribute entropy from those who have to those who don't.  It's really
handy for VMs, and for that isolated system that you use for your root keys.

For most uses, use /dev/urandom - which doesn't block.  /dev/random will
block if the entropy pool is depleted.  (However, if you have a hardware
source, very, very rarely.)  /dev/random is recommended for long lived
keys - which usually includes KSKs, and may include ZSKs.  I don't
believe named makes a distinction...you get to pick one for everything.

Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Slow zone signing with ECDSA

[Mark Andrews]

In message , "Spain, Dr. Jeffry A." writes:
> > Install and run haveged... The problem is your system doesn't have
> > enough entropy
>
> This was clearly the problem. I built a new test server with haveged
> installed, and the bind9 completed ECDSAP256SHA256 signing in 5 seconds.
> I used 9.11.1 this time since it was just released today.

DSA requires random values as part of the signing process.  Really
all CPU's should have real random number sources built into them
and new genuine random values should only be a instruction code away.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Slow zone signing with ECDSA

[Spain, Dr. Jeffry A.]

> Install and run haveged... The problem is your system doesn't have enough 
> entropy
This was clearly the problem. I built a new test server with haveged installed, 
and the bind9 completed ECDSAP256SHA256 signing in 5 seconds. I used 9.11.1 
this time since it was just released today.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Slow zone signing with ECDSA

[Spain, Dr. Jeffry A.]

> Install and run haveged... The problem is your system doesn't have enough 
> entropy in the processor or maybe it's a VM but either way there is not 
> enough entropy to produce random seeds which is why it is taking so long.

Thanks, David. The system is a Microsoft Azure VM. I assumed that while entropy 
is required for ECDSA key generation, which in any event I did on another 
system, additional entropy would not be required for the zone signing process 
itself. Jeff.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users