union intersection and refinement types and reasoning
play

Union, Intersection, and Refinement Types and Reasoning about Type - PowerPoint PPT Presentation

Mar 06, 2024 •301 likes •1.39k views

Union, Intersection, and Refinement Types and Reasoning about Type Disjointness for Security Protocol Analysis C t lin Hri cu Prof. Dr. Holger Hermanns (UdS) Dean of Math and CS Faculty Prof. Dr. Gert Smolka (UdS) Chair of Examination

  1. Type-checking protocols k A secret k A only signs pairs for which AliceSends holds & authentic T A = {x : String*Prin | AliceSends x} k A :SigKey(T A ) vk(k A ) : VerKey(T A ) vk(k A ) authentic (also for Bob) m = "Meet@2pm" : String assume (AliceSends (m,Bob)) sign((m,Bob), k A ) y : Un let y = in(net) in (x m ,x b ) : T A if check(y,vk(k A )) ⇓ (x m ,x b ) then {x b == Bob} if x b == Bob then assert (AliceSends (x m ,Bob)) ✓ Intuituion : strong type of k A allows us to “transfer” AliceSends predicate from Alice to Bob [Fournet, Gordon & Ma fg eis, CSF 2007], [Bengtson et. al., CSF 2008]

  2. Advantages of type systems for protocol analysis • modular → efficient and scalable analysis • incremental (type-check while writing the code) • robust to changes • useful error messages (pinpoints location in the code) • both for protocol models ( π ) & implementations ( λ ) • unbounded # of executions by sound approximation

  3. Inherent / incidental limitations • User often needs to write some type annotations • we require the same ( π , inference) or more annotations ( λ ) • Precise protocol analysis requires sophisticated types • we use even more expressive types • Restricted to simple crypto primitives (enc, sign, hash) • no existing type system could handle zero-knowledge proofs • the only previous symbolic analysis for ZK used ProVerif [Backes, Maffei & Unruh, S&P 2008]

  4. Inherent / incidental limitations • User often needs to write some type annotations • we require the same ( π , inference) or more annotations ( λ ) • Precise protocol analysis requires sophisticated types • we use even more expressive types • Restricted to simple crypto primitives (enc, sign, hash) • no existing type system could handle zero-knowledge proofs • the only previous symbolic analysis for ZK used ProVerif [Backes, Maffei & Unruh, S&P 2008] • the first type systems that can handle ZK ( π + λ )

  5. Inherent / incidental limitations • User often needs to write some type annotations • we require the same ( π , inference) or more annotations ( λ ) • Precise protocol analysis requires sophisticated types • we use even more expressive types • Restricted to simple crypto primitives (enc, sign, hash) • no existing type system could handle zero-knowledge proofs • the only previous symbolic analysis for ZK used ProVerif [Backes, Maffei & Unruh, S&P 2008] • the first type systems that can handle ZK ( π + λ )

  6. Inherent / incidental limitations • User often needs to write some type annotations • we require the same ( π , inference) or more annotations ( λ ) • Precise protocol analysis requires sophisticated types • • we use even more expressive types we use even more expressive types • Restricted to simple crypto primitives (enc, sign, hash) • no existing type system could handle zero-knowledge proofs • the only previous symbolic analysis for ZK used ProVerif [Backes, Maffei & Unruh, S&P 2008] • the first type systems that can handle ZK ( π + λ )

  7. Inherent / incidental limitations • User often needs to write some type annotations • • we require the same ( π , inference) or more annotations ( λ ) we require the same ( π , inference) or more annotations ( λ ) • Precise protocol analysis requires sophisticated types • • we use even more expressive types we use even more expressive types • Restricted to simple crypto primitives (enc, sign, hash) • no existing type system could handle zero-knowledge proofs • the only previous symbolic analysis for ZK used ProVerif [Backes, Maffei & Unruh, S&P 2008] • the first type systems that can handle ZK ( π + λ )

  8. 13 emerging applications of zero-knowledge proofs anonymous authentication electronic voting security despite compromise privacy-friendly smart metering privacy-aware anonymous credentials digital identity management decentralized social networks anonymous trust and reputation risk assurance for hedge funds e-cash electronic auctions anonymous electronic ticketing for public transportation biometric authentication

  9. Achieving seemingly conflicting security requirements with ZK + ➔ vote privacy verifiability electronic voting + ➔ protecting digital credentials privacy-enabled identity systems personal information “proving you are over 18 without revealing your age”

  10. Zero-knowledge (symbolically) • Non-interactive zero-knowledge proofs • very powerful crypto primitives • show validity of a statement without revealing the witnesses

  11. Zero-knowledge (symbolically) • Non-interactive zero-knowledge proofs • very powerful crypto primitives • show validity of a statement without revealing the witnesses S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18

  12. Zero-knowledge (symbolically) • Non-interactive zero-knowledge proofs • very powerful crypto primitives • show validity of a statement without revealing the witnesses S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 Prover sign((A,29),k i )

  13. Zero-knowledge (symbolically) • Non-interactive zero-knowledge proofs • very powerful crypto primitives • show validity of a statement without revealing the witnesses S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 Prover Verifier zk S age (29, sign((A,29),k i ); A, vk(k i )) sign((A,29),k i )

  14. Zero-knowledge (symbolically) • Non-interactive zero-knowledge proofs • very powerful crypto primitives • show validity of a statement without revealing the witnesses S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 Prover Verifier zk S age (29, sign((A,29),k i ); A, vk(k i )) sign((A,29),k i )

  15. Zero-knowledge (symbolically) • Non-interactive zero-knowledge proofs • very powerful crypto primitives • show validity of a statement without revealing the witnesses S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 Prover Verifier zk S age (29, sign((A,29),k i ); A, vk(k i )) check(sign((A,29),k i ), vk(k i )) ⇓ (A,29) ∧ 29 ≥ 18 sign((A,29),k i )

  16. Zero-knowledge (symbolically) • Non-interactive zero-knowledge proofs • very powerful crypto primitives • show validity of a statement without revealing the witnesses S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 Prover Verifier zk S age (29, sign((A,29),k i ); A, vk(k i )) ✓ check(sign((A,29),k i ), vk(k i )) ⇓ (A,29) ∧ 29 ≥ 18 sign((A,29),k i )

  17. Zero-knowledge (symbolically) • Non-interactive zero-knowledge proofs • very powerful crypto primitives • show validity of a statement without revealing the witnesses S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 Prover Verifier zk S age (29, sign((A,29),k i ); A, vk(k i )) ✓ check(sign((A,29),k i ), vk(k i )) ⇓ (A,29) ∧ 29 ≥ 18 A vk(k i ) • sign((A,29),k i ) verifier finds out whether the proof is valid or not, and the public arguments

  18. Zero-knowledge (symbolically) • Non-interactive zero-knowledge proofs • very powerful crypto primitives • show validity of a statement without revealing the witnesses S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 Prover Verifier zk S age (29, sign((A,29),k i ); A, vk(k i )) ✓ check(sign((A,29),k i ), vk(k i )) ⇓ (A,29) ∧ 29 ≥ 18 A vk(k i ) • sign((A,29),k i ) verifier finds out whether the proof is valid or not, and the public arguments (zero-knowledge) no other information is revealed about the witnesses (soundness) cannot produce wrong proof that passes verification

  19. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 age = 29 : Private Verifier cert = sign((A,age),k i ) zk S age (age, cert; A, vk(k i ))

  20. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 age = 29 : Private Verifier cert = sign((A,age),k i ) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then

  21. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 age = 29 : Private Verifier cert = sign((A,age),k i ) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  22. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 age = 29 : Private Verifier cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  23. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) age = 29 : Private Verifier cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  24. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) assume IssueId(A,age) age = 29 : Private Verifier cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  25. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) k i : SigKey(T ki ) assume IssueId(A,age) age = 29 : Private Verifier cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  26. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) k i : SigKey(T ki ) T ki ={x : Un*Private | IssueId x} assume IssueId(A,age) age = 29 : Private Verifier cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  27. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) k i : SigKey(T ki ) T ki ={x : Un*Private | IssueId x} Type-checker initially knows: y vki = vk(k i ) assume IssueId(A,age) vk(k i ) : VerKey(T ki ) x age ≥ 18 check(x cert , y vki ) ⇓ (y name ,x age ) age = 29 : Private Verifier cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  28. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) k i : SigKey(T ki ) T ki ={x : Un*Private | IssueId x} Type-checker initially knows: y vki = vk(k i ) assume IssueId(A,age) vk(k i ) : VerKey(T ki ) x age ≥ 18 check(x cert , y vki ) ⇓ (y name ,x age ) Type-checker infers: age = 29 : Private (y name ,x age ) : T ki same as Verifier x age : Private and IssueId(y name ,x age ) cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  29. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) k i : SigKey(T ki ) T ki ={x : Un*Private | IssueId x} Type-checker initially knows: y vki = vk(k i ) assume IssueId(A,age) vk(k i ) : VerKey(T ki ) x age ≥ 18 check(x cert , y vki ) ⇓ (y name ,x age ) Type-checker infers: age = 29 : Private (y name ,x age ) : T ki same as Verifier x age : Private and IssueId(y name ,x age ) cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then ✖ assert (Accept (y name )) Not enough to justify assert!

  30. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) k i : SigKey(T ki ) T ki ={x : Un*Private | IssueId x} Type-checker initially knows: y vki = vk(k i ) assume IssueId(A,age) vk(k i ) : VerKey(T ki ) x age ≥ 18 check(x cert , y vki ) ⇓ (y name ,x age ) Type-checker infers: age = 29 : Private (y name ,x age ) : T ki same as Verifier x age : Private and IssueId(y name ,x age ) cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) zk S age (age, cert’; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then ✖ assert (Accept (y name )) Not enough to justify assert!

  31. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) k i : SigKey(T ki ) T ki ={x : Un*Private | IssueId x} Type-checker initially knows: y vki = vk(k i ) assume IssueId(A,age) vk(k i ) : VerKey(T ki ) x age ≥ 18 check(x cert , y vki ) ⇓ (y name ,x age ) Type-checker infers: age = 29 : Private (y name ,x age ) : T ki same as Verifier x age : Private and IssueId(y name ,x age ) cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) zk S age (age, cert’; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then If proof created by attacker: ✖ assert (Accept (y name )) x age : Un x cert : Un y name : Un Not enough to justify assert! y vki : Un ∧ VerKey(T ki )

  32. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) T ki ={x : Un*Private | IssueId x} Type-checker initially knows: y vki = vk(k i ) It can’t be that x age : Private and x age : Un vk(k i ) : VerKey(T ki ) since Private and Un are disjoint types; x age ≥ 18 so the proof was’n created by attacker check(x cert , y vki ) ⇓ (y name ,x age ) Type-checker infers: age = 29 : Private (y name ,x age ) : T ki same as Verifier x age : Private and IssueId(y name ,x age ) cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then ✖ If proof created by attacker: ✖ assert (Accept (y name )) x age : Un x cert : Un y name : Un Not enough to justify assert! y vki : Un ∧ VerKey(T ki )

  33. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) T ki ={x : Un*Private | IssueId x} Type-checker initially knows: y vki = vk(k i ) It can’t be that x age : Private and x age : Un vk(k i ) : VerKey(T ki ) since Private and Un are disjoint types; x age ≥ 18 so the proof was’n created by attacker check(x cert , y vki ) ⇓ (y name ,x age ) Type-checker infers: age = 29 : Private (y name ,x age ) : T ki same as Verifier x age : Private and IssueId(y name ,x age ) cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in The proof was created by honest participant if ver S age (z, =vk(k i )) ⇓ y name then (ie. type-checked), so we just need to impose ✖ assert (Accept (y name )) more restrictions on ZK proof creation Not enough to justify assert!

  34. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) T ki ={x : Un*Private | IssueId x} T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) Type associated to ZK statement Type-checker infers: age = 29 : Private (y name ,x age ) : T ki same as Verifier x age : Private and IssueId(y name ,x age ) cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in The proof was created by honest participant if ver S age (z, =vk(k i )) ⇓ y name then (ie. type-checked), so we just need to impose ✖ assert (Accept (y name )) more restrictions on ZK proof creation Not enough to justify assert!

  35. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) T ki ={x : Un*Private | IssueId x} T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) Type associated to ZK statement Check this formula whenever honest participant creates ZK proof Type-checker infers: age = 29 : Private (y name ,x age ) : T ki same as Verifier x age : Private and IssueId(y name ,x age ) cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in The proof was created by honest participant if ver S age (z, =vk(k i )) ⇓ y name then (ie. type-checked), so we just need to impose ✖ assert (Accept (y name )) more restrictions on ZK proof creation Not enough to justify assert!

  36. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) T ki ={x : Un*Private | IssueId x} T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) Type associated to ZK statement Check this formula whenever honest participant creates ZK proof Type-checker infers: age = 29 : Private (y name ,x age ) : T ki same as Verifier ✓ x age : Private and IssueId(y name ,x age ) cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in The proof was created by honest participant if ver S age (z, =vk(k i )) ⇓ y name then (ie. type-checked), so we just need to impose ✖ assert (Accept (y name )) more restrictions on ZK proof creation Not enough to justify assert!

  37. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) T ki ={x : Un*Private | IssueId x} T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) Type associated to ZK statement Check this formula whenever honest participant creates ZK proof Type-checker infers: age = 29 : Private (y name ,x age ) : T ki same as Verifier ✓ x age : Private and IssueId(y name ,x age ) cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in The proof was created by honest participant if ver S age (z, =vk(k i )) ⇓ y name then (ie. type-checked), so we just need to impose assert (Accept (y name )) more restrictions on ZK proof creation Assume (existentially quantified) formula if verification succeeds

  38. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) T ki ={x : Un*Private | IssueId x} T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) Type associated to ZK statement Check this formula whenever honest participant creates ZK proof Type-checker infers: age = 29 : Private (y name ,x age ) : T ki same as Verifier ✓ x age : Private and IssueId(y name ,x age ) cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in The proof was created by honest participant if ver S age (z, =vk(k i )) ⇓ y name then ✓ (ie. type-checked), so we just need to impose assert (Accept (y name )) more restrictions on ZK proof creation Assume (existentially quantified) formula if verification succeeds

  39. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : Un*Private | IssueId x} k i : SigKey(T ki ) age = 29 : Private Verifier cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  40. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : Un*Private | IssueId x} k i : SigKey(T ki ) age = 29 : Private Verifier cert = sign((A,age),k i ) assume ProverSends(A,age) zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  41. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : Un*Private | IssueId x} k i : SigKey(T ki ) age = 29 : Private Verifier cert = sign((A,age),k i ) age cert let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  42. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : Un*Private | IssueId x} k i : SigKey(T ki ) This needs to change age = 29 : Private Verifier cert = sign((A,age),k i ) age cert let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  43. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : Un*Private | IssueId x} PrivateUnless(A) = {Private | ¬ Comp(A)} ∨ {Un | Comp(A)} k i : SigKey(T ki ) This needs to change age = 29 : PrivateUnless(A) Verifier cert = sign((A,age),k i ) assume (Comp(A)) age cert let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  44. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) Snowball effect T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : (x name : Un * PrivateUnless(x name )) | IssueId x} PrivateUnless(A) = {Private | ¬ Comp(A)} ∨ {Un | Comp(A)} k i : SigKey(T ki ) This needs to change age = 29 : PrivateUnless(A) Verifier cert = sign((A,age),k i ) assume (Comp(A)) age cert let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  45. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) Snowball effect T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : (x name : Un * PrivateUnless(x name )) | IssueId x} PrivateUnless(A) = {Private | ¬ Comp(A)} ∨ {Un | Comp(A)} k i : SigKey(T ki ) This needs to change age = 29 : PrivateUnless(A) Verifier cert = sign((A,age),k i ) assume (Comp(A)) age cert zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  46. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) Snowball effect T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : (x name : Un * PrivateUnless(x name )) | IssueId x} PrivateUnless(A) = {Private | ¬ Comp(A)} ∨ {Un | Comp(A)} k i : SigKey(T ki ) This needs to change age = 29 : PrivateUnless(A) Verifier cert = sign((A,age),k i ) assume (Comp(A)) age cert zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then ✖ assert (Accept (y name )) Failed assert - no ProverSends...

  47. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) Snowball effect T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : (x name : Un * PrivateUnless(x name )) | IssueId x} PrivateUnless(A) = {Private | ¬ Comp(A)} ∨ {Un | Comp(A)} k i : SigKey(T ki ) This needs to change age = 29 : PrivateUnless(A) Verifier cert = sign((A,age),k i ) assume (Comp(A)) age cert zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then ✖ Attacker following protocol assert (Accept (y name )) (not real attack) Failed assert - no ProverSends...

  48. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) weaken policy assume (Comp(y name ) ⇒ ∀ x age . ProverSends(y name ,x age )) T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : (x name : Un * PrivateUnless(x name )) | IssueId x} PrivateUnless(A) = {Private | ¬ Comp(A)} ∨ {Un | Comp(A)} k i : SigKey(T ki ) age = 29 : PrivateUnless(A) Verifier cert = sign((A,age),k i ) assume (Comp(A)) age cert zk S age (age, cert; A, vk(k i )) let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then ✖ Attacker following protocol assert (Accept (y name )) (not real attack) Failed assert - no ProverSends...

  49. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) weaken policy assume (Comp(y name ) ⇒ ∀ x age . ProverSends(y name ,x age )) T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : (x name : Un * PrivateUnless(x name )) | IssueId x} PrivateUnless(A) = {Private | ¬ Comp(A)} ∨ {Un | Comp(A)} k i : SigKey(T ki ) Inferred types conditioned by other types not being compromised x age : {|fkind(T ki , tnt)|} ∨ {x age : PrivateUnless(A) | IssueId(y name ,x age )} age = 29 : PrivateUnless(A) Verifier cert = sign((A,age),k i ) assume (Comp(A)) age cert let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  50. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) weaken policy assume (Comp(y name ) ⇒ ∀ x age . ProverSends(y name ,x age )) T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : (x name : Un * PrivateUnless(x name )) | IssueId x} PrivateUnless(A) = {Private | ¬ Comp(A)} ∨ {Un | Comp(A)} k i : SigKey(T ki ) Inferred types conditioned by other types not being compromised x age : {|fkind(T ki , tnt)|} ∨ {x age : PrivateUnless(A) | IssueId(y name ,x age )} age = 29 : PrivateUnless(A) Verifier cert = sign((A,age),k i ) false because of IssueId assume (Comp(A)) age (issuer is not compromised) cert let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  51. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) weaken policy assume (Comp(y name ) ⇒ ∀ x age . ProverSends(y name ,x age )) T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : (x name : Un * PrivateUnless(x name )) | IssueId x} PrivateUnless(A) = {Private | ¬ Comp(A)} ∨ {Un | Comp(A)} k i : SigKey(T ki ) Inferred types conditioned by other types not being compromised x age : {|fkind(T ki , tnt)|} ∨ {x age : PrivateUnless(A) | IssueId(y name ,x age )} age = 29 : PrivateUnless(A) Verifier cert = sign((A,age),k i ) false because of IssueId case analysis on Comp(A) assume (Comp(A)) age (issuer is not compromised) cert let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then assert (Accept (y name ))

  52. S age = witness x age , x cert public y name ,y vki , in check(x cert , y vki ) ⇓ (y name ,x age ) ∧ x age ≥ 18 assume ( ∀ y name ,x age . ProverSends(y name ,x age ) ∧ IssueId(y name ,x age ) ∧ x age ≥ 18 ⇒ Accept(x name )) weaken policy assume (Comp(y name ) ⇒ ∀ x age . ProverSends(y name ,x age )) T S age =ZKProof(... ∃ x age ,x cert . ProverSends(y name ,x age )...) T ki ={x : (x name : Un * PrivateUnless(x name )) | IssueId x} PrivateUnless(A) = {Private | ¬ Comp(A)} ∨ {Un | Comp(A)} k i : SigKey(T ki ) Inferred types conditioned by other types not being compromised x age : {|fkind(T ki , tnt)|} ∨ {x age : PrivateUnless(A) | IssueId(y name ,x age )} age = 29 : PrivateUnless(A) Verifier cert = sign((A,age),k i ) false because of IssueId case analysis on Comp(A) assume (Comp(A)) age (issuer is not compromised) cert let z = in(net) in if ver S age (z, =vk(k i )) ⇓ y name then ✓ assert (Accept (y name )) Protocol robustly safe even when A compromised

  53. Reasoning about Type Disjointness New ! • Syntactically derive type disjointness information

  54. Reasoning about Type Disjointness New ! • Syntactically derive type disjointness information tree � α � = µβ. α + α ∗ β ∗ β

  55. Reasoning about Type Disjointness New ! • Syntactically derive type disjointness information tree � α � = µβ. α + α ∗ β ∗ β Private # Un Private ∗ tree � Private � ∗ tree � Private � # Un ∗ tree � Un � ∗ tree � Un � Private # Un Private + Private ∗ tree � Private � ∗ tree � Private � # Un + Un ∗ tree � Un � ∗ tree � Un � µβ. Private + Private ∗ β ∗ β # µβ. Un + Un ∗ β ∗ β tree � Private � # Un

  56. Reasoning about Type Disjointness New ! • Syntactically derive type disjointness information tree � α � = µβ. α + α ∗ β ∗ β Private # Un Private ∗ tree � Private � ∗ tree � Private � # Un ∗ tree � Un � ∗ tree � Un � Private # Un Private + Private ∗ tree � Private � ∗ tree � Private � # Un + Un ∗ tree � Un � ∗ tree � Un � µβ. Private + Private ∗ β ∗ β # µβ. Un + Un ∗ β ∗ β tree � Private � # Un • More powerful non-disjointness judgement If T 1 overlaps with T 2 E ⊢ T 1 � � T 2 � F then formula F holds

  57. Reasoning about Type Disjointness New ! • Syntactically derive type disjointness information tree � α � = µβ. α + α ∗ β ∗ β Private # Un Private ∗ tree � Private � ∗ tree � Private � # Un ∗ tree � Un � ∗ tree � Un � Private # Un Private + Private ∗ tree � Private � ∗ tree � Private � # Un + Un ∗ tree � Un � ∗ tree � Un � µβ. Private + Private ∗ β ∗ β # µβ. Un + Un ∗ β ∗ β tree � Private � # Un • More powerful non-disjointness judgement If T 1 overlaps with T 2 E ⊢ T 1 � � T 2 � F then formula F holds Disjointness encoded T 1 # T 2 � ⊢ T 1 � � T 2 � false

  58. Reasoning about Type Disjointness New ! • Syntactically derive type disjointness information tree � α � = µβ. α + α ∗ β ∗ β Private # Un Private ∗ tree � Private � ∗ tree � Private � # Un ∗ tree � Un � ∗ tree � Un � Private # Un Private + Private ∗ tree � Private � ∗ tree � Private � # Un + Un ∗ tree � Un � ∗ tree � Un � µβ. Private + Private ∗ β ∗ β # µβ. Un + Un ∗ β ∗ β tree � Private � # Un • More powerful non-disjointness judgement If T 1 overlaps with T 2 E ⊢ T 1 � � T 2 � F then formula F holds Disjointness encoded T 1 # T 2 � ⊢ T 1 � � T 2 � false Our base case is security-specific ( ⊢ PrivateUnless F � � Un � F ) but the inductive cases are not.

  59. Models ( π ) Implementations ( λ )

  60. Models ( π ) Implementations ( λ ) concurrent λ -calculus (RCF); ML core spi calculus variant

  61. Models ( π ) Implementations ( λ ) concurrent λ -calculus (RCF); ML core spi calculus variant encryption, signatures, hashes, blind signatur hashes, blind signatures, zero-knowledge

  62. Models ( π ) Implementations ( λ ) concurrent λ -calculus (RCF); ML core spi calculus variant encryption, signatures, hashes, blind signatur hashes, blind signatures, zero-knowledge constructors and destructors crypto encoded using dynamic sealing

  63. Models ( π ) Implementations ( λ ) concurrent λ -calculus (RCF); ML core spi calculus variant encryption, signatures, hashes, blind signatur hashes, blind signatures, zero-knowledge constructors and destructors crypto encoded using dynamic sealing efinement {x : T | C}, dependent pair ( Σ ) types union ( ∨ ), intersection ( ∧ ), refinement {x :

  64. Models ( π ) Implementations ( λ ) concurrent λ -calculus (RCF); ML core spi calculus variant encryption, signatures, hashes, blind signatur hashes, blind signatures, zero-knowledge constructors and destructors crypto encoded using dynamic sealing efinement {x : T | C}, dependent pair ( Σ ) types union ( ∨ ), intersection ( ∧ ), refinement {x : + dependent function ( Π ), sum (+), iso- + lots of crypto-specific types recursive ( μ ), polymorphic ( ∀ ) types

  65. Models ( π ) Implementations ( λ ) concurrent λ -calculus (RCF); ML core spi calculus variant encryption, signatures, hashes, blind signatur hashes, blind signatures, zero-knowledge constructors and destructors crypto encoded using dynamic sealing efinement {x : T | C}, dependent pair ( Σ ) types union ( ∨ ), intersection ( ∧ ), refinement {x : + dependent function ( Π ), sum (+), iso- + lots of crypto-specific types recursive ( μ ), polymorphic ( ∀ ) types first-order authorization logic der authorization logic

  66. Models ( π ) Implementations ( λ ) concurrent λ -calculus (RCF); ML core spi calculus variant encryption, signatures, hashes, blind signatur hashes, blind signatures, zero-knowledge constructors and destructors crypto encoded using dynamic sealing efinement {x : T | C}, dependent pair ( Σ ) types union ( ∨ ), intersection ( ∧ ), refinement {x : + dependent function ( Π ), sum (+), iso- + lots of crypto-specific types recursive ( μ ), polymorphic ( ∀ ) types first-order authorization logic der authorization logic reasoning about type disjointness (#) easoning about type disjointness (#)

  67. Models ( π ) Implementations ( λ ) concurrent λ -calculus (RCF); ML core spi calculus variant encryption, signatures, hashes, blind signatur hashes, blind signatures, zero-knowledge constructors and destructors crypto encoded using dynamic sealing efinement {x : T | C}, dependent pair ( Σ ) types union ( ∨ ), intersection ( ∧ ), refinement {x : + dependent function ( Π ), sum (+), iso- + lots of crypto-specific types recursive ( μ ), polymorphic ( ∀ ) types first-order authorization logic der authorization logic reasoning about type disjointness (#) easoning about type disjointness (#) logical kinding&subtyping (novel) inductive kinding&subtyping (standard)

  68. Models ( π ) Implementations ( λ ) concurrent λ -calculus (RCF); ML core spi calculus variant encryption, signatures, hashes, blind signatur hashes, blind signatures, zero-knowledge constructors and destructors crypto encoded using dynamic sealing efinement {x : T | C}, dependent pair ( Σ ) types union ( ∨ ), intersection ( ∧ ), refinement {x : + dependent function ( Π ), sum (+), iso- + lots of crypto-specific types recursive ( μ ), polymorphic ( ∀ ) types first-order authorization logic der authorization logic reasoning about type disjointness (#) easoning about type disjointness (#) logical kinding&subtyping (novel) inductive kinding&subtyping (standard) statement-based inference for ZK code generation from ZK statement

  69. Models ( π ) Implementations ( λ ) concurrent λ -calculus (RCF); ML core spi calculus variant encryption, signatures, hashes, blind signatur hashes, blind signatures, zero-knowledge constructors and destructors crypto encoded using dynamic sealing efinement {x : T | C}, dependent pair ( Σ ) types union ( ∨ ), intersection ( ∧ ), refinement {x : + dependent function ( Π ), sum (+), iso- + lots of crypto-specific types recursive ( μ ), polymorphic ( ∀ ) types first-order authorization logic der authorization logic reasoning about type disjointness (#) easoning about type disjointness (#) logical kinding&subtyping (novel) inductive kinding&subtyping (standard) statement-based inference for ZK code generation from ZK statement type-checker is extensible, proof is not extending type system requires no proof

  70. Formalization and Proofs • Formalized definitions in Coq + “partial formal proofs” Coq + ( π ) 17kLOC (2.9kLOC of definitions -- 250 rules) Ott + ( λ ) 14kLOC (1.5kLOC of definitions -- 135 rules) LNGen • Found and fixed bugs in our previous definitions and in published “convincing paper proofs” partial vigorous convincing axiom-free no proofs formal proofs formal proofs handwaving paper proofs

  71. Formalization and Proofs • Formalized definitions in Coq + “partial formal proofs” Coq + ( π ) 17kLOC (2.9kLOC of definitions -- 250 rules) Ott + ( λ ) 14kLOC (1.5kLOC of definitions -- 135 rules) LNGen • Found and fixed bugs in our previous definitions and in published “convincing paper proofs” partial vigorous convincing axiom-free no proofs formal proofs formal proofs handwaving paper proofs • Shortly before Christmas Matteo found a bug in weakening for statement-based inference ( π ) • fix required significant change to subtyping (inductive+logical → just logical) • still working on updating all the proofs (will finish that for final version of thesis)

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend

Towards a Logical Framework with Intersection and Union Types Claude Stolze Luigi Liquori

Towards a Logical Framework with Intersection and Union Types Claude Stolze Luigi Liquori

Towards a Logical Framework with Intersection and Union Types Claude Stolze Luigi Liquori INRIA Sophia-Antipolis Mditerrane, France Furio Honsell Ivan Scagnetto Universit di Udine, Italy Plan of the talk Proof functional logics

820 views • 59 slides
Computational and Fine-Structure Aspects of Intersection Types A personal encounter with

Computational and Fine-Structure Aspects of Intersection Types A personal encounter with

Computational and Fine-Structure Aspects of Intersection Types A personal encounter with intersection types Jakob Rehof Technische Universit at Dortmund TLT Types and Logic in Torino Colloquium in honor of Mariangiola

2.47k views • 90 slides
Refinement Calculus for Compositional System Reasoning Viorel Preoteasa Joint work with Stavros

Refinement Calculus for Compositional System Reasoning Viorel Preoteasa Joint work with Stavros

Relational Interfaces and Refinement Calculus for Compositional System Reasoning Viorel Preoteasa Joint work with Stavros Tripakis and Iulia Dragomir 08.12.2015 Computational Logic Day 2015 1 Overview Motivation General refinement

341 views • 20 slides
Rank 3 Inhabitation of Intersection Types Revisited Andrej Dudenhefner Jan Bessai Boris D

Rank 3 Inhabitation of Intersection Types Revisited Andrej Dudenhefner Jan Bessai Boris D

Rank 3 Inhabitation of Intersection Types Revisited Andrej Dudenhefner Jan Bessai Boris D udder Jakob Rehof Technical University of Dortmund, Germany May 20, 2016 1 / 26 Contents Intersection Type System 1 Intersection Type

408 views • 26 slides
Refinement Types for Algebraic Effects Danel Ahman Gordon Plotkin LFCS, University of

Refinement Types for Algebraic Effects Danel Ahman Gordon Plotkin LFCS, University of

Refinement Types for Algebraic Effects Danel Ahman Gordon Plotkin LFCS, University of Edinburgh TYPES 2015 Tallinn Todays plan Value ref. types Computation ref. types Algebraic theories Value

368 views • 21 slides
Fast Evaluation of Union-Intersection Expressions Philip Bille Anna Pagh Rasmus Pagh IT

Fast Evaluation of Union-Intersection Expressions Philip Bille Anna Pagh Rasmus Pagh IT

Fast Evaluation of Union-Intersection Expressions Philip Bille Anna Pagh Rasmus Pagh IT University of Copenhagen Data Structures for Intersection Queries Preprocess a collection of sets independently into a representation

430 views • 12 slides
Motivation behind SOSL - intersection - union - complement - in - cardinality Special

Motivation behind SOSL - intersection - union - complement - in - cardinality Special

Motivation behind SOSL - intersection - union - complement - in - cardinality Special operators Simplification of set Make it easy to for set-related theory operations manipulate sets functions - addition - subtraction -

285 views • 10 slides
1. Short answers: (a) Define the following terms and concepts: i. Union, intersection, set

1. Short answers: (a) Define the following terms and concepts: i. Union, intersection, set

2 CS 341 Practice Final 1. Short answers: (a) Define the following terms and concepts: i. Union, intersection, set concatenation, Kleene-star, set CS 341 Practice Final subtraction, complement Answer: Union: S T = { x | x S or x T

428 views • 13 slides
Type Reconstruction for General Refinement Types Kenn Knowles University of California, Santa

Type Reconstruction for General Refinement Types Kenn Knowles University of California, Santa

Type Reconstruction for General Refinement Types Kenn Knowles University of California, Santa Cruz joint work with: Cormac Flanagan (University of California, Santa Cruz) March 25, 2007 Assertions / Refinement Types The role of assertions in

386 views • 37 slides
Refactoring, Refinement, and Reasoning A Logical Characterization for Hybrid Systems Stefan Mitsch

Refactoring, Refinement, and Reasoning A Logical Characterization for Hybrid Systems Stefan Mitsch

Introduction Refactoring Refactoring Operations Conclusion Refactoring, Refinement, and Reasoning A Logical Characterization for Hybrid Systems Stefan Mitsch 1 , 2 Jan-David Quesel 1 e Platzer 1 Andr 1 Computer Science Department, Carnegie

451 views • 32 slides
Higher-Order Approximate Relational Refinement Types for Mechanism Design and Differential

Higher-Order Approximate Relational Refinement Types for Mechanism Design and Differential

Higher-Order Approximate Relational Refinement Types for Mechanism Design and Differential Privacy Gilles Barthe, Marco Gaboardi, Emilio Jess Gallego Arias, Justin Hsu, Aaron Roth, Pierre-Yves Strub UPenn-Mines ParisTech, IMDEA Software

905 views • 89 slides
Colored intersection types: a bridge between linear logic and higher-order model-checking Charles

Colored intersection types: a bridge between linear logic and higher-order model-checking Charles

Colored intersection types: a bridge between linear logic and higher-order model-checking Charles Grellois (joint work with Paul-Andr e Melli` es) PPS & LIAFA Universit e Paris 7 TYPES conference May 18th, 2015 Charles

549 views • 35 slides
CS 671 Automated Reasoning Extending Nuprls Type Theory 1. Design Decisions for Nuprls Type

CS 671 Automated Reasoning Extending Nuprls Type Theory 1. Design Decisions for Nuprls Type

CS 671 Automated Reasoning Extending Nuprls Type Theory 1. Design Decisions for Nuprls Type Theory 2. Product, Union, and List Types 3. The Curry-Howard Isomorphism, formally 4. Empty and Unit Types Design Decisions for Nuprls Type Theory

556 views • 8 slides
Rank-2 Intersection Types for Cost Analysis of Functional Programs oes 1 Kevin Hammond 1 ario

Rank-2 Intersection Types for Cost Analysis of Functional Programs oes 1 Kevin Hammond 1 ario

Rank-2 Intersection Types for Cost Analysis of Functional Programs oes 1 Kevin Hammond 1 ario Florido 2 Hugo R. Sim M Pedro B. Vasconcelos 1 1 University of St Andrews 2 Universidade do Porto TYPES, 2006 Motivation For doing cost analysis

431 views • 23 slides
Intersection Safety Intersection Safety Intersection Safety Intersections Intersections

Intersection Safety Intersection Safety Intersection Safety Intersections Intersections

Intersection Safety Intersection Safety Intersection Safety Intersections Intersections Among the most hazardous components of the highway system for all users (planned points of conflict) Complex speed-distance judgments under time

601 views • 24 slides
Higher-Order Relational Refinement Types for Mechanism Design and Differential Privacy Gilles

Higher-Order Relational Refinement Types for Mechanism Design and Differential Privacy Gilles

Higher-Order Relational Refinement Types for Mechanism Design and Differential Privacy Gilles Barthe 1 , Marco Gaboardi 2 , Emilio Jess Gallego Arias 3 , 4 , Justin Hsu 4 , Aaron Roth 4 , Pierre-Yves Strub 1 1 IMDEA Software, 2 University of

1.16k views • 77 slides
Multi-Signatures for Blockchains Yannick Seurin Agence nationale de la scurit des systmes

Multi-Signatures for Blockchains Yannick Seurin Agence nationale de la scurit des systmes

Multi-Signatures for Blockchains Yannick Seurin Agence nationale de la scurit des systmes dinformation June 12, 2019 LINCS Blockchain Day Y. Seurin (ANSSI) Multi-Signatures for Blockchains 12/06/2019 1 / 17 Uses of cryptography

921 views • 68 slides
Privacy-preserving electronic civic infrastructure Andrew J. Blumberg

Privacy-preserving electronic civic infrastructure Andrew J. Blumberg

Privacy-preserving electronic civic infrastructure Andrew J. Blumberg (blumberg@math.utexas.edu) Andrew J. Blumberg (blumberg@math.utexas.edu) Privacy-preserving electronic civic infrastructure Objective: design potentially invasive

532 views • 24 slides
Proving tight security for Rabin-Williams signatures D. J. Bernstein Public-key signatures 1976

Proving tight security for Rabin-Williams signatures D. J. Bernstein Public-key signatures 1976

Proving tight security for Rabin-Williams signatures D. J. Bernstein Public-key signatures 1976 Diffie Hellman: Public-key signatures would allow verification by anyone, not just signer. Cool! Can we build a signature system? 1977 Rivest

743 views • 33 slides
NAME-ES 20 novembre 2002 Yves Leroux, David Ankri, Fabrice Scemama SISGEM Agenda Why NAME

NAME-ES 20 novembre 2002 Yves Leroux, David Ankri, Fabrice Scemama SISGEM Agenda Why NAME

STORCK 2002 conference IST project :Smart IS Accompanying Measure NAME-ES 20 novembre 2002 Yves Leroux, David Ankri, Fabrice Scemama SISGEM Agenda Why NAME and NAME-ES ? Different perspectives about signature Cryptographic

471 views • 9 slides
Low-Rank Decomposition of Multi-Way Arrays: A Signal Processing Perspective Nikos Sidiropoulos

Low-Rank Decomposition of Multi-Way Arrays: A Signal Processing Perspective Nikos Sidiropoulos

TUC & UMN Nikos Sidiropoulos / SAM 2004, July 18-21, 2004, Sitges, Barcelona, Spain Low-Rank Decomposition of Multi-Way Arrays: A Signal Processing Perspective Nikos Sidiropoulos Dept. ECE, TUC-Greece & UMN-U.S.A

796 views • 35 slides
The Forgotten Art of Anonymous Digital Cash Jonathan Smuggler Logan Before the Chains

The Forgotten Art of Anonymous Digital Cash Jonathan Smuggler Logan Before the Chains

The Forgotten Art of Anonymous Digital Cash Jonathan Smuggler Logan Before the Chains Blockchain currencies were not the first digital non-government money The past is widely forgotten Im here from the past or from

402 views • 23 slides
Cryptography Crash Course Symmetric Key Cryptography School on Secure IoT, 2016 Dr. Ir. Jens

Cryptography Crash Course Symmetric Key Cryptography School on Secure IoT, 2016 Dr. Ir. Jens

Cryptography Crash Course Symmetric Key Cryptography School on Secure IoT, 2016 Dr. Ir. Jens Hermans KU Leuven/COSIC Cryptology: basic principles Eve Alice Bob CRYP CRYP Clear Clear %^C& %^C& TOB TOB @&^( @&^(

1.32k views • 119 slides
Can Charlie distinguish Alice and Bob? Automated verification of equivalence properties Steve

Can Charlie distinguish Alice and Bob? Automated verification of equivalence properties Steve

Can Charlie distinguish Alice and Bob? Automated verification of equivalence properties Steve Kremer joint work with: Myrto Arapinis, David Baelde, Rohit Chadha, Vincent Cheval, S tefan Ciob ac a, V eronique Cortier, St ephanie

1.09k views • 87 slides

More recommend