Re: Why self describing data formats:
James A. Donald wrote: Many protocols use some form of self describing data format, for example ASN.1, XML, S expressions, and bencoding. Why? Presumably both ends of the conversation have negotiated what protocol version they are using (and if they have not, you have big problems) and when they receive data, they need to get the data they expect. If they are looking for list of integer pairs, and they get an integer string pair, then having the string correctly identified as a string is not going to help much. Charlie Kaufman wrote: You are correct that such encodings don't help with any interoperability issues. Sometimes, they make reading and writing the spec easier, since silly issues like big endian vs. little endian encoding of integers gets specified elsewhere. They also make it easy to write specs that do not in fact work. The spec writers do not in fact agree, and then leave the problem of implementing an under defined spec to the engineer. More rarely, it makes coding easier (if there is some parsing and encoding engine readily available to the implementers). If the protocol is being designed by a committee, it can reduce the number of debates over minutia. In the case of XML, yes there is a parsing engine, and if the structure of the DTD reflects the structure of the algorithm, then indeed it makes things much easier. But usually the committee have not thought about the algorithm, or have unresolved disagreements about what the algorithm should be, leaving the engineer with problems that are at best extremely difficult to solve, and are at worst impossible to solve. Ideally the DTD should be developed in parallel with the program that processes the XML. In that case, you get the parsing engine doing a lot of work for free, so the engineers do not have to reinvent the wheel. But if the DTD is written first by one group, and the program second, by another group, the second group is usually hosed good. But the main motivation (imho) is that it's trendy. And once anyone proposes a heavyweight standard encoding, anyone who opposes it is labeled a Luddite. Sounds true. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free Rootkit with Every New Intel Machine
Peter Gutmann wrote: -- Snip -- This is very scary. I bet that our Minister of the Interior would love it, though, since he has been pushing a scheme for stealth examination of suspects' computers (called Federal Trojan). Technology like this would be a large first step towards making this possible. [...] - Built in web interface on every machine (port 16994) Apart from all the other things that are wrong with this scheme, * you can't trust the output of netstat anymore; * in other words, what you see with netstat may not be the same as what someone else sees with nmap; and * if the web interface has a vulnerability, you have an unshutdownable vulnerable service running on your machine. Fun, Stephan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Why self describing data formats:
On Friday, June 01, 2007 7:00 AM James A. Donald wrote: Many protocols use some form of self describing data format, for example ASN.1, XML, S expressions, and bencoding. Why? Presumably both ends of the conversation have negotiated what protocol version they are using (and if they have not, you have big problems) and when they receive data, they need to get the data they expect. If they are looking for list of integer pairs, and they get a integer string pairs, then having them correctly identified as strings is not going to help much. But what is does help is allowing a protocol to be expanded and enhanced while maintaining backward compatibility for both client and server. Provided care is taken to have the protocol contain the previously required items, consumers (clients) can examine the version information and continue based on a minimum required version (i.e., The client *must* be receive version X.Y or higher.) Clients can safely ignore new, unrecognized protocol elements while greatly simplifying server code (which just emits the high-version protocol). I would generally reserve the term protocol for wire transmissions (where presumably client and server could negotiate an appropriate version). Many of the self-describing protocols you mention become static file formats. This can have its drawbacks. An interesting workaround to this is the use of critical key usage extensions in X.509 (forcing the client to reject the certificate if there are key usage restrictions that a specific client cannot recognize). There are also overhead issues (especially for XML). -Piers - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: luks disk encryption benchmarks
On Tue, 5 Jun 2007, Travis H. wrote: 1048576000 bytes (1.0 GB) copied, 3.08291 seconds, 340 MB/s [...] That seems to reflect that it isn't really going to disk. I'm surprised the controller has that much RAM on it, I guess it is not the controller, but the kernel. Encryption reduces bandwidth by about a factor of 2 with write-caching enabled. To be useful, benchmark should be similar to normal workload. Maybe you should try to compile a kernel, or install/remove some package. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why self describing data formats:
| Many protocols use some form of self describing data format, for | example ASN.1, XML, S expressions, and bencoding. | | Why? | | Presumably both ends of the conversation have negotiated what protocol | version they are using (and if they have not, you have big problems) | and when they receive data, they need to get the data they expect. If | they are looking for list of integer pairs, and they get a integer | string pairs, then having them correctly identified as strings is not | going to help much. I suspect the main reason designers use self-describing formats is the same reason Unix designers tend to go with all-ASCII formats: It's much easier to debug by eye. Whether this is really of significance at any technical level is debateable. At the social level, it's very important. We're right into worse is better territory: Self- describing and, especially, ASCII-based protocols and formats are much easier to hack with. It's much easier to recover from errors in a self-describing format; it's much easier to make reasonable inter- pretations of incorrect data (for better or worse). Network lore makes this a virtue: Be conservative in what you send, liberal in what you accept. (The first part gets honored in the breach all too often, and of course, the second is a horrible prescription for cryptography or security in general.) So software to use such protocols and formats gets developed faster, spreads more widely, and eventually you have an accepted standard that's too expensive to replace. The examples are rife. HTML is a wonderful one: It's a complex but human-readable protocol that a large fraction (probaby a majority) of generators get wrong - so there's a history of HTML readers ignoring errors and doing the best they can. Again, this is a mixed bag - on the on hand, the web would clearly have grown much more slowly without it; on the other, the lack of standardization can cause, and has caused, problems. (IE6-only sites, raise your hands.) Looked at objectively, it's hard to see why XML is even a reasonable choice for many of its current uses. (A markup language is supposed to add semantic information over an existing body of data. If most of the content of a document is within the markup - true of probably the majority of uses of XML today - something is very wrong.) But it's there, there are tons of ancilliary programs, so ... the question that gets asked is not why use XML? but why *not* use XML? (Now, if I could only learn to relax and stop tearing my hear every time I read some XML paper in which they use semantics to mean what everyone else uses syntax for) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why self describing data formats:
Many protocols use some form of self describing data format, for example ASN.1, XML, S expressions, and bencoding. I'm not sure what you're getting at. All XML and S expressions really get you is that you know how to skip past something you don't understand. This is also true for many (XER, DER, BER) but not all (PER) encodings for ASN.1. Are you saying why publish a schema? /r$ -- STSM, Senior Security Architect DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: proceedings from ECRYPT Hash Workshop 2007
Thanks to Vincent Rijmen and all who provided their papers and presentations. Most of them are there: http://events.iaik.tugraz.at/HashWorkshop07/program.html Vlastimil Klima - PŮVODNÍ ZPRÁVA - Od: [EMAIL PROTECTED] Komu: cryptography@metzdowd.com Předmět: proceedings from ECRYPT Hash Workshop 2007 Datum: 28.5.2007 - 8:39:31 The workshop was very interesting. Will the presentations or papers be avalilable on the web soon? http://events.iaik.tugraz.at/HashWorkshop07/program.html Vlastimil Klima - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free Rootkit with Every New Intel Machine
Peter Gutmann wrote: [...] a register article saying Intel released its new platform Centrino Pro which includes Intel Active Management 2.5. An article with some more info is here: It appears Active Management is a setting that can be disabled normally from the BIOS, like with TPMs today: http://support.intel.com/support/motherboards/desktop/sb/cs-020837.htm I couldn't find a conclusive statement one way or the other, but I expect it'll also be turned off by default for consumer machines. That still leaves a slew of open questions, but makes it less initially alarming, I'd say. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: luks disk encryption benchmarks
On Tue, Jun 05, 2007 at 07:00:51PM -0500, Travis H. wrote: I just did some performance testing on a file server (debian 4.0) and thought I'd share the figures, both raw and using the luks cryptosystem described here: http://luks.endorphin.org/about Here's the specs: AMD Athlon 64 x2 3600+ (1800MHz) 2GB 800MHz DDR2 ECC DRAM Asus M2N32WS motherboard 3ware 9650SE SATA RAID controller (PCI Express) in PCI Express x16 slot 4 Seagate SATA-II 500GB 7200 RPM drives with NCQ in RAID 10 configuration 16kB stripe size Debian 4.0 stable (etch) My hunch is that over NFS, even with gigabit ethernet, there will be no measurable difference between encrypted and non-encrypted storage. raw over NFS: Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP nfsclient4G 16756 61 40475 21 12033 9 15669 85 15564 6 445.8 3 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2329 12 8480 32 4185 22 1857 10 9742 27 3692 18 nfsclient,4G,16756,61,40475,21,12033,9,15669,85,15564,6,445.8,3,16,2329,12,8480,32,4185,22,1857,10,9742,27,3692,18 crypt over NFS: Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP nfsclient4G 16416 61 33488 13 10666 9 14084 73 16143 7 392.7 3 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 2218 12 7444 25 4248 20 2288 12 9401 28 3575 15 nfsclient,4G,16416,61,33488,13,10666,9,14084,73,16143,7,392.7,3,16,2218,12,7444,25,4248,20,2288,12,9401,28,3575,15 So... yeah, pretty minimal - IMHO, not worth worrying about. -- ``To know love, be like the running brook, which though deaf, sings its melody for others to hear.'' -- Master Po, Kung Fu URL:http://www.subspacefield.org/~travis/ -- dharma advaita For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp0t6UIV8S0K.pgp Description: PGP signature
question re practical use of secret sharing
A quick question. Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? Chuck Jackson - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Inadvertent Disclosure
Interesting-looking article on how users of P2P networks end up sharing much more than they expected: http://weis2007.econinfosec.org/papers/43.pdf -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Inadvertent Disclosure
| Interesting-looking article on how users of P2P networks end up sharing | much more than they expected: http://weis2007.econinfosec.org/papers/43.pdf Earlier analysis by the USPTO: http://www.uspto.gov/web/offices/dcom/olia/copyright/oir_report_on_inadvertent_sharing_v1012.pdf -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Trusted Computing Group webinar
In case anyone is interested in seeing how the Trusted Computing Group is pitching Trusted Computing to OEMs. Trusted Storage - Why You Need Security in Storage and How to Make Storage Secure Sponsored by: Trusted Computing Group Thursday, June 21st 11am PT/2pm ET This Webinar provides a framework with which to understand why and how storage should be secured and transformed into inherently trusted devices. The TCG Storage Specification provides the technical details for developing a trusted storage device, as well as how computing platform-based applications can exploit those trust and security functions. Secure and trusted storage contributes a critical element to an overall trusted platform. To register for this event go to: http://onlineevents.cmptechnetwork.com/cgi-bin4/DM/y/m8qV0JLezL0Psu0FJ8N0F5 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Full Disk Encryption solutions selected for US Government use
US Government has select 9 security vendors that will product drive and file level encryption software. See: http://security-basics.blogspot.com/2007/06/fde-fde-solutions-selected-for-us.html OR http://tinyurl.com/2xffax - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Quantum Cryptography
Hi Folks, On a legal mailing list I'm on there is a bunch of emails on the perceived effects of quantum cryptography. Is there any authoritative literature/links that can help clear the confusion? Thanks in advance, Aram Perez - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
fyi: Ross Anderson on UK ATM fraud
see also: Reliability of security systems http://www.cl.cam.ac.uk/~rja14/#Reliability =JeffH From: Ross Anderson [EMAIL PROTECTED] Subject: Newsnight tonight To: [EMAIL PROTECTED] Date: Wed, 20 Jun 2007 19:19:24 +0100 We helped make a piece on ATM fraud a few weeks ago for Newsnight, pointing out that law enforcement on bank fraud is now deeply corrupt. The Home Office did a deal with the banks so that fraud victims must report the crime to the bank, not the police; the City force's card squad is a tied cottage (as Nick put it) as the banks pays its bills; ditto the Met's e-crime squad; ditto the Financial services ombudsman. This is jolly nice for the banks when the fraud is done by a bent insider they don't want exposed, and jolly nasty for the poor customer. It's also jolly nice for terrorists such as the Tamil Tigers who use ATM fraud to raise money to finance murder and mayhem. It's really wonderful for government spin doctors as fraud figures have fallen to near zero. I'm now told that the programme will run tonight. Unfortunately a lot of its teeth have been drawn (below) Ross ** Date:Wed, 20 Jun 2007 19:09:10 BST To: [EMAIL PROTECTED] From:*** @bbc.co.uk Subject: newsnight Just to let you know. The piece will run tonight. Sadly we could only include a small part of your magnificent contribution, so the angle about the tamil tigers was dropped, against my wishes. The banks spokesman is coming on afterwards. The Home Office and ACPO both refused to appear. Regards *** -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
wrt Network Endpoint Assessment (was: Re: Free Rootkit with Every New Intel Machine)
of potential related interest is.. Network Endpoint Assessment (NEA): Overview and Requirements http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt note term remediate/remediation. relevant snippage below. see also.. http://www.ietf.org/html.charters/nea-charter.html =JeffH snip/ 1. Introduction Today, most network providers can leverage existing standards- based technologies to restrict access to their network based upon criteria such as the requesting system's user or host-based identity, source IP address or physical access point. However these approaches still leave the network resident systems vulnerable to malware-based attack, when an authorized but infected system is admitted and the malware is able to spread throughout the internal network. As a result, network operators need a proactive mechanism to assess the state of systems joining or present on the network to determine their status relative to network compliance policies. For example, if a system is determined to be out of compliance because it is lacking proper defensive mechanisms such as firewalls, anti-virus software or the absence of critical security patches, there needs to be a way to safely repair (remediate) the system so that it can be subsequently trusted to join and operate on the network. The NEA technology strives to provide a mechanism to report the configuration of an endpoint for evaluation against network compliance policy. Such a mechanism could offer a useful tool for the network operators' arsenal but should be recognized as not being a complete endpoint compliance solution in and of itself. NEA typically involves the use of special client software running on the requesting system that observes and reports on the configuration of the system to the network infrastructure. The infrastructure has corresponding validation software that is capable of comparing the system configuration information with network compliance policy and providing the result to appropriate authorization entities that make decisions about network and application access. Some systems may be incapable of running the NEA client software (e.g. printer) or be unwilling to share information about its configuration. In these cases the network infrastructure might decide to disallow or limit access to the network. In many cases, the admission decision is provisioned to the enforcement mechanisms on the network and/or system requesting access. The decision might allow for no access, limited or quarantined access (possibly to allow for remediation), or full access to the network. While the NEA Working Group recognizes there is a link between an assessment and the enforcement of the assessment decision, the mechanisms and protocols for enforcement are not in scope for this specification. Architectures, similar to NEA, have existed in the industry for some time and are present in shipping products, but do not offer interoperability. Some examples of such architectures include: Trusted Computing Group's Trusted Network Connect [TNC], Microsoft's Network Access Protection [NAP], Cisco's Network Admission Control [CNAC]). These technologies assess the software or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy. These architectures are not interoperable because they are implemented using primarily non- standards based technologies. The NEA working group is working on defining standard protocols so as to enable interoperability between devices from different vendors allowing network owners to deploy truly heterogeneous solutions. This document describes the requirements for NEA candidate technologies and protocols. snip/ 4. Problem Statement NEA technology may be used for several purposes. One use is to facilitate endpoint compliance checking against an organization's security policy when an endpoint connects to the network. Organizations often require endpoints to run an IT- specified OS configuration and have certain security applications enabled, e.g. anti-virus software, host intrusion detection/prevention systems, personal firewalls, and patch management software. An endpoint that is not compliant with IT policy may be vulnerable to a number of known threats that might exist on the network. Without NEA technology, ensuring compliance of endpoints to corporate policy is a time-consuming and difficult task. Not all endpoints are managed by a corporation's IT organization, e.g. lab assets and guest machines. Even for assets that are
Blackberries insecure?
According to the AP (which is quoting Le Monde), French government defense experts have advised officials in France's corridors of power to stop using BlackBerry, reportedly to avoid snooping by U.S. intelligence agencies. That's a bit puzzling. My understanding is that email is encrypted from the organization's (Exchange?) server to the receiving Blackberry, and that it's not in the clear while in transit or on RIM's servers. In fact, I found this text on Blackberry's site: Private encryption keys are generated in a secure, two-way authenticated environment and are assigned to each BlackBerry device user. Each secret key is stored only in the user's secure regenerated by the user wirelessly. Data sent to the BlackBerry device is encrypted by the BlackBerry Enterprise Server using the private key retrieved from the user's mailbox. The encrypted information travels securely across the network to the device where it is decrypted with the key stored there. Data remains encrypted in transit and is never decrypted outside of the corporate firewall. Of course, we all know there are ways that keys can be leaked. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
There is a opensource implementation available: http://point-at-infinity.org// On 6/13/07, Charles Jackson [EMAIL PROTECTED] wrote: A quick question. Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? -- Saqib Ali, CISSP, ISSAP http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: wrt Network Endpoint Assessment
Hi. On Wed, 20 Jun 2007 [EMAIL PROTECTED] wrote: Network Endpoint Assessment (NEA): Overview and Requirements http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt [...] NEA technology may be used for several purposes. One use is to facilitate endpoint compliance checking against an organization's security policy when an endpoint connects to the network. Organizations often require endpoints to run an IT- specified OS configuration and have certain security applications enabled, e.g. anti-virus software, host intrusion detection/prevention systems, personal firewalls, and patch management software. An endpoint that is not compliant with IT policy may be vulnerable to a number of known threats that might exist on the network. I wonder what stops a trojan to disable an antivirus, but screw the reporting system up so that it pretends that the antivirus is still active? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Blackberries insecure?
Steven M. Bellovin wrote: According to the AP (which is quoting Le Monde), French government defense experts have advised officials in France's corridors of power to stop using BlackBerry, reportedly to avoid snooping by U.S. intelligence agencies. That's a bit puzzling. My understanding is that email is encrypted from the organization's (Exchange?) server to the receiving Blackberry, and that it's not in the clear while in transit or on RIM's servers. (quick reply) they specifically mentioned the servers: The ban has been prompted by SGDN concerns that the BlackBerry system is based on servers located in the US and the UK,... https://financialcryptography.com/mt/archives/000856.html http://www.ft.com/cms/s/dde45086-1e97-11dc-bc22-000b5df10621.html iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free Rootkit with Every New Intel Machine
=?UTF-8?B?SXZhbiBLcnN0acSH?= [EMAIL PROTECTED] writes: It appears Active Management is a setting that can be disabled normally from the BIOS, like with TPMs today: http://support.intel.com/support/motherboards/desktop/sb/cs-020837.htm With TPMs it's a bit different, they're absent from the hardware by default :-). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Blackberries insecure?
On 21 June 2007 04:41, Steven M. Bellovin wrote: According to the AP (which is quoting Le Monde), French government defense experts have advised officials in France's corridors of power to stop using BlackBerry, reportedly to avoid snooping by U.S. intelligence agencies. That's a bit puzzling. My understanding is that email is encrypted from the organization's (Exchange?) server to the receiving Blackberry, and that it's not in the clear while in transit or on RIM's servers. In fact, I found this text on Blackberry's site: Private encryption keys are generated in a secure, two-way authenticated environment and are assigned to each BlackBerry device user. Each secret key is stored only in the user's secure regenerated by the user wirelessly. Data sent to the BlackBerry device is encrypted by the BlackBerry Enterprise Server using the private key retrieved from the user's mailbox. The encrypted information travels securely across the network to the device where it is decrypted with the key stored there. Data remains encrypted in transit and is never decrypted outside of the corporate firewall. Of course, we all know there are ways that keys can be leaked. And work factors reduced. And corporations who want to do business in the US have been known to secretly collaborate with the US.gov before to sabotage encryption features on exported devices (e.g. Lotus, Crypto AG, Microsoft, Netscape). So there's no reason to take the assurances on the blackberry website at face value, and if you're a government or other .org that really takes security /proper/ seriously, you've got to account for the very real risk. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Blackberries insecure?
On Wed, Jun 20, 2007 at 11:41:20PM -0400, Steven M. Bellovin wrote: According to the AP (which is quoting Le Monde), French government defense experts have advised officials in France's corridors of power to stop using BlackBerry, reportedly to avoid snooping by U.S. intelligence agencies. That's a bit puzzling. My understanding is that email is encrypted from the organization's (Exchange?) server to the receiving Blackberry, and that it's not in the clear while in transit or on RIM's servers. In fact, I found this text on Blackberry's site: The key issue is who manages the (not necessarily, but often Exchange) mail store. Enterprise BlackBerry devices should be safe from external attacks, consumer BlackBerry devices use servers provisioned elsewhere. Are the officials using Corporate or Personal BlackBerry devices? -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why self describing data formats:
James A. Donald wrote: snip In the case of XML, yes there is a parsing engine, and if the structure of the DTD reflects the structure of the algorithm, then indeed it makes things much easier. But usually the committee have not thought about the algorithm, or have unresolved disagreements about what the algorithm should be, leaving the engineer with problems that are at best extremely difficult to solve, and are at worst impossible to solve. Ideally the DTD should be developed in parallel with the program that processes the XML. In that case, you get the parsing engine doing a lot of work for free, so the engineers do not have to reinvent the wheel. But if the DTD is written first by one group, and the program second, by another group, the second group is usually hosed good. The situation is improved slightly with XML schemas, as one can use frameworks like XMLBeans (http://xmlbeans.apache.org/) to get the protocol much closer to the code. This can help a bit, but doesn't change the fundamentals. You're still right in that if you have one group developing the code and another the protocol, you're probably screwed, but isn't this just as true (perhaps moreso) if you're rolling your own protocol structure instead of using XML? W - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Blackberries insecure?
Steve, It could be that the linkage between user ids and auth keys is too weak, allowing a MITM attack to be undetected that sniffs the data encryption key. This seems to be common problem with many of the secure protocols I've examined. - Alex - Original Message - From: Steven M. Bellovin [EMAIL PROTECTED] To: cryptography@metzdowd.com Subject: Blackberries insecure? Date: Wed, 20 Jun 2007 23:41:20 -0400 According to the AP (which is quoting Le Monde), French government defense experts have advised officials in France's corridors of power to stop using BlackBerry, reportedly to avoid snooping by U.S. intelligence agencies. That's a bit puzzling. My understanding is that email is encrypted from the organization's (Exchange?) server to the receiving Blackberry, and that it's not in the clear while in transit or on RIM's servers. In fact, I found this text on Blackberry's site: Private encryption keys are generated in a secure, two-way authenticated environment and are assigned to each BlackBerry device user. Each secret key is stored only in the user's secure regenerated by the user wirelessly. Data sent to the BlackBerry device is encrypted by the BlackBerry Enterprise Server using the private key retrieved from the user's mailbox. The encrypted information travels securely across the network to the device where it is decrypted with the key stored there. Data remains encrypted in transit and is never decrypted outside of the corporate firewall. Of course, we all know there are ways that keys can be leaked. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ad hoc IPsec or similiar
There's a rather ominous EU legislation to be passed soon, which requires any party acting as a provider (you run anonymous proxy, or mix cascade, you are a provider) to log all connection info (when, who, with whom). What's the status of ad hoc IPsec or any other TCP/IP-tunneling VPN for random endpoints? -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
On Fri, 22 Jun 2007, Peter Gutmann wrote: It's available as part of other products (e.g. nCipher do it for keying their HSMs), but I don't know of any product that just does... secret sharing. What would be the user interface for such an application? What would be the target audience? (I mean a real target audience, not some hypothesised scenario). http://monolith.sourceforge.net/: Monolith is a simple tool that takes two arbitrary binary files (called a Basis file and an Element file) and munges them together to produce a Mono binary file (with a .mono extension). Monolith can also reconstruct an Element file from a Basis file and a Mono file. So if one xors a Linux iso image and some movie, it is quite hard to claim that the result is copyright-protected. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ad hoc IPsec or similiar
In article [EMAIL PROTECTED], Eugen Leitl [EMAIL PROTECTED] writes There's a rather ominous EU legislation to be passed soon, which requires any party acting as a provider (you run anonymous proxy, or mix cascade, you are a provider) to log all connection info (when, who, with whom). What's the status of ad hoc IPsec or any other TCP/IP-tunneling VPN for random endpoints? (a) the EU legislation was actually passed well over a year ago http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2006/l_105/l_1052 0060413en00540063.pdf and applies to service providers so random endpoints will be unlikely to be caught by its requirements. (b) what the Directive exactly means is anyone's guess (the wording shows a deep failure to understand how the Internet works), and it is entirely clear that it will in practice mean different things in different EU countries. In the UK it's likely to only apply to large public ISPs -- and retention will be restricted to records of who used which IP address, email server records, and possibly web cache logs (possibly not, since web caches may not be economic if the logs have to be retained)... ... the wikipedia page on the topic http://en.wikipedia.org/wiki/Data_retention ... has information for other countries that looks fairly plausible from what I know about their plans. Note that the Directive also applies to phone calls ... and the transposition of that into national laws is supposed to be completed by October 2007; most countries have until March 2009 for Internet logs -- richard Richard Clayton They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Benjamin Franklin - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why self describing data formats:
On Fri, Jun 01, 2007 at 08:59:55PM +1000, James A. Donald wrote: Many protocols use some form of self describing data format, for example ASN.1, XML, S expressions, and bencoding. ASN.1 is not an encoding, and not all its encodings are self-describing. Specifically, PER is a compact encoding such that a PER encoding of some data cannot be decoded without access to the ASN.1 module(s) that describes the data types in question. Yes, it's a nit. Then there's XDR -- which can be thought of as a subset of ASN.1 and a four-octet aligned version of PER (XDR being both, a syntax and an encoding). Why? Supposedly it is (or was thought to be) easier to write encoders/ decoders for TLV encodings (BER, DER, CER) and S-expressions, but I don't believe it (though I certainly believe that it was thought to be easier): rpcgen is a simple enough program, for example. TLV encodings tend to quite redundant, in a way that seems dangerous: a lazy programmer can (and many have) write code that fails to validate parts of an encoding and mostly get away with it (until the then inevitable subsequent buffer overflow, of course). Of course, code generators and libraries for self-describing and non- self-describing encodings alike are not necessarily bug free (have any been?) but at least they have the virtue that they are automatic tools that consume a formal language, thus limiting the number of lazy programmers involved and the number of different ways in which they can screw up (and they leave their consumers off the hook, to a point). Presumably both ends of the conversation have negotiated what protocol version they are using (and if they have not, you have big problems) and when they receive data, they need to get the data they expect. If they are looking for list of integer pairs, and they get a integer string pairs, then having them correctly identified as strings is not going to help much. I agree. The redundancy of TLV encodings, XML, etcetera, is unnecessary. Note though that I'm only talking about serialization formats for data in protocols; XML, I understand, was intended for _documents_, and it does seem quite appropriate for that, and so it can be expected that there should be a place for it in Internet protocols in transferring pieces of documents. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: wrt Network Endpoint Assessment
On Thu, Jun 21, 2007 at 04:32:50PM +0300, Alexander Klimov wrote: Hi. On Wed, 20 Jun 2007 [EMAIL PROTECTED] wrote: Network Endpoint Assessment (NEA): Overview and Requirements http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-02.txt [...] NEA technology may be used for several purposes. One use is to facilitate endpoint compliance checking against an organization's security policy when an endpoint connects to the network. Organizations often require endpoints to run an IT- specified OS configuration and have certain security applications enabled, e.g. anti-virus software, host intrusion detection/prevention systems, personal firewalls, and patch management software. An endpoint that is not compliant with IT policy may be vulnerable to a number of known threats that might exist on the network. I wonder what stops a trojan to disable an antivirus, but screw the reporting system up so that it pretends that the antivirus is still active? Nothing, the technology is not sufficient, merely necessary... -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why self describing data formats:
But the main motivation (imho) is that it's trendy. And once anyone proposes a heavyweight standard encoding, anyone who opposes it is labeled a Luddite. Maybe. But there's quite a lot to be said for standards which lead to widespread availability of tools implementing them, both, open source and otherwise. One of the arguments we've heard for why ASN.1 sucks is the lack of tools, particularly open source ones, for ASN.1 and its encodings. Nowadays there is one GPL ASN.1 compiler and libraries: SNACC. (I'm not sure if it's output is unencumbered, like bison, or what, but that's important to a large number of developers who don't want to be forced to license under GPL, and there's not any full-featured ASN.1 compilers and libraries licensed under the BSD or BSD-like licenses.) The situation is markedly different with XML. Even if you don't like XML, or its redundancy (as an encoding, but then, see FastInfoSet, a PER-based encoding of XML), it has that going for it: tool availability. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
RSA's BSAFE 6.2.1.0 supports Bloom-Shamir secret sharing. Peter Trei Principal Engineer RSA: the Security Division of EMC. Disclaimer: I am not a spokesperson for RSA or EMC. -Original Message- Charles Jackson asks: A quick question. Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why self describing data formats:
On Mon, Jun 11, 2007 at 09:28:02AM -0400, Bowness, Piers wrote: But what is does help is allowing a protocol to be expanded and enhanced while maintaining backward compatibility for both client and server. Nonsense. ASN.1's PER encoding does not prevent extensibility. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Tue, Jun 19, 2007 at 09:10:12PM -0700, Aram Perez wrote: On a legal mailing list I'm on there is a bunch of emails on the perceived effects of quantum cryptography. Is there any authoritative literature/links that can help clear the confusion? Quantum Cryptography or Quantum Computing (i.e. cryptanysis)? - Quantum Cryptography is fiction (strictly claims that it solves an applied problem are fiction, indisputably interesting Physics). - Quantum Computing is science fiction. Some science fiction eventually becomes reality. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Blackberries insecure?
[EMAIL PROTECTED] schrieb: Steve, It could be that the linkage between user ids and auth keys is too weak, allowing a MITM attack to be undetected that sniffs the data encryption key. This seems to be common problem with many of the secure protocols I've examined. - Alex Ahoi! Nobody knows, what the blackberry does with the decrypted data. The whole device is a black-box, so it is able to do anything it is programmed for, with all the data transmitted to it. -- Grisu - Original Message - From: Steven M. Bellovin [EMAIL PROTECTED] To: cryptography@metzdowd.com Subject: Blackberries insecure? Date: Wed, 20 Jun 2007 23:41:20 -0400 According to the AP (which is quoting Le Monde), French government defense experts have advised officials in France's corridors of power to stop using BlackBerry, reportedly to avoid snooping by U.S. intelligence agencies. That's a bit puzzling. My understanding is that email is encrypted from the organization's (Exchange?) server to the receiving Blackberry, and that it's not in the clear while in transit or on RIM's servers. In fact, I found this text on Blackberry's site: Private encryption keys are generated in a secure, two-way authenticated environment and are assigned to each BlackBerry device user. Each secret key is stored only in the user's secure regenerated by the user wirelessly. Data sent to the BlackBerry device is encrypted by the BlackBerry Enterprise Server using the private key retrieved from the user's mailbox. The encrypted information travels securely across the network to the device where it is decrypted with the key stored there. Data remains encrypted in transit and is never decrypted outside of the corporate firewall. Of course, we all know there are ways that keys can be leaked. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
