mobisys footers PDF1

Transcript

1 USENIX Association Proceedings of HotOS IX: The 9th Workshop on Hot Topics in Operating Systems Lihue, Hawaii, USA May 18–21, 2003 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2003 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein.

2 An Analysis of Compare-by-hash ValHenson Sun Microsystems [email protected] context. An informal survey of my colleagues re- Abstract veals that many computer scientists are still either Recent research has produced a new and perhaps unaware of compare-by-hash or disagree with the dangerous technique for uniquely identifying blocks technique strongly. Since adoption of compare-by- compare-by-hash . Using this tech- that I will call hash has the potential to change the face of oper- nique, we decide whether two blocks are identical ating systems design and implementation, it should to each other by comparing their hash values, using be the subject of more criticism and peer review be- a collision-resistant hash such as SHA-1[5]. If the fore being accepted as a general purpose computing hash values match, we assume the blocks are identi- technique for critical applications. cal without further ado. Users of compare-by-hash In this position paper, I hope to begin an in-depth argue that this assumption is warranted because the discussion of compare-by-hash. Section 2 reviews chance of a hash collision between any two randomly the traditional uses of hashing, followed by a more generated blocks is estimated to be many orders of detailed description of compare-by-hash in Section magnitude smaller than the chance of many kinds 3. Section 4 will raise some questions about the use of hardware errors. Further analysis shows that this of compare-by-hash as a general-purpose technique. approach is not as risk-free as it seems at first glance. Section 5 will propose some alternatives to compare- by-hash, and Section 6 will summarize my findings 1 Introduction and make recommendations. Compare-by-hash is a technique that trades on the 2 Traditional applications of hashing insight that applications frequently read or write data that is identical to already existing data. Rather than read or write the data a second time The review in this section may seem tedious and to the disk, network, or memory, we should use the unnecessary, but I believe that a clear understanding instance of the data that we already have. Using of how hashing has been used in the past is necessary a collision-resistant hash, we can quickly determine to understand how compare-by-hash differs. with a high degree of accuracy whether two blocks A maps a variable length input hash function are identical by comparing only their hashes and not hash string to fixed length output string — its their contents. After making a few assumptions, we for short. If the input is longer than value hash ,or can estimate that the chance of a hash collision is the output, then some inputs must map to the same much lower than the chance of a hardware error, and output — a hash collision . Comparing the hash so many feel comfortable neglecting the possibility values for two inputs can give us one of two answers: of a hash collision. the inputs are definitely not the same, or there is a Compare-by-hash is accepted by some computer sci- possibility that they are the same. Hashing as we entists and has been implemented in several different know it is used for performance improvement, er- projects: rsync[14], a utility for synchronizing files, ror checking, authentication, and encryption. One LBFS[4], a distributed file system, Stanford’s vir- example of a performance improvement is the com- tual computer migration project[9], Venti[6], a block mon hash table, which uses a hash function to index archival system, Pastiche[3], an automated backup into the correct bucket in the hash table, followed system, and OpenCM[11], a configuration manage- by comparing each element in the bucket to find a ment system. However, I believe some publications match. In error checking, hashes (checksums, mes- overstate the acceptance of compare-by-hash, claim- sage digests, etc.) are used to detect errors caused ing that it is “customary”[3] or a “widely-accepted by either hardware or software. Examples are TCP practice”[4] to assume hashes never collide in this checksums, ECC memory, and MD5 checksums on The 9th Workshop on Hot Topics in Operating Systems HotOS IX: USENIX Association 13

