cryptography  

Messages by Thread

• • SSL use Anne & Lynn Wheeler
  • Re: User interface, security, and "simplicity" Peter Gutmann
  • Re: User interface, security, and "simplicity" Perry E. Metzger
  • Re: User interface, security, and "simplicity" Jeff Simmons
  • Re: User interface, security, and "simplicity" Steven M. Bellovin
  • Re: User interface, security, and "simplicity" Perry E. Metzger
  • Re: User interface, security, and "simplicity" Thor Lancelot Simon
  • Re: User interface, security, and "simplicity" Perry E. Metzger
  • Re: User interface, security, and "simplicity" James A. Donald
  • Re: User interface, security, and "simplicity" Thor Lancelot Simon
  • Re: User interface, security, and "simplicity" Victor Duchovni
  • Re: User interface, security, and "simplicity" Steven M. Bellovin
  • Re: User interface, security, and "simplicity" Jack Lloyd
  • Re: User interface, security, and "simplicity" Nicolas Williams
  • Re: User interface, security, and "simplicity" Ben Laurie
  • Re: User interface, security, and "simplicity" Steven M. Bellovin
  • Re: User interface, security, and "simplicity" Ray Dillinger
  • Re: User interface, security, and "simplicity" James A. Donald
  • Re: User interface, security, and "simplicity" Jacob Appelbaum
  • Re: User interface, security, and "simplicity" Perry E. Metzger
  • Re: User interface, security, and "simplicity" Ian G
  • Re: User interface, security, and "simplicity" Ed Gerck
  • User interface, security, and "simplicity" David Wagner
  • Re: User interface, security, and "simplicity" Victor Duchovni
  • Re: User interface, security, and "simplicity" Ian G
  • Re: User interface, security, and "simplicity" James A. Donald
  • Re: User interface, security, and "simplicity" Victor Duchovni
  • Re: User interface, security, and "simplicity" Peter Gutmann
• Interesting attack vector Peter Gutmann
• Pentagon looks for 'Killer Switch' Ali, Saqib
• Microsoft COFEE Arshad Noor
  • Re: Microsoft COFEE Adam Shostack
  • RE: Microsoft COFEE Dave Korn
• Shor's algorithm in danger? Rod Van Meter
• Re: Just update the microcode (was: Re: defending against evil in all layers of hardware and software) alex
  • Re: Just update the microcode (was: Re: defending against evil in all layers of hardware and software) John Ioannidis
• SSL and Malicious Hardware/Software Ryan Phillips
  • Re: SSL and Malicious Hardware/Software Victor Duchovni
  • Re: SSL and Malicious Hardware/Software Jack Lloyd
  • privacy expectations Was: SSL and Malicious Hardware/Software Alexander Klimov
  • Re: privacy expectations Was: SSL and Malicious Hardware/Software Steven M. Bellovin
  • Re: SSL and Malicious Hardware/Software Leichter, Jerry
  • Re: SSL and Malicious Hardware/Software Arcane Jill
  • Re: SSL and Malicious Hardware/Software Steven M. Bellovin
  • Re: SSL and Malicious Hardware/Software Peter Thoenen
  • Re: SSL and Malicious Hardware/Software Arcane Jill
• Doubts about efficiency of Shor's factoring algorithm in quantum computers Charles McElwain
  • Re: Doubts about efficiency of Shor's factoring algorithm in quantum computers Perry E. Metzger
  • Re: Doubts about efficiency of Shor's factoring algorithm in quantum computers Ray Perlner
• matt blaze on evil hardware Perry E. Metzger
• more on malicious hardware Perry E. Metzger
  • Re: more on malicious hardware Karsten Nohl
  • RE: more on malicious hardware Scott Guthery
  • Re: more on malicious hardware Allen
  • Re: more on malicious hardware Peter Gutmann
