[tor-bugs] #17868 [Core Tor/Tor]: base64_decode_nopad() destination buffer length problem

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Apr 6 13:19:40 UTC 2017


#17868: base64_decode_nopad() destination buffer length problem
-----------------------------+------------------------------------
 Reporter:  dgoulet          |          Owner:  nikkolasg
     Type:  defect           |         Status:  needs_revision
 Priority:  Medium           |      Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor     |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:  review-group-12  |  Actual Points:
Parent ID:  #19531           |         Points:  2
 Reviewer:  dgoulet          |        Sponsor:  SponsorR-can
-----------------------------+------------------------------------

Comment (by nickm):

 Replying to [comment:38 catalyst]:
 > I think part of the difficulty is that the contract of
 `base64_decode_nopad()` is a bit ambiguous. Must padding be absent? Must
 spaces (or newlines) be absent? i.e., must the unpadded input encoding be
 of minimum length (which also means that the output length is a function
 solely of the input length)? If the input to `base64_decode_nopad()`
 doesn't meet these constraints, should that be an error?

 Suggestion:

 The nopad() variant should allow either padding or no padding.


 >
 > Also, in `base64_decode()`, the length check at the beginning is overly
 conservative. Maybe it should just start decoding and return an error if
 it runs out of space? Or maybe make a first pass over the input to count
 the actual number of output bytes required before the actual decoding?

 I think the first option is better?  Two-pass approaches can be risky if
 there is the tiniest mismatch in the passes' behavior.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17868#comment:39>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list