9/6/17

1

3.CryptographyReview

Prof.TudorDumitrașAssistantProfessor,ECEUniversityofMaryland,CollegePark

ENEE657

http://ter.ps/enee657

Today’sLecture

• Wherewe’vebeen–  IntroducFontocomputersecurity

– MemorycorrupFonexploits

• Wherewe’regoingtoday–  Cryptographyreview

• Wherewe’regoingnext–  Homework1dueonFriday!

–  OSprotecFonmechanisms

2

9/6/17

2

PilotProjectProposals•  DueonMonday–  PostproposalonthePiazzadiscussionboard–  SomeideasavailableontheclassWebpage

•  Proposalshouldbeconcise(2-3paragraphs)–  Problemstatement–  Approachconsideredfortacklingtheproblem

• Mustdescribeconcretetasks,notvaguedirecFons• Mustdemonstratethatyou’vethoughtaboutthefirststeps,andyouarenotsimplyparaphrasingtheprojectideasIgaveyou

•  Comeseemeduringofficehours(AVW3425,Mon@2pm)–  Ifyouarenotsurewhattodoforyourproject–  Ifyouwanttoproposeatopicthatisnotonthelistfromthecoursewebpage–  IfyouhaveanyquesFonsabouttheproject

3

RandomVariablesandRandomNumbers

• ArandomvariableXisaruleforassigninganumbertoeachexperimentaloutcome–  Example:XisthenumberofheadsaYerncointosses

– We’reoYentryingtodeterminetheprobabilitydistribuRonofX• AssignprobabiliFesp1,p2,…pntovaluesx1,x2,…xnofX• UniformdistribuFon:p1=p2=…=pn

• Computersproducepseudo-randomnumbers–  Sequenceofnumbersthatappearsrandom

–  ThenumbersinthesequencefollowcertainmathemaFcalproperFes,e.g.uniformdistribuRon

–  Sequenceofnumbers(orbit)starFngfromaseedvalue• Sameseedprovided =>samesequencegenerated

4Commoncryptomisuse#1:usingstaRcseeds

9/6/17

3

CryptoPrimiRves:Hashingvs.EncrypRon

• Givenplaintextx–  Hashing: funcFonH(),suchthatH(x)isann-bitstring

–  EncrypFon:funcFonsD()andE(),suchthatDkey’(Ekey(x))=x

• Hashingisone-way.Thereisno“uh-hashing”!–  AciphertextcanbedecryptedwithadecrypFonkey…hasheshavenoequivalentofdecrypFon

• Hash(x)looks“random”butcanbecomparedforequalitywithHash(x’)–  Hashthesameinputtwice→samehashvalue–  Encryptthesameinputwithdifferentkeys→differentciphertexts

5Commoncryptomisuse#2:usingconstantencrypRonkeys

HashFuncRons:MainIdea

bitstringsofanylength n-bitstrings

. .

...

x’x’’

x

y’y

hashfuncFonH

• HashfuncFonHisalossycompressionfuncFon–  Collision:H(x)=H(x’)forsomeinputsx≠x’

• H(x)shouldlookrandom–  Everybit(almost)equallylikelytobe0or1

• AcryptographichashfuncRonmusthavecertainproperFes

“messagedigest”message

6

9/6/17

4

One-WayFuncRons

•  IntuiFon:hashshouldbehardtoinvert–  “Preimageresistance”

–  Givenh()andy,itshouldbehardtofindanyxsuchthath(x)=y• yisann-bitstringrandomlychosenfromtheoutputspaceofthehashfuncFon,ie,y=h(x’)forsomex’

• Howhard?–  Brute-force:tryeverypossiblex,seeifh(x)=y–  SHA256(acommonhashfuncFon,brokenrecently)has256-bitoutput• SupposewehaveHWthatcancompute1B(≈230)hashesatonceanddo234trialspersecond

• Cantry289hashesperyear• Willtake2167yearstoinvertSHA256onarandomimage

7

BirthdayParadox

• Tpeople• SupposeeachbirthdayisarandomnumbertakenfromKdays(K=365)–howmanypossibiliFes?–  KT-sampleswithreplacement

• HowmanypossibiliFesthatarealldifferent?–  (K)T=K(K-1)…(K-T+1)-sampleswithoutreplacement

• ProbabilityofnorepeFFon?–  (K)T/KT≈1-T(T-1)/2K