3 3 1 . In this case, the hash provides to calculate but we can use the “birthday paradox” downloaded files additional assurance that the data we received is cor- how many inputs will give us a 50% chance of find- rect. Finally, hashes are used to authenticate mes- ing a collision. For a 160-bit output, we will need 80 2 160 / sages. In this case, we are trying to protect the orig- about 2 or 2 inputs to have a 50% chance of inal input from tampering, and we select a hash that a collision. Put another way, we expect with about − 160 is strong enough to make malicious attack infeasible ) of certainty that any two ran- 2 48 nines (1 − or unprofitable. domly chosen inputs will not collide, whereas empir- ical measurements tell us we only have perhaps 8 or 9 nines of certainty that we will not encounter an un- 3 Compare-by-hash in detail detected TCP error when we transmit the block[13]. In the face of much larger sources of potential error, Compare-by-hash is a technique used when the pay- the error added by compare-by-hash appears to be off of discovering identical blocks is worth the com- negligible. putational cost of computing the hash of a block. In Now that we’ve described compare-by-hash in more compare-by-hash, we assume hash collisions never detail, it should be clear how compare-by-hash and occur, so we can treat the hash of a block as a unique traditional hashing differ: No known previous uses id and compare only the hashes of blocks rather than of hashing skip the step of directly comparing the the contents of blocks. For example, we can use inputs for performance reasons. The only case in compare-by-hash to reduce bandwidth usage. Be- which we do skip that step is authentication, because fore sending a block, the sender first transmits the we can’t compare the inputs directly due to the lack hash of the block to the receiver. The receiver checks of a secure channel. Compare-by-hash sets a new to see if it has a local block with the same hash value. precedent and so does not yet enjoy the acceptance If it does, it assumes that it is the same block as the of established uses of hashing. sender’s, without actually comparing the two input blocks. In the case of a 4096 byte block and a 160 bit hash value, this system can reduce network traf- 4 Questions about compare-by-hash fic from 4096 bytes to 20 bytes, or about a 99.5% savings in bandwidth. What appears to be a fall of manna from heaven should be examined a little more closely before This is an incredible savings! The cost, of course, compare-by-hash is accepted into the computer sci- is the risk of a hash collision. We can reduce that entist’s tricks of the trade. In the following section, risk by choosing a collision-resistant hash. From I will re-examine the assumptions we made earlier a cryptographic point of view, collision resistance when justifying the use of compare-by-hash. means that it is difficult to find two inputs that hash to the same output. By implication, the range of 4.1 Randomness of input hash values must be large enough that a brute-force 2 In Section 3, we calculated the probability of a hash attack to find collisions is “difficult.” Cryptolo- collision under the assumption that our inputs were gists have given us several algorithms that appear to random and uniformly distributed. While this as- have this property, although so far, only SHA-1 and . wrong sumption simplifies the math, it is also RIPEMD-160 have stood up to careful analysis[8]. Real data is not random, unless all applications pro- With a few assumptions, we can arrive at an esti- duce random data. This may seem like a trivial mate for the risk of a hash collision. We assume that and facile statement, but it is actually the key in- the inputs to the hash function are random and uni- sight into the weakness of compare-by-hash. If real formly distributed, and the output of the hash func- data were actually random, each possible input block n tion is also random and uniformly distributed. Let would be equally likely to occur, whereas in real be the number of input blocks, and let b be the num- data, input blocks that contain only ASCII charac- ber of bits in the hash output. As a function of the ters or begin with an ELF header are more common number of input blocks, n , the probability that we − b n than in random data. Knowing that real data isn’t will encounter one or more collisions is 1 2 − (1 − ) . is 160, This is a difficult number to calculate when b 3 The “birthday paradox ”is best illustrated by the ques- tion, “How many people do you need in a room to have a 50% 1 MD5 checksums are designed to detect intentional tam- or greater chance that two of them have the same birthday?” pering as well. The answer is 23 (assuming that birthdays are uniformly dis- 2 A cryptographicallysecurehash is defined as a hash tributed and neglecting leap years). This is easier to under- with no known method better than brute force for finding / 2) = 253 different stand if you realize that there are 23 × (22 collisions. of people in the room. pairs The 9th Workshop on Hot Topics in Operating Systems HotOS IX: USENIX Association 14

4 Obsolecence can occur overnight. A related random, can we think of some cases where it is non- consideration is how quickly obsolescence occurs for random in an interesting way? cryptosystems. In operating systems, we are used Consider an application, let’s call it [email protected], to systems slowing and gracefully obsolescing over a that attempts to find a collision in the SHA-1 hash period of years. Cryptosystems can go from state- function. [email protected] is a distributed application, of-the-art to completely useless overnight. so it runs many instances in parallel on many ma- Large governments, Obsolescence is inevitable. chines, using a distributed file system to share data corporations, and scientists all have a huge incentive when necessary. When two inputs are found that hash to the same value, one program reads and to analyze and break cryptographic hashes. We have compares both input blocks to find out if they dif- no proof that any particular hash, much less SHA-1, fer. If the file system uses compare-by-hash with is “unbreakable.” At the same time, history tells SHA-1 and the same block size as the inputs for us that we should expect any popular cryptographic [email protected], this application will be unable to de- hash to be broken within a few years of its introduc- tect a collision, ever. For example, if [email protected] tion. If anyone had built a distributed file system used a 2KB block size, it would run incorrectly if it using compare-by-hash and MD4, it would already 4 used LBFS as the underlying file system . be unusable today, due to known attacks that take seconds to find a collision using a personal computer. This is only one very crude, very simple example MD5 appears to be well on its way to unusability as of an entire class of applications that are very use- well[8]. ful, especially to cryptanalysts. In their 1998 pa- per, Chabaud and Joux implemented several pro- Given that our hash Upgrade strategy required. grams designed specifically to find collisions in var- algorithms will be obsolete within a few years, sys- ious hashing algorithms, including SHA-0 and sev- tems using compare-by-hash need to have a concrete eral relatives. They end by hinting at avenues of upgrade plan for what happens when anyone with a research for attacking SHA-1[2]. Somewhat ironi- PC can generate a hash collision. Upgrade will be cally, this paper is referenced by one of the papers more difficult if any hash collisions have occurred, using compare-by-hash[9]. because part of your data will now be corrupted, possibly a very important part of your data. 4.2 Cryptographic hashes — one size 4.3 Silent, deterministic, hard-to-fix er- fits all? rors Collision-resistant hashes were originally developed Ordinarily, anyone who discovered two inputs for use in cryptosystems. Is a hash intended for cryp- that hash to the same SHA-1 output would be- tography also good for use in systems with different come world-famous overnight. On a system using characteristics? compare-by-hash, that person would instead just Data is Cryptographic hashes are short-lived. silently read or overwrite the wrong data (which is forever, secrecy is not. The literature is rife with more than a bug, it’s a security hole). To understand examples of cryptosystems that turned out to not why silent errors are so bad, think about silent disk be nearly as secure as we thought. Weakness are corruption. Sometimes the corruption goes unde- frequently discovered within a few years of a crypto- tected until long after the last backup with correct graphic hash’s introduction[2, 8, 10]. On the other data has been destroyed. hand, lifetimes of operating systems, file systems, In addition, any two inputs that hash to the same and file transfer protocols are frequently measured value will always be treated incorrectly, whereas in decades. Solaris, FFS, and ftp come to mind im- most hardware errors are transitory and data- mediately. Cryptologists choose algorithms based on independent. Redundant disks or servers provide how long they want to keep their data secure, while no protection against data-dependent, deterministic computer scientists should choose their algorithms errors. To avoid this, we could add a random seed based on how long they want to keep their data, pe- every time we compute the hash, but we won’t save riod. (Cryptologists may desire to keep data secure anything except in the most extreme cases if we have for decades, but most would not expect their current to recompute hashes on every candidate local block algorithms to actually accomplish this goal.) every time we compare a block. 4 Once a hash collision has been found and a demon- LBFS uses variable sized blocks, but has minimum block strably buggy test program created using the collid- size of 2KB to avoid pathologically small block sizes[4] The 9th Workshop on Hot Topics in Operating Systems HotOS IX: USENIX Association 15

5 both the block and its SHA-1 hash, or we could ing inputs, how will you fix the bug? Usually, the slightly worsen that rate by sending only the hash. response to a test program that demonstrates a bug in the system is to fix the bug. In this case, the 4.6 When is compare-by-hash appropri- underlying algorithm is the bug. ate? 4.4 Comparing probabilities Taking all this into account, when is it reasonable One of the primary arguments for compare-by-hash to use compare-by-hash? For one, users of soft- is a simple comparison of the probability of a hash ware should know when they are getting best effort collision (very low) and the probability of some com- and when they are getting correctness. When using mon hardware error (also low but much higher). To rsync, the user knows that there is a tiny but real show that we cannot directly compare the probabil- possibility of an incorrect target file (in rsync’s case, ity of a deterministic, data-dependent error with the the user has only to read the man page). When us- probability of nondeterministic, data-independent ing a file system, or incurring a page fault, users ex- error, let’s construct a hash function that has the pect to get exactly the data they wrote, all the time. same collision probability as SHA-1 but, when used Another consideration is whether other users share in compare-by-hash, will be a far more common the “address space” produced by compare-by-hash. source of error than any normal hardware error. If only trusted users write data to the system, they don’t have to worry about maliciously generated col- Define VAL-1(x) as follows: lisions and can avoid known collisions. By these { standards, rsync is an appropriate use of compare- x> 0 : SHA-1( x ) x )= VAL-1( by-hash, whereas LBFS, Venti, Pastiche, and Stan- x = 0 : SHA-1(1) ford’s virtual machine migration are not. In other words, VAL-1 is SHA-1 except that the first two inputs map to the same output. This function 5 Alternatives to compare-by-hash has an almost identical probability of collision as SHA-1, but it is completely unsuitable for use in The alternatives to compare-by-hash can be sum- compare-by-hash. The point of this example is not marized as “Keep some state!” Compare-by-hash that bad hash functions will result in errors, but attempts to establish similarities between two un- that we can’t directly compare the probability of a known sets of blocks. If we keep track of which hash collision with the probability of a hardware er- blocks we are sure are identical (because we directly ror. If we could, VAL-1 and SHA-1 would be equally compared them), we don’t have to guess. Unfortu- good candidates for compare-by-hash. The relation- nately, keeping state is hard. Part of the popularity ship between the probability of a hash collision and of compare-by-hash is undoubtably due to its ease the probability of a hardware error must be more of implementation compared to a stateful solution. complicated than a straightforward comparison can However, simplicity of implementation should not reveal. come at the cost of correctness. 4.5 Software and reliability One of the applications of compare-by-hash is re- ducing network bandwidth used by distributed file On a more philosophical note, should software im- systems. To accomplish nearly the same effect, we prove on hardware reliability or should programmers can resolve to only send any particular block over accept hardware reliability as an upper bound on the link once, keeping sent and received data in a total system reliability? What would we think of a cache in both sender and receiver. Before sending a file system that had a race condition that was trig- block, the sender checks to see if it has already sent gered less often than disk I/O errors? What if it the block and if so, sends the block id rather than lost files only slightly less often than users acciden- the block itself. This idea is proposed by Spring and tally deleted them? Once we start playing the game Wetherall in [12]. We might also agree in advance of error relativity, where do we stop? Current soft- on certain universal block ids, for example, block id ware practices suggest that most programmers be- 0 is always the zero block of length 4096 bytes. The lieve software should improve reliability — hence we initial start-up cost is higher, depending on the de- have TCP checksums, asserts for impossible hard- gree of actually shared blocks between the two ma- ware conditions, and handling of I/O errors. For ex- chines, but after cache warm-up, performance should ample, the empirically observed rate of undetected be quite similar to compare-by-hash. errors in TCP packets is about 0.0000005%[13]. We In combination with an intelligent blocking tech- could dramatically improve that rate by sending The 9th Workshop on Hot Topics in Operating Systems HotOS IX: USENIX Association 16

6 nique, such as Rabin fingerprints[7], which divide 6 Conclusion up blocks at “anchor” points (patterns in the in- put) rather than at fixed intervals, we can exper- Use of compare-by-hash is justified by mathematical iment with byte and block level differencing tech- calculations based on assumptions that range from niques that require similar amounts of computation unproven to demonstrably wrong. The short life- time as computing cryptographic hashes. Using fin- time and fast transition into obsolescence of cryp- gerprints to determine block boundaries allows us tographic hashes makes them unsuitable for use in to more easily detect insertions and deletions within long-lived systems. When hash collisions do occur, blocks. they cause silent errors and bugs that are difficult to repair. What should worry computer scientists Compression may still have more mileage left in it, the most about compare-by-hash is that real people since we are willing to trade off large amounts of are running real workloads that will execute incor- computation for reduced bandwidth. We might try rectly on systems using compare-by-hash. Perhaps compressing with several different algorithms opti- research would be better directed towards alterna- mized for different inputs. tives to or improvements on compare-by-hash that avoid the problems described. At the very least, fu- 5.1 Existence proof: Rsync vs. Bit- ture research using compare-by-hash should include Keeper a more careful analysis of the risk of hash collisions. As an example of a system that improves on compare-by-hash while retaining correctness, com- 7 Acknowledgments pare rsync and BitKeeper[1], a commercial source configuration management tool. They both solve Many people joined in on (both sides of) the dis- the problem of keeping several source code trees cussion that led to this paper and provided help- in sync. (We will ignore the unrelated features ful comments on drafts, including Jonathan Adams, of BitKeeper, such as versioning, in this compari- Matt Ahrens, Jeff Bonwick, Bryan Cantrill, Miguel son.) Rsync is stateless; it has no a priori knowledge Castro, Whit Diffie, Marius Eriksen, Barry Hayes, of the relationship between two source code trees. Richard Henderson, Larry McVoy, Dave Powell, It uses compare-by-hash to determine which blocks Bart Smaalders, Niraj Tolia, Vernor Vinge, and are different between the two trees and sends only Cynthia Wong. the blocks with different hashes. BitKeeper keeps state about each file under source control and knows References what changes have been made since the last time each tree was synchronized. When synchronizing, it [1] Bitmover, Inc. Bitkeeper - the scalable dis- sends only the differences since the last synchroniza- tributed software configuration management tion occurred, in compressed form. In comparison system. http://www.bitkeeper.com. to rsync, BitKeeper provides similar and sometimes better bandwidth usage when simply synchronizing [2] Florent Chabuad and Antoine Joux. Differ- two trees without resorting to compare-by-hash. Im- Proceedings of ential collisions in SHA-0. In provements BitKeeper provides over rsync include CRYPTO ’98, 18th Annua lInternationa lCryp- elimination of reverse updates (synchronizing in the , pages 56–71, 1998. tology Conference wrong direction and losing your changes), automerg- [3] Landon P. Cox, Christoper D. Murray, and ing algorithms optimized for source code (so trees Brian D. Noble. Pastiche: Making backup can be updated in parallel and then synchronized), cheap and easy. In Proceedings of the 5th Sym- and intelligent handling of metadata operations such posium on Operating Systems Design and Im- as renaming of files (which rsync sees as deletion and , 2002. plementation creation of files). With a little more programming effort, we can get [4] Athicha Muthitacharoen, Benjie Chen, and the bandwidth reduction promised by compare-by- David Mazi ́ eres. A low-bandwidth network file hash without sacrificing correctness and at the same Proceedings of the system. In 18th ACM Sym- time adding functionality. Compare-by-hash still posium on Operating Systems Principles , 2001. has applications in areas where statelessness and low bandwidth are more important than correctness of [5] National Institute of Standards and Technol- data referenced, and users are aware of the risk they ogy. FIPS Publication 180–1: Secure Hash are taking, as in rsync. Standard , 1995. The 9th Workshop on Hot Topics in Operating Systems HotOS IX: USENIX Association 17

7 [6] Sean Quinlan and Sean Dorward. Venti: a new Proceedings of approach to archival storage. In the FAST 2002 Conference on File and Storage Technologies , 2002. [7] M. O. Rabin. Fingerprinting by random poly- nomials. Technical Report TR–15–81, Center for Research in Computer Technology, Harvard University, 1981. [8] B. Van Rompay, B. Preneel, and J. Vandewalle. On the security of dedicated hash functions. In 19th Symposium on Information Theory in the Benelux , 1998. [9] Constantine P. Sapuntzakis, Ramesh Chandra, Ben Pfaff, Jim Chow, Monica S. Lam, and Mendel Rosenblum. Optimizing the migration of virtual computers. In Proceedings of the 5th Symposium on Operating Systems Design and , 2002. Implementation [10] Bruce Schneier. . John Applied Cryptography Wiley & Sons, Inc., second edition, 1996. [11] Jonathan S. Shapiro and John Vanderburgh. CPCMS: A configuration management system based on cryptographic names. In Proceed- ings of the 2002 USENIX Technica lConference, FREENIX Track , 2002. [12] Neil T. Spring and David Wetherall. A pro- tocol independent technique for eliminating re- dundant network traffic. In Proceedings of the 2000 ACM SIGCOMM Conference , 2000. [13] Jonathan Stone and Craig Partridge. When the CRC and TCP checksum disagree. In Proceed- , ings of the 2000 ACM SIGCOMM Conference 2000. Efficient Algorithms for Sort- [14] Andrew Tridgell. . PhD thesis, The Aus- ing and Synchronization tralian National University, 1999. The 9th Workshop on Hot Topics in Operating Systems HotOS IX: USENIX Association 18

Related documents

COMM 750 Network S Directory   508

COMM 750 Network S Directory 508

SM Provider Directory – Blue Network S UPDATED SEPTEMBER 2016

More info »
NRDC: Game Changer   How the Sports Industry Is Saving the Environment (PDF)

NRDC: Game Changer How the Sports Industry Is Saving the Environment (PDF)

SePtember 2012 rEpor N R DC T r:12-08-A Game ChanGer how the SPortS induStry iS Saving the environment Preface Major League Baseball Commissioner Allan H. (Bud) Selig afterword Martin Tull, Executive ...

More info »
doj final opinion

doj final opinion

UNITED STAT ES DIS TRICT COURT IC F OR THE D ISTR T OF CO LU M BIA UNITED STAT F AMERICA, : ES O : : la in t if f, P 99 No. on cti l A vi Ci : 96 (GK) -24 : and : TOBACCO-F UND, : REE KIDS ACTION F : ...

More info »
JO 7400.11C   Airspace Designations and Reporting Points

JO 7400.11C Airspace Designations and Reporting Points

U.S. DEPARTMENT OF TRANSPORTATION ORDER FEDERAL AVIATION ADMINISTRATION 7400.11C JO Air Traffic Organization Policy August 13, 2018 SUBJ: Airspace Designations and Reporting Points . This O rder, publ...

More info »
Computer Vision: Algorithms and Applications

Computer Vision: Algorithms and Applications

Computer Vision: Algorithms and Applications Richard Szeliski September 3, 2010 draft c © 2010 Springer This electronic draft is for non-commercial personal use only, and may not be posted or re-distr...

More info »
Cemetery%20Brochure%20Final%20opt%202

Cemetery%20Brochure%20Final%20opt%202

GONE BUT NOT FORGOTTEN CEMETERIES IN THE NATION’S CAPITAL Text by Anne O. Brockett, Architectural Historian District of Columbia Historic Preservation Office Brochure Design by [email protected] P...

More info »
facilities by location

facilities by location

2019 KENTUCKY DIRECTORY OF MANUFACTURERS February 1, 2019 REPORT DATE: NUMBER OF FACILITIES: 2,449 257,976 TOTAL FULL-TIME EMPLOYMENT: Geographic Guide Manufacturers Listed by City Location 300 W. Bro...

More info »
"I Was Born": Slave Narratives, Their Status as Autobiography and as Literature

"I Was Born": Slave Narratives, Their Status as Autobiography and as Literature

"I Was Born": Slave Narratives, Their Status as Autobiography and as Literature Author(s): James Olney Source: No. 20 (Winter, 1984), pp. 46-73 Callaloo, Published by: The Johns Hopkins University Pre...

More info »
"Seek But You May Not Find": Non UCC Recorded, Unrecorded and Hidden Security Interests Under Article 9 of the Uniform Commercial Code

"Seek But You May Not Find": Non UCC Recorded, Unrecorded and Hidden Security Interests Under Article 9 of the Uniform Commercial Code

Fordh am L w aw R evie | Issue 5 Article 1 Volume 53 1985 ou M ay N ind": N on-UC C ut Y "Seek B ot F , U nr ecor Recor nd H idde n S ec ur ity ded ded a ts U nde r A rticle 9 of the U ni for m Intere...

More info »
Thriving on Our Changing Planet: A Decadal Strategy for Earth Observation from Space

Thriving on Our Changing Planet: A Decadal Strategy for Earth Observation from Space

TIONAL ACADEMIES PRESS THE NA This PDF is available at http://nap.edu/24938 SHARE     Thriving on Our Changing Planet: A Decadal Strategy for Earth Observation from Space DET AILS 700 pages | 8.5 ...

More info »
CDIR 2018 07 27

CDIR 2018 07 27

S. Pub. 115-7 2017-2018 Official Congressional Directory 115th Congress Convened January 3, 2017 JOINT COMMITTEE ON PRINTING UNITED STATES CONGRESS UNITED STATES GOVERNMENT PUBLISHING OFFICE WASHINGTO...

More info »
625137

625137

2018-19 Nebraska All-Sports Record Book - Nebraska Communications Office -

More info »
roads and bridges the unseen labor behind our digital infrastructure

roads and bridges the unseen labor behind our digital infrastructure

Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure WRITTEN BY Nadia Eghbal

More info »
7340.2H  Bsc dtd 3 29 18

7340.2H Bsc dtd 3 29 18

ORDER JO 7340.2H Air Traffic Organization Policy Effective Date: March 29, 2018 Contractions SUBJ: contractions used by ed word and phrase This handbook contains the approv personnel of the Federal Av...

More info »
WG1AR5 Chapter09 FINAL

WG1AR5 Chapter09 FINAL

Evaluation of Climate Models Coordinating Lead Authors: 9 Gregory Flato (Canada), Jochem Marotzke (Germany) Lead Authors: Babatunde Abiodun (South Africa), Pascale Braconnot (France), Sin Chan Chou (B...

More info »
Operator Directory Listing

Operator Directory Listing

OPERATOR'S DIRECTORY SORTED BY OPERATOR NAME DATA SUPPLIED BY: FORM 1006 B CURRENT AS OF: Tuesday, April 16, 2019 Please notify Surety Department at ( 405 ) 521-2273 of any corrections or omissions th...

More info »
GMBAMasterlist 18 19

GMBAMasterlist 18 19

Agency of Administration State of Vermont 802 3261 Tel: - - 828 Department of Libraries - 802 Fax: - 828 2199 109 State Street -- Montpelier, VT 05609 0601 Book Award Green Mountain - 2019 Master List...

More info »
StateGovernmentDirectory

StateGovernmentDirectory

West Virginia State Government Directory Published May 2, 2019 West Virginia State Government Directory 1

More info »
Feature Specific Neural Reactivation during Episodic Memory

Feature Specific Neural Reactivation during Episodic Memory

bioRxiv preprint first posted online Apr. 30, 2019; doi: http://dx.doi.org/10.1101/622837 . The copyright holder for this preprint (which was not peer-reviewed) is the author/funder, who has granted b...

More info »
Feature Specific Neural Reactivation during Episodic Memory

Feature Specific Neural Reactivation during Episodic Memory

bioRxiv preprint first posted online Apr. 30, 2019; doi: http://dx.doi.org/10.1101/622837 . The copyright holder for this preprint (which was not peer-reviewed) is the author/funder, who has granted b...

More info »