summaryrefslogtreecommitdiffstats
path: root/crypto/secure_hash_default.cc
Commit message (Collapse)AuthorAgeFilesLines
* [Downloads] Rework how hashes are calculated for download files.asanka2016-03-151-43/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this CL, downloads assumed that there would be a stable serialization of hash state. This serialization was meant to be persisted and used if the download was subsequently resumed, thus avoiding rehashing the portion of the download completed so far. However, there's no standard serialization for SHA256 hash state. Any change to the serialization format would render any historical data invalid. While it's possible to come up with a reasonable and stable format for hash state, the resulting complexity isn't worth it. Fortunately, the code for persisting the hash state was never written. Hence it's not too late to change things. With this CL, downloads will behave as follows with respect to hashes: * An in-progress download will calculate the hash of the bytes written to disk so far using a crypto::SecureHash object using SHA256. * Progress notifications from DownloadItem / DownloadFile no longer report a hash state. * If the download completes successfully, DownloadFile exposes the crypto::SecureHash object representing the final hash state via the DownloadDestinationObserver interface. DownloadItemImpl uses this object to calculate the final hash which is then made available via DownloadItem::GetHash() for completed downloads. * In the event of an interruption, DownloadFile will expose the crypto::SecureHash object representing the hash state. DownloadItemImpl uses a clone of the hash state to obtain a SHA256 hash of the partial data. This hash is available via DownloadItem::GetHash() on interrupted downloads. DownloadItemImpl also keeps the crypto::SecureHash object in case the download is resumed later. * Resuming downloads pass the crypto::SecureHash object representing the partial state via DownloadSaveInfo. If a crypto::SecureHash object isn't available (e.g. because the download was restored from history), then DownloadItemImpl can optionally pass along a SHA256 hash of the partial file. If for some reason, the partial state of the download is abandoned (e.g. because of a validation error), then DownloadRequestCore destroys the cryto::SecureHash object and resets the prefix hash so that the download can restart from the beginning. * When DownloadManagerImpl receives a StartDownload() callback (which happens when a response is available for a download request), the crypto::SecureHash object passed within DownloadSaveInfo is used to construct a new DownloadFile. * A newly created DownloadFile assumes that a crypto::SecureHash object passed to it correctly represents the partial state of the partial file. * In the absence of a crypto::SecureHash object, DownloadFile reads the partial file and calculates the partial hash state in a new crypto::SecureHash object. If a prefix hash value is available, then the hash of the partial file is matched against this prefix hash. A mismatch causes a FILE_HASH_MISMATCH error which in turn causes the download to abandon its partial state and restart. These rules establish the following invariants: * All downloads calculate the SHA256 hash of its contents. * Regardless of how a download is started or resumed, by the time it is completed successfully, DownloadItem::GetHash() correctly reports the SHA256 hash of the downloaded bytes. * Regardless of how a download is started or resumed, an interrupted download with a received byte count > 0 will always report the correct SHA256 hash of the partial data in DownloadItem::GetHash(). Note that this CL doesn't add code to persist the hash for an interrupted download. In order to keep the size of the CL sane, the download history changes are going to be done in a follow up CL. BUG=7648 BUG=563684 Review URL: https://codereview.chromium.org/1751603002 Cr-Commit-Position: refs/heads/master@{#381158}
* Switch to standard integer types in crypto/.avi2015-12-211-0/+2
| | | | | | | | | | BUG=138542 TBR=rsleevi@chromium.org NOPRESUBMIT=true Review URL: https://codereview.chromium.org/1539353003 Cr-Commit-Position: refs/heads/master@{#366460}
* Change most uses of Pickle to base::Picklebrettw2015-06-031-4/+4
| | | | | | | | | | There should be no behavior change. TBR=jschuh (IPC messages) Review URL: https://codereview.chromium.org/1154283003 Cr-Commit-Position: refs/heads/master@{#332552}
* Standardize usage of virtual/override/final specifiers in crypto/.dcheng2014-12-221-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Google C++ style guide states: Explicitly annotate overrides of virtual functions or virtual destructors with an override or (less frequently) final specifier. Older (pre-C++11) code will use the virtual keyword as an inferior alternative annotation. For clarity, use exactly one of override, final, or virtual when declaring an override. To better conform to these guidelines, the following constructs have been rewritten: - if a base class has a virtual destructor, then: virtual ~Foo(); -> ~Foo() override; - virtual void Foo() override; -> void Foo() override; - virtual void Foo() override final; -> void Foo() final; This patch was automatically generated. The clang plugin can generate fixit hints, which are suggested edits when it is 100% sure it knows how to fix a problem. The hints from the clang plugin were applied to the source tree using the tool in https://codereview.chromium.org/598073004. Several formatting edits by clang-format were manually reverted, due to mangling of some of the more complicate IPC macros. BUG=417463# Review URL: https://codereview.chromium.org/825503002 Cr-Commit-Position: refs/heads/master@{#309488}
* Replacing the OVERRIDE with override and FINAL with final in /src/cryptoanujk.sharma2014-10-071-4/+4
| | | | | | | | | | | This step is a giant search and replace for OVERRIDE and FINAL to replace them with their lowercase versions. BUG=417463 Review URL: https://codereview.chromium.org/632653002 Cr-Commit-Position: refs/heads/master@{#298360}
* Fix nits in SecureHash.wtc@chromium.org2012-11-301-0/+1
| | | | | | | | | | R=agl@chromium.org,rsleevi@chromium.org BUG=none TEST=none Review URL: https://chromiumcodereview.appspot.com/11299235 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@170308 0039d316-1c4b-4281-b951-d872f2087c98
* crypto: Tag some overridden methods with OVERRIDE.tfarina@chromium.org2012-07-301-4/+5
| | | | | | | | | | BUG=115047 R=rsleevi@chromium.org Review URL: https://chromiumcodereview.appspot.com/10824076 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@148928 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor Pickle Read methods to use higher performance PickleIterator.jbates@chromium.org2012-03-071-9/+6
| | | | | | | | | | | | | | | | There was a lot of redundant error checking and initialization code in all Pickle Read methods because of the void** iterator type. This change replaces the void* iterator with PickleIterator, which encapsulates the read pointer so that less error checking and initialization code is needed for reading. PickleIterator has all the necessary data to do the actual reading. The advantage of having it provide Read methods (as opposed to leaving them solely in the Pickle interface) is that the callers do not need to pass around the const Pickle* once they have a PickleIterator. Followup CLs will refactor the call sites to remove const Pickle* arguments where they are now unnecessary. Then the Pickle::Read* methods can be removed entirely. The alternative approach would have been to change the Pickle::Read methods to non-const and remove the iterator parameter (making Read methods advance an internal read pointer). Unfortunately, the const Read with iterator design is entrenched throughout the chromium code, making this a much more complex change with the same performance outcome. BUG=13108 Review URL: https://chromiumcodereview.appspot.com/9447084 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@125447 0039d316-1c4b-4281-b951-d872f2087c98
* Added serialization to SecureHash.ahendrickson@chromium.org2011-11-191-0/+48
| | | | | | | | | | | | These will be used to resume hash generation when a download is interrupted and later resumed. BUG=None. TEST=SecureHashTest.TestSerialization Review URL: http://codereview.chromium.org/8588057 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@110842 0039d316-1c4b-4281-b951-d872f2087c98
* Rename crypto/third_party/nss headers to avoid mixups.mattm@chromium.org2011-11-151-2/+2
| | | | | | | | | | | | | | When trying to include the real NSS headers from other files under crypto/third_party/nss, the local versions would get used on the MSVS build. BUG=none TEST=none Review URL: http://codereview.chromium.org/8538025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@110009 0039d316-1c4b-4281-b951-d872f2087c98
* Move crypto files out of base, to a top level directory.rvargas@google.com2011-04-141-0/+49
src/crypto is now an independent project that contains our cryptographic primitives (except md5 and sha1). This removes the base dependency from nss, openssl and sqlite. BUG=76996 TEST=none Review URL: http://codereview.chromium.org/6805019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@81611 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2024-05-13 05:41:43 +0000