* Avoid calling RR.Header more than once per RR
Header is an interface method so there's non-zero overhead when calling
it.
* Reset entire RR_Header in SIG.Sign
This is equivilant (while also clearing Rdlength) while being simpler.
* Remove fullSize return from compressionLenSearch
This wasn't used anywhere but TestCompressionLenSearch, and was very
wrong.
* Add generated compressedLen functions and use them
This replaces the confusing and complicated compressionLenSlice
function.
* Use compressedLenWithCompressionMap even for uncompressed
This leaves the len() functions unused and they'll soon be removed.
This also fixes the off-by-one error of compressedLen when a (Q)NAME
is ".".
* Use Len helper instead of RR.len private method
* Merge len and compressedLen functions
* Merge compressedLen helper into Msg.Len
* Remove compress bool from compressedLenWithCompressionMap
* Merge map insertion into compressionLenSearch
This eliminates the need to loop over the domain name twice when we're
compressing the name.
* Use compressedNameLen for NSEC.NextDomain
This was a mistake.
* Remove compress from RR.len
* Add test case for multiple questions length
* Add test case for MINFO and SOA compression
These are the only RRs with multiple compressible names within the same
RR, and they were previously broken.
* Rename compressedNameLen to domainNameLen
It also handles the length of uncompressed domain names.
* Use off directly instead of len(s[:off])
* Move initial maxCompressionOffset check out of compressionLenMapInsert
This should allow us to avoid the call overhead of
compressionLenMapInsert in certain limited cases and may result in a
slight performance increase.
compressionLenMapInsert still has a maxCompressionOffset check inside
the for loop.
* Rename compressedLenWithCompressionMap to msgLenWithCompressionMap
This better reflects that it also calculates the uncompressed length.
* Merge TestMsgCompressMINFO with TestMsgCompressSOA
They're both testing the same thing.
* Remove compressionLenMapInsert
compressionLenSearch does everything compressionLenMapInsert did anyway.
* Only call compressionLenSearch in one place in domainNameLen
* Split if statement in domainNameLen
The last two commits worsened the performance of domainNameLen
noticably, this change restores it's original performance.
name old time/op new time/op delta
MsgLength-12 550ns ±13% 510ns ±21% ~ (p=0.050 n=10+10)
MsgLengthNoCompression-12 26.9ns ± 2% 27.0ns ± 1% ~ (p=0.198 n=9+10)
MsgLengthPack-12 2.30µs ±12% 2.26µs ±16% ~ (p=0.739 n=10+10)
MsgLengthMassive-12 32.9µs ± 7% 32.0µs ±10% ~ (p=0.243 n=9+10)
MsgLengthOnlyQuestion-12 9.60ns ± 1% 9.20ns ± 1% -4.16% (p=0.000 n=9+9)
* Remove stray newline from TestMsgCompressionMultipleQuestions
* Remove stray newline in length_test.go
This was introduced when resolving merge conflicts.
* Remove redundant parenthesis
These were caught with:
gofmt -r '(a) -> a' -w *.go
This commit only includes the changes where the formatting makes the
ordering of operations clear.
* Remove more redundant parenthesis
These were caught with:
gofmt -r '(a) -> a' -w *.go
This commit includes the remaining changes where the formatting does not
make the ordering of operations as clear as the previous commit.
RFC 2537 (RSA/MD5) and RFC 3110 (RSA/SHA1) disallow leading zero octets.
RFC 5702 (RSA/SHA256 and RSA/SHA512) isn't specific but defers to these
earlier RFCs in other places.
There is an upper limit of 4096 bits for both the modulus and exponent.
The modulus must be at least 512 bits. No minimum is specified for the
exponent but a quick search suggests single byte exponents are viable.
Exponents larger than 32 bits are already disallowed. This commit adds
checks for the other requirements, general bounds checks, and defers
initialisation of the big num till the other checks have passed.
* Add test from #688 demonstrating bug decoding RSA exponent
* Unpack RSA exponent in correct order
Fixes#688
* Don't unpack RSA keys with an exponent too large for the crypto package
* Update dnssec_test.go
Fix the one nit
copyHeader() is redundant, we allocate a header and then copy the
non-pointer elements into it; we don't need to do this, because if we
just asssign rr.Hdr to something else we get the same result.
Remove copyHeader() and the generation and use of it in ztypes.go.
* Add support for Ed25519 DNSSEC signing from RFC 8080
Note: The test case from RFC 8080 has been modified
to correct the missing final brace, but is otherwise
present as-is.
* Explain why ed25519 is special cased in (*RRSIG).Sign
* Explain use of ed25519.GenerateKey in readPrivateKeyED25519
* Add dep
This is PR #458 with the dependency added into it.
rawSignatureData currently missed a few types:
MD MF RP AFSDB RT SIG PX NXT A6
We don't have NXT and A6 anymore in this lib. Add the other ones.
Fixes#523
* Produce less garbage in dnssec.go.
This change removes several needless append calls.
This is a minor performance improvement and will likely go
entirely unnoticed. The changes will reduce the amount of
garbage produced when calling (*DNSKEY).ToDS, (*RRSIG).Sign
and (*RRSIG).Verify.
* Minor performance improvement in RSA DNSSEC key generation.
This change ensures that (*big.Int).Bytes is only called once in
exponentToBuf because each call has non-zero overhead. It also
makes buf large enough to append without a second allocation.
exponentToBuf is invoked by (*DNSKEY).setPublicKeyRSA which is in
turn invoked by (*DNSKEY).Generate when (*DNSKEY).Algorithm is set
to an RSA* constant.
This is a minor performance improvement that will likely go
entirely unnoticed. The changes will improve the performance and
reduce the ammount of garbage produced when calling
(*DNSKEY).Generate.
* Remove {un,}packUint{16,32}Msg functions.
unpackUint16Msg unpackUint32Msg packUint16Msg packUint32Msg implemented
functionality that is part of the encoding/binary package.
* Use encoding/binary's encoding in more places.
Remove the use of reflection when packing and unpacking, instead
generate all the pack and unpack functions using msg_generate.
This will generate zmsg.go which in turn calls the helper functions from
msg_helper.go.
This increases the speed by about ~30% while cutting back on memory
usage. Not all RRs are using it, but that will be rectified in upcoming
PR.
Most of the speed increase is in the header/question section parsing.
These functions *are* not generated, but straight forward enough. The
implementation can be found in msg.go.
The new code has been fuzzed by go-fuzz, which turned up some issues.
All files that started with 'z', and not autogenerated were renamed,
i.e. zscan.go is now scan.go.
Reflection is still used, in subsequent PRs it will be removed entirely.
This will allow RRSIG.Sign to use generic crypto.Signer implementations.
This is a interface breaking change, even if the required changes are most
likely just type asserions from crypto.PrivateKey to the underlying type or
crypto.Signer.
Change suggested by miekg, since the caller may already know it's
passing a proper RRset.
Update unit test to call isValidRRSet directly instead of expecting Sign
to return an error for sets the fail the check.
Add a sanity check used by RRSig's Sign and Verify functions making sure
that the records they operate on form a valid RRSet (same name, type,
and class).
Add a unit test TestInvalidRRSet that calls RRSig's Sign and Verify
methods with invalid RRSets, and makes sure the correct error is
returned.
Now PrivateKey is an interface exposing Sign() and String(). Common
implementations are wrappers for {rsa|dsa|ecdsa}.PrivateKey but
this allows for custom signers, and abstracts away the private-ops
code to a single place.
ECDSA public keys consist of a single value, called "Q" in FIPS
186-3. In DNSSEC keys, Q is a simple bit string that represents the
uncompressed form of a curve point, "x | y".
The ECDSA signature is the combination of two non-negative integers,
called "r" and "s" in FIPS 186-3. The two integers, each of which is
formatted as a simple octet string, are combined into a single longer
octet string for DNSSEC as the concatenation "r | s". (Conversion of
the integers to bit strings is described in Section C.2 of FIPS
186-3.) For P-256, each integer MUST be encoded as 32 octets; for
P-384, each integer MUST be encoded as 48 octets.