• ProbabilityofrepeFFon?–  O(T2)

8

9/6/17

5

CollisionResistance

• Shouldbehardtofindx≠x’suchthath(x)=h(x’)• Birthdayparadox–  LetTbethenumberofvaluesx,x’,x’’…weneedtolookatbeforefindingthefirstpairx≠x’s.t.h(x)=h(x’)

–  Assuminghisrandom,whatistheprobabilitythatwefindarepeFFonaYerlookingatTvalues?

–  Totalnumberofpairs?• n=numberofbitsintheoutputofhashfuncFon

–  Conclusion:• Brute-forcecollisionsearchisO(2n/2),notO(2n)–  ForSHA256,thismeansO(2128)vs.O(2256)

O(T2)

O(2n)

T≈O(2n/2)

9

One-Wayvs.CollisionResistance

• One-waynessdoesnotimplycollisionresistance–  Supposeg()isone-way–  Defineh(x)asg(x’)wherex’isxexceptthelastbit• hisone-way(cannotinverthwithoutinverFngg)• Collisionsforhareeasytofind:foranyx,h(x0)=h(x1)

• Collisionresistancedoesnotimplyone-wayness–  Supposeg()iscollision-resistant–  Defineh(x)tobe0xifxis(n-1)-bitlong,else1g(x)• Collisionsforharehardtofind:ifystartswith0,thentherearenocollisions;ifystartswith1,thenmustfindcollisionsing

• hisnotoneway:halfofally’s(thosewhosefirstbitis0)areeasytoinvert(how?),thusrandomyisinverFblewithp≥½

10

9/6/17

6

WeakCollisionResistance

• Givenarandomlychosenx,hardtofindx’≠xsuchthath(x)=h(x’)–  “Secondpre-imageresistance”

–  Avackermustfindcollisionforaspecificx…bycontrast,tobreakcollisionresistance,enoughtofindanycollision

–  Brute-forceavackrequiresO(2n)Fme

• Weakcollisionresistancedoesnotimplycollisionresistance

11

ApplicaRon:PasswordHashing

•  Insteadofuserpassword,storehash(password)

• Whenuserentersapassword,computeitshashandcomparewiththeentryinthepasswordfile–  Systemdoesnotstoreactualpasswords!–  Cannotgofromhashtopassword!

• Whatavacksdoesthisprevent?–  Doeshashingprotectweak,easilyguessablepasswords?

12

9/6/17

7