• "Designing and implementing malicious hardware" Perry E. Metzger
  • Re: "Designing and implementing malicious hardware" Jacob Appelbaum
  • Re: "Designing and implementing malicious hardware" Leichter, Jerry
  • Re: "Designing and implementing malicious hardware" Anne & Lynn Wheeler
  • Re: "Designing and implementing malicious hardware" Ivan Krstić
  • Re: "Designing and implementing malicious hardware" John Gilmore
  • Re: "Designing and implementing malicious hardware" Karsten Nohl
  • Re: "Designing and implementing malicious hardware" Adam Fields
  • Re: "Designing and implementing malicious hardware" Leichter, Jerry
  • Re: "Designing and implementing malicious hardware" Ed Gerck
  • Re: "Designing and implementing malicious hardware" Perry E. Metzger
  • Re: "Designing and implementing malicious hardware" Ed Gerck
  • Re: "Designing and implementing malicious hardware" Perry E. Metzger
  • Re: "Designing and implementing malicious hardware" Ed Gerck
  • Re: "Designing and implementing malicious hardware" Perry E. Metzger
  • Re: "Designing and implementing malicious hardware" Leichter, Jerry
  • Re: "Designing and implementing malicious hardware" James A. Donald
  • defending against evil in all layers of hardware and software John Denker
  • Re: defending against evil in all layers of hardware and software Perry E. Metzger
  • Just update the microcode (was: Re: defending against evil in all layers of hardware and software) John Ioannidis
  • Re: Just update the microcode (was: Re: defending against evil in all layers of hardware and software) Sebastian Krahmer
  • Re: defending against evil in all layers of hardware and software Stephan Neuhaus
  • Re: defending against evil in all layers of hardware and software Perry E. Metzger
  • Re: defending against evil in all layers of hardware and software Ivan Krstić
  • Re: defending against evil in all layers of hardware and software Ivan Krstić
  • Re: defending against evil in all layers of hardware and software Jonathan Thornburg
  • Re: "Designing and implementing malicious hardware" COMINT
  • OpenSparc -- the open source chip (except for the crypto parts) zooko
  • Re: OpenSparc -- the open source chip (except for the crypto parts) Alexander Klimov
  • Re: OpenSparc -- the open source chip (except for the crypto parts) Marcos el Ruptor
  • Re: OpenSparc -- the open source chip (except for the crypto parts) Perry E. Metzger
  • Re: OpenSparc -- the open source chip (except for the crypto parts) Eric Rescorla
  • Re: OpenSparc -- the open source chip (except for the crypto parts) Florian Weimer
  • Re: OpenSparc -- the open source chip (except for the crypto parts) Perry E. Metzger
  • Re: OpenSparc -- the open source chip (except for the crypto parts) Ben Laurie
  • Re: OpenSparc -- the open source chip (except for the crypto parts) Perry E. Metzger
  • Re: [mm] OpenSparc -- the open source chip (except for the crypto parts) Ben Laurie
  • Re: OpenSparc -- the open source chip (except for the crypto parts) James A. Donald
  • Re: OpenSparc -- the open source chip (except for the crypto parts) Jon Callas
  • Re: OpenSparc -- the open source chip (except for the crypto parts) Matt Blaze
  • RE: OpenSparc -- the open source chip (except for the crypto parts) Scott Guthery
  • Re: OpenSparc -- the open source chip (except for the crypto parts) James A. Donald
  • RE: "Designing and implementing malicious hardware" Crawford Nathan-HMGT87
• Declassified NSA publications Steven M. Bellovin
  • Re: Declassified NSA publications Leichter, Jerry
  • Re: Declassified NSA publications Ilya Levin
• [Fwd: Secure Server e-Cert & Developer e-Cert. Comerica TM Connect Web Bank] Arshad Noor
  • Re: [Fwd: Secure Server e-Cert & Developer e-Cert. Comerica TM Connect Web Bank] Arshad Noor
  • Re: [Fwd: Secure Server e-Cert & Developer e-Cert. Comerica TM Connect Web Bank] Thierry Moreau
  • Re: [Fwd: Secure Server e-Cert & Developer e-Cert. Comerica TM Connect Web Bank] Peter Gutmann
• Re: Estimated 10 million dollars lost in parking meter fraud James Muir
• quantum cryptography broken? travis+ml-cryptography
• Re: Cruising the stacks and finding stuff Victor Duchovni
  • Re: Cruising the stacks and finding stuff Perry E. Metzger
  • Re: Cruising the stacks and finding stuff Leichter, Jerry
  • Re: Cruising the stacks and finding stuff Allen
  • Re: Cruising the stacks and finding stuff Perry E. Metzger
  • Re: Cruising the stacks and finding stuff Jack Lloyd
  • Re: Cruising the stacks and finding stuff Sandy Harris
  • no possible brute force Was: Cruising the stacks and finding stuff Alexander Klimov
  • Re: no possible brute force Was: Cruising the stacks and finding stuff Leichter, Jerry
  • Re: Cruising the stacks and finding stuff Sandy Harris
  • Re: Cruising the stacks and finding stuff Ian G
• TextTell - 1983 - Encrypted Text Transmission Nap van Zuuren
• Mark Dowd's Flash NULL Pointer Vulnerability Exploit Ryan Phillips
• New results against the Mifare cipher Peter Gutmann
• Snake oil crypto of the day: BabelSecure Samurai Ali, Saqib
  • Re: Snake oil crypto of the day: BabelSecure Samurai james hughes
• Pi, randomness, entropy, unpredictability travis+ml-cryptography
• Double Encryption Q COMINT
  • Re: Double Encryption Q Jack Lloyd
  • Re: Double Encryption Q Pehr Söderman
  • Re: Double Encryption Q Martin James Cochran
• 2factor Leichter, Jerry
  • Re: 2factor Ed Gerck
  • Re: 2factor mhey...@gmail.com
  • Re: 2factor mhey...@gmail.com
  • Re: 2factor Steven M. Bellovin
