summaryrefslogtreecommitdiffstats
path: root/crypto/secure_hash_unittest.cc
Commit message (Collapse)AuthorAgeFilesLines
* [Downloads] Rework how hashes are calculated for download files.asanka2016-03-151-31/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-4/+6
| | | | | | | | | | 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-2/+2
| | | | | | | | | | There should be no behavior change. TBR=jschuh (IPC messages) Review URL: https://codereview.chromium.org/1154283003 Cr-Commit-Position: refs/heads/master@{#332552}
* clean up code at crypto folder.rucifer1217@gmail.com2014-07-221-0/+2
| | | | | | | | BUG=none Review URL: https://codereview.chromium.org/407713002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@284547 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor Pickle Read methods to use higher performance PickleIterator.jbates@chromium.org2012-03-071-3/+3
| | | | | | | | | | | | | | | | 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/+39
| | | | | | | | | | | | 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
* Convert SHA256_LENGTH from a constant-in-anonymous-enum to a static const. ↵pkasting@chromium.org2011-09-221-2/+2
| | | | | | | | | | | | | | This defines the constant where it's declared to preserve the existing readability. Normally this makes things like DCHECK_EQ() unhappy, but when I'd originally tested this I didn't seem to need to make any changes due to that. Will be watching the trybots... The original motiviation for this change was to find a way to eliminate some cases of passing anonymous-typed values as template arguments (which happens when you use a value from the enum in e.g. EXPECT_EQ()), which is technically illegal in C++03, though we don't warn about it. Simply naming the enum would have done this, but in general naming enums used to declare constants like this is bizarre ("enum Constants { ... }"?). BUG=92247 TEST=Compiles Review URL: http://codereview.chromium.org/7823004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@102369 0039d316-1c4b-4281-b951-d872f2087c98
* Move crypto files out of base, to a top level directory.rvargas@google.com2011-04-141-0/+34
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-12 14:28:33 +0000