ProtecRngPasswordsAgainstDicRonaryA`acks

• Peopletendtochosecommonwordsforpasswords–  Avackercanpre-computeH(word)foreverywordinthedicFonary–thisonlyneedstobedoneonce!(moreonthislater)

–  Defensesaimtoincreasetheavacker’sworkfactor

• SalFng–  Choseasalt:doesnothavetobesecret,butmustberandom–  ComputeH(salt||pwd)

• KeyderivaFonfuncFons– MulFpleiteraFonsofthehashfuncFon:H(H(H(…(salt||pwd))))

13

Commoncryptomisuse#3:hashingpasswordswithconstantsalts

Commoncryptomisuse#4:fewerthan1000iteraRonsofkeyderiv.funcRon

ApplicaRon:SoawareIntegrity

goodFile

SoYwaremanufacturerwantstoensurethattheexecutablefileisreceivedbyuserswithoutmodificaFon…SendsoutthefiletousersandpublishesitshashintheNYTimesThegoalisintegrity,notsecrecy

Idea:givengoodFileandhash(goodFile),veryhardtofindbadFilesuchthathash(goodFile)=hash(badFile)

BigFirm™ User

VIRUS

badFile

TheTimes

hash(goodFile)

14

9/6/17

8

WhichPropertyIsNeeded?

• Passwordsstoredashash(password)–  One-wayness:hardtorecoverenFrepassword–  Passwordsarenotrandomandthusguessable

•  IntegrityofsoYwaredistribuFon– Weakcollisionresistance?–  ButsoYwareimagesarenotrandom…maybeneedfullcollisionresistance

• AucFons:tobidB,sendH(B),laterrevealB–  One-wayness…butdoesnotprotectBfromguessing–  Collisionresistance:biddershouldnotbeabletofindtwobidsBandB’suchthatH(B)=H(B’)

15

CommonHashFuncRons

• MD5–  Completelybrokenbynow

• RIPEMD-160–  160-bitvariantofMD-5

• SHA-1(SecureHashAlgorithm)– Widelyused(butrecentlybroken)

–  USgovernment(NIST)standardasof1993-95• AlsothehashalgorithmforDigitalSignatureStandard(DSS)

• SHA256

16

9/6/17

9

IntegrityandAuthenRcaRon

IntegrityandauthenRcaRon:onlysomeonewhoknowsKEYcancomputecorrectMACforagivenmessage

Alice Bob

KEYKEY

message

MAC(messageauthenFcaFoncode)

message,MAC(KEY,message)

=?

RecomputesMACandverifieswhetheritisequaltotheMACavachedtothemessage

17

HMAC

• ConstructMACfromacryptographichashfuncFon–  InventedbyBellare,Cane|,andKrawczyk(1996)

–  UsedinSSL/TLS,mandatoryforIpsec

• WhynotencrypFon?–  HashingisfasterthanencrypFon–  LibrarycodeforhashfuncFonswidelyavailable–  CaneasilyreplaceonehashfuncFonwithanother–  ThereusedtobeUSexportrestricFonsonencrypFon

18

9/6/17

10

SymmetricCryptography

?---------------

Given:bothparFesalreadyknowthesamesecret

HowisthisachievedinpracFce?Goal:sendamessageconfidenFally

AnycommunicaFonsystemthataimstoguaranteeconfidenRalitymustsolvethisproblem

19

Kerckhoffs'sPrinciple

• AnencrypFonschemeshouldbesecureevenifenemyknowseverythingaboutitexceptthekey–  Avackerknowsallalgorithms

–  Avackerdoesnotknowrandomnumbers

• Donotrelyonsecrecyofthealgorithms(“securitybyobscurity”)

Fullname:Jean-Guillaume-Hubert-Victor-François-Alexandre-AugusteKerckhoffsvonNieuwenhof

20

Commoncryptomisuse#5:DIYcrypto

9/6/17

11

CommonSymmetricCryptoAlgorithms

• DES–  64-bitblocks(56-bitkey+8bitsforparity)–  Outdated,butsFllinuse(especiallyas3DES)• 3DES:DES+inverseDES+DES(with2or3differentkeys)

• AES(Rijndael)–  128-bitblocks,keyscanbe128,192or256bits–  USfederalstandardasof2001

• Theseareblockciphers–  Operateonfixed-sizeblocks–  Asopposedtostreamciphers(keyisaslongastheplaintext)

21

EncrypRngaLargeMessage

• So,we’vegotagoodblockcipher,butourplaintextislargerthan128-bitblocksize

• ElectronicCodeBook(ECB)mode–  Splitplaintextintoblocks,encrypteachoneseparatelyusingtheblockcipher

• CipherBlockChaining(CBC)mode–  Splitplaintextintoblocks,XOReachblockwiththeresultofencrypFngpreviousblocks

• Alsovariouscountermodes,feedbackmodes,etc.

22

9/6/17

12

ECBMode

•  IdenFcalblocksofplaintextproduceidenFcalblocksofciphertext

• Nointegritychecks:canmixandmatchblocks

plaintext

ciphertext

blockcipher

blockcipher

blockcipher

blockcipher

blockcipher

key key key key key

23

InformaRonLeakageinECBMode[Wikipedia]

EncryptinECBmode

24

Commoncryptomisuse#6:usingECBmode

9/6/17

13

Sentwithciphertext(preferablyencrypted)

CBCMode:EncrypRon

•  IdenFcalblocksofplaintextencrypteddifferently•  LastcipherblockdependsonenFreplaintext

plaintext

ciphertext

blockcipher

blockcipher

blockcipher

blockcipher

⊕IniFalizaFon

vector(random) ⊕ ⊕ ⊕

key key key key

25Commoncryptomisuse#7:usingaconstantIVinCBCmode

CBCMode:DecrypRon

plaintext

ciphertext

decrypt decrypt decrypt decrypt

⊕IniFalizaFonvector ⊕ ⊕ ⊕

key key key key

26

• SFlldoesnotguaranteeintegrity

9/6/17

14

HowCanaCipherBeA`acked?

• AvackersknowsciphertextandencrypFonalgorithm– Whatelsedoestheavackerknow?DependsontheapplicaFoninwhichthecipherisused!