• Privacy as Contextual Integrity - A lecture by Dr. Nissembaum of NYU Ali, Saqib
• Still locked up Shannon crypto work? Ed Gerck
  • Re: Still locked up Shannon crypto work? Steven M. Bellovin
• Levels of security according to the easiness to steel biometric data Danilo Gligoroski
  • Re: Levels of security according to the easiness to steel biometric data Philipp Gühring
  • Re: Levels of security according to the easiness to steel biometric data Arshad Noor
  • Re: Levels of security according to the easiness to steel biometric data Richard Clayton
  • Re: Levels of security according to the easiness to steel biometric data Ali, Saqib
• Hagelin cipher machine for sale on Ebay Steven M. Bellovin
• NSA declassified histories, cryptographic quarterly articles, online Perry E. Metzger
• presentations about encrypted storage travis+ml-cryptography
  • Re: presentations about encrypted storage Ivan Krstić
  • Re: presentations about encrypted storage Arshad Noor
• paper enigma machine Perry E. Metzger
• NSA domestic intelligence "vacuum" Perry E. Metzger
• announcing allmydata.org "Tahoe", the Least-Authority Filesystem, v1.0 zooko
• Fwd: [tahoe-dev] [p2p-hackers] convergent encryption reconsidered zooko
• convergent encryption reconsidered zooko
  • Re: convergent encryption reconsidered Leichter, Jerry
  • Re: [p2p-hackers] convergent encryption reconsidered zooko
  • Re: [p2p-hackers] convergent encryption reconsidered Ivan Krstić
  • Re: [p2p-hackers] convergent encryption reconsidered Leichter, Jerry
  • Re: [p2p-hackers] convergent encryption reconsidered Ivan Krstić
  • convergent encryption reconsidered -- salting and key-strengthening zooko
  • Re: [tahoe-dev] convergent encryption reconsidered -- salting and key-strengthening Ben Laurie
  • Re: [p2p-hackers] convergent encryption reconsidered -- salting and key-strengthening Ivan Krstić
  • Re: [p2p-hackers] convergent encryption reconsidered -- salting and key-strengthening zooko
  • Re: [p2p-hackers] convergent encryption reconsidered Victor Duchovni
  • Re: [p2p-hackers] convergent encryption reconsidered James A. Donald
  • Re: [p2p-hackers] convergent encryption reconsidered Ivan Krstić
  • Re: convergent encryption reconsidered Ludovic Courtès
• how to read information from RFID equipped credit cards Perry E. Metzger
  • Re: how to read information from RFID equipped credit cards Ben Laurie
  • Re: how to read information from RFID equipped credit cards Allen
  • Re: how to read information from RFID equipped credit cards James A. Donald
  • Re: how to read information from RFID equipped credit cards Peter Gutmann
  • Re: how to read information from RFID equipped credit cards Steven J. Murdoch
  • Re: how to read information from RFID equipped credit cards Victor Duchovni
  • Re: how to read information from RFID equipped credit cards Peter Gutmann
  • Re: how to read information from RFID equipped credit cards Nicolas Williams
  • Re: how to read information from RFID equipped credit cards Peter Gutmann
• Protection for quasi-offline memory nabbing Jon Callas
  • Re: Protection for quasi-offline memory nabbing Steven M. Bellovin
  • Re: Protection for quasi-offline memory nabbing Jon Callas
  • Re: Protection for quasi-offline memory nabbing Alex Alten
  • Re: Protection for quasi-offline memory nabbing Jack Lloyd
• Firewire threat to FDE Hagai Bar-El
  • Re: Firewire threat to FDE Leichter, Jerry
  • Re: Firewire threat to FDE David Malone
  • RE: Firewire threat to FDE Dave Korn
• NSA approves secure smart phone Steven M. Bellovin
  • Re: NSA approves secure smart phone David G. Koontz
  • Re: NSA approves secure smart phone David G. Koontz
• announcing allmydata.org "Tahoe" v0.9 zooko
• RFID-hack hits 1 billion digital access cards worldwide David G. Koontz
• Unique locks on microchips could reduce hardware piracy David G. Koontz
  • Re: Unique locks on microchips could reduce hardware piracy David G. Koontz
  • Re: Unique locks on microchips could reduce hardware piracy David G. Koontz
• Another NXP Mifare Classic attack Allen
• RNG for Padding COMINT
  • Re: RNG for Padding Leichter, Jerry
  • Re: RNG for Padding Steven M. Bellovin
  • Re: RNG for Padding William Allen Simpson
  • Re: RNG for Padding "Hal Finney"
• Mixmaster 3.0 released Len Sassaman
• Book Review Aram Perez
• Safari falls afoul of the security fashionistas Peter Gutmann

• Earlier messages
• Later messages