• Known-plaintextavack(stronger)–  Knowssomeplaintext-ciphertextpairs

• Chosen-plaintextavack(evenstronger)–  Canobtainciphertextforanyplaintextofhischoice

• Chosen-ciphertextavack(verystrong)–  Candecryptanyciphertextexceptthetarget–  SomeFmesveryrealisFc

27

InformalIntuiRon

• Securityagainstchosen-plaintextavack–  CiphertextleaksnoinformaFonabouttheplaintext

–  Eveniftheavackercorrectlyguessestheplaintext,hecannotverifyhisguess

–  Everyciphertextisunique,encrypFngsamemessagetwiceproducescompletelydifferentciphertexts

• Securityagainstchosen-ciphertextavack–  IntegrityprotecFon–itisnotpossibletochangetheplaintextbymodifyingtheciphertext

Minimumsecurityrequirementfora

modernencrypFonscheme

28

9/6/17

15

Encrypt+MAC

Goal:confidenFality+integrity+authenFcaFon

Alice Bob

K1,K2K1,K2

msg

MAC=HMAC(K2,msg)

encrypt(msg),MAC(msg)

=?

Encrypt(K1,msg)

Decrypt

VerifyMAC

encrypt(msg2),MAC(msg2)

Cantellifmessagesarethesame!

MACisdeterminisFc:messagesareequal⇒theirMACsareequal

SoluFon:Encrypt,thenMAC(orMAC,thenencrypt)

Breakschosen-plaintextsecurity

29

Public-KeyCryptography

?

Given:EverybodyknowsBob’spublickey -HowisthisachievedinpracFce?

OnlyBobknowsthecorrespondingprivatekey

privatekey

Goals:1.AlicewantstosendamessagethatonlyBobcanread 2.BobwantstosendamessagethatonlyBobcould

havewriven

publickey

publickey

AliceBob

30

9/6/17

16

ApplicaRonsofPublic-KeyCrypto

• EncrypFonforconfidenFality–  Anyonecanencryptamessage• Withsymmetriccrypto,mustknowthesecretkeytoencrypt

–  Onlysomeonewhoknowstheprivatekeycandecrypt–  Secretkeysareonlystoredinoneplace

• DigitalsignaturesforauthenFcaFonandintegrity–  Onlysomeonewhoknowstheprivatekeycansign

• Sessionkeyestablishment–  Exchangemessagestocreateasecretsessionkey–  Thenswitchtosymmetriccryptography(why?)

31

Public-KeyEncrypRon

• KeygeneraFon:computaFonallyeasytogenerateapair(publickeyPK,privatekeySK)

• EncrypFon:givenplaintextMandpublickeyPK,easytocomputeciphertextC=EPK(M)

• DecrypFon:givenciphertextC=EPK(M)andprivatekeySK,easytocomputeplaintextM–  InfeasibletolearnanythingaboutMfromCwithoutSK

–  TrapdoorfuncFon:Decrypt(SK,Encrypt(PK,M))=M

• Popularalgorithm:RSA32

9/6/17

17

DigitalSignatures:BasicIdea

?

Given:EverybodyknowsBob’spublickey OnlyBobknowsthecorrespondingprivatekey

privatekey

Goal:Bobsendsa“digitallysigned”message1.  Tocomputeasignature,mustknowtheprivatekey2.  Toverifyasignature,onlythepublickeyisneeded

publickey

publickey

Alice Bob

33

PopularDigitalSignatureSchemes

• RSAsignatures–  SigninganddecrypFonarethesamemathemaFcaloperaFon

–  VerificaFonandencrypFonarethesamemathemaFcaloperaFon

– Messagemustbehashedandpadded

• DSA(digitalsignaturealgorithm)signatures–  U.S.governmentstandard(1991-94)– ModificaFonoftheElGamalsignaturescheme(1985)

–  SecurityofDSArequireshardnessofdiscretelogproblem• Hardtoextractx(privatekey)fromgxmodp(publickey)

–  Ifthesamemessageissignedtwice,signaturesaredifferent• Eachsignatureisbasedinpartonrandomsecretk• Secretkmustbedifferentforeachsignature!

34

9/6/17

18

Diffie-HellmanProtocol

• AliceandBobnevermetandsharenosecrets• Publicinfo:pandg–  Hardtoextractx(privatekey)fromgxmodp(publickey)

Alice Bob

Picksecret,randomX Picksecret,randomY

gymodp

gxmodp

Computek=(gy)x=gxymodp

Computek=(gx)y=gxymodp

35

Commoncryptomisuse#8:exchangingkeysw/oauthenRcaRngtheendpoint

ProperResofDiffie-Hellman

• Assumingthediscretelogarithmproblemishard,Diffie-Hellmanisasecurekeyestablishmentprotocolagainstpassiveavackers–  Eavesdroppercan’ttellthedifferencebetweentheestablishedkeyandarandomvalue

–  Canusethenewkeyforsymmetriccryptography

• BasicDiffie-HellmanprotocoldoesnotprovideauthenFcaFon–  IPseccombinesDiffie-Hellmanwithsignatures,anF-DoScookies,etc.

36

9/6/17

19

AdvantagesofPublic-KeyCrypto

• ConfidenFalitywithoutsharedsecrets–  Veryusefulinopenenvironments

–  Canusethisforkeyestablishment,avoidingthe“chicken-or-egg”problem• Withsymmetriccrypto,twoparFesmustshareasecretbeforetheycanexchangesecretmessages

• AuthenFcaFonwithoutsharedsecrets

• EncrypFonkeysarepublic,butmustbesurethatAlice’spublickeyisreallyherpublickey–  Hardproblem,currentlysolvedusingpublic-keycerFficates(moreonthislater)

37

DisadvantagesofPublic-KeyCrypto

• CalculaFonsare2-3ordersofmagnitudeslower– ModularexponenFaFonisanexpensivecomputaFon

–  Typicalusage:usepublic-keycryptographytoestablishasharedsecret,thenswitchtosymmetriccrypto• SSL,IPsec,mostothersystemsbasedonpubliccrypto

• Keysarelonger–  2048bits(RSA)ratherthan128bits(AES)

• Reliesonunprovennumber-theoreFcassumpFons–  Factoring,RSAproblem,discretelogarithmproblem,decisionalDiffie-Hellmanproblem…

38

9/6/17

20

CommonCryptoMisuseExamples• UsingstaFcseedsforrandomnumbergenerators

• UsingconstantencrypFonkeys• Hashingpasswordswithconstantsalts

• Fewerthan1000iteraFonsofkeyderivaFonfuncFon

• DIYcrypto• UsingECBmode• UsingaconstantIVinCBCmode• Exchangingkeysw/oauthenFcaFngtheendpoint

• Manyothers(seehvp://cwe.mitre.org)39

the security benefits of symmetric encryption. For example,AdMob encrypts the phone’s location data using a constantkey and sends it over the network. Another example is anapplication that stores the user’s Google credentials on diskencrypted using a static key.

Rule 2: Do not use a non-random IV for CBC encryp-

tion. CryptoLint identified 1,932 applications that makeuse of constant initialization vectors in CBC mode encryp-tion.

Rule 4: Do not use constant salts for PBE. Cryp-

toLint identified 1,574 applications that use a static valuefor the salt used with the key derivation function in PBE.Using a static salt allows an attacker to pre-compute a dictio-nary based on the known salt, negating much of the benefit ofusing a salt at all. While the use of a static salt is better thanusing the password directly as encryption key, this choicenegates the advantages in multi-instance security [5].

Rule 5: Do not use fewer than 1,000 iterations for PBE.

The Java PBEKeySpec API implements password based en-cryption based on the PKCS#5 standard. The RFC forPKCS#5 recommends an iteration count of at least 1,000.CryptoLint identified 1,636 applications that use feweriterations. Applications that use a low iteration count anda static salt for password-based encryption are exposed totrivial dictionary-based o↵-line attacks, exactly the type of at-tacks that password-based encryption schemes were designedto protect against.

Applications violating multiple rules We next investi-gated the number of applications that violate multiple rules.These results are illustrated in Figure 1. Interestingly, itwas more common for applications to violate two rules thanonly violating a single rule. Of the applications violating asingle rule, rule 1 was violated the most (3,033 times). 511applications violated rule 2 and used constant IVs. For 246applications CryptoLint identified the use of a static sym-metric encryption key (violation of rule 3). 29 applicationswere flagged for using a low iteration count, and 13 appli-cations use static salt values for password-based encryptionschemes. CryptoLint identified 6 applications that onlyviolated rule 6 by seeding SecureRandom with a static seed.

The numbers of applications that violated exactly tworules are listed in Table 3. Additionally, our dataset con-tained exactly one application that violated all six rulesthat CryptoLint evaluates.

# apps rules violated1,905 Rule 1 & Rule 31,588 Rule 1 & Rule 61,247 Rule 4 & Rule 5866 Rule 2 & Rule 3109 Rule 1 & Rule 224 Rule 1 & Rule 511 Rule 3 & Rule 55 Rule 2 & Rule 52 Rule 1 & Rule 42 Rule 3 & Rule 4

Table 3: Applications violating two rules

1

10

100

1000

10000

0 1 2 3 4 5 6

Num

ber

of

dis

tinct

appli

cati

ons

Number of distinct violated rules

Figure 1: Number of applications violating 0, 1, 2,

. . . 6 rules.

6.2 Case Studies

Social gaming platform To estimate the impact of apply-ing cryptographic primitives incorrectly, we manually exam-ined a popular game that CryptoLint reported as misusingcrypto. This game is from a development studio that releaseda series of popular games, all containing a social platform forconnecting and interacting with friends. This social platformis used to track high-scores on a leader board. Accordingto Google play, the application we analyzed has between50,000,000 and 100,000,000 installations. The applicationcommunicates with the back-end servers of the social compo-nents over http. However, data that is transmitted betweenthe server and the client is encrypted. This application gotflagged by CryptoLint for two reasons. First, it uses theDES blockcipher in ECB mode. The developers explicitlyspecified the ECB block cipher mode as the used transfor-mation string is DES/ECB). Furthermore, CryptoLint alsocomplains that the application uses a static key with thisencryption scheme. We evaluated the correctness of theseresults by interacting with the game and exercising the socialnetwork functionality while at the same time recording allnetwork tra�c sent by the application. With the key ma-terial retrieved by CryptoLint, it was trivially possible todecrypt the encrypted network tra�c.

Bookmark Manager We also investigated a bookmark man-ager application in more detail (install base between 1,000,000and 5,000,000). This application allows the user to synchro-nize bookmarks between di↵erent browsers installed on themobile device. Furthermore, it provides the functionality tosynchronize browser bookmarks with Google’s web services.To make use of this functionality, the user has to provide herGoogle credentials. The application stores these credentialsin a regular Java property file. While the Google user-name isstored in the clear, the password is encrypted. CryptoLint

flagged this application because it uses the DES blockcipherin ECB mode to store that information in the property file.Furthermore, the application also uses a constant key forthe encryption. Again we verified that decryption of thepassword is trivially possible. We agree that safe storage ofaccess credentials is challenging to get right. To this end, An-droid provides a KeyStore facility that is designed for exactly

CryptomisuseinAndroidapps[Egeleetal.,2013]

88%ofappsmadeatleast1mistake

HowAreCryptosystemsA`ackedinPracRce?•  Don’tbotherwiththecrypto;targettheusersinstead–  Socialengineering–  Passwordguessing

•  ExploitbugsormisuseofcryptoAPIsintheimplementaFon–  SSL:gotofail,Heartbleed–  DieboldvoFngmachines:3DESinCBCmodewithNULLIV

•  ExploitmisconfiguraFonsorenvironmentalfactors–  Insufficiententropy,sharedprimes

• DebianOpenSSLbug•  Embeddeddeviceswithoutkeyboard,mouse,real-Fmeclock,etc.

•  Avackthemath–  Flameworm:chosen-prefixcollisionavackagainstMD5 40

9/6/17

21

AddiRonalReferences

•  JonathanKatz’sCourseraclass:hvps://www.coursera.org/course/cryptography

• KPSchapters2–6

41

ReviewofLecture•  Whatdidwelearn?–  HashfuncFons:one-way,collisionresistant,weaklycollisionresistant–  MessageauthenFcaFoncodes–  SecurityproperFes:confidenFality,integrity,authenFcaFon–  Symmetriccrypto–  Publickeycrypto–  CommonwaystomisusecryptoAPIs

•  Sources–  VitalyShmaFkov

•  Deadlinereminder–  Monday:postpilotprojectproposalonPiazza–  Ifyouarenotsurewhattodo,orifyouwanttoproposeatopicthatisnotonthelistfrom

thecoursewebpage,comeseemeduringofficehoursaYerclass

•  What’snext?–  OSprotecFonmechanisms 42