Re: Hiding data on 3.5 using 40 track mode
Ben Laurie [EMAIL PROTECTED] writes: Dave Howe wrote: Oh - before I forget, I was thinking about covert channels and cds a few days ago and realised there is already one - CDs support a special mode called CD+G - this is used making karaoke cds to support the video data stream; the vast majority of pc drives cannot read this data - there are exceptions of course. however, karaoke players (and many low-end dvd players) CAN, and by design display them on the screen of the playback device. I used to write CD device drivers (ancient history, I wrote, with my brother, one of the first CD rippers ever: CD-GRAB). As I remember it, most drives _can_ read this extra data, but drivers often don't support it. I recently had to check out the low-level capabilities of a range of CD/DVD writers for reasons too tedious to mention, CD+G read support is at best about 50:50. I used cdrinfo.com to get the data, they use Nero's InfoTool to ask the drive for capabilities rather than relying on manufacturer specs, since they can change between printing the data sheets and shipping the drive, and across different firmware versions. CD+G read support is treated as a drive firmware/hardware characteristic since the drives that don't support it simply won't send the streams to the host system even if they can read them. Beyond that, your software driver also has to support it. You can get assorted software to write CD+G, but it's mostly targeted at the DIY Karaoke market and not for use as subliminal channels (I believe Nero can write CD+G, but haven't tried it yet - if it's like the other CD+G progs, it'll only allow insertion of song text and graphics). In addition you only get 4 lots of 16 bytes per 2352-byte sector, and can then use 6 bits of each byte for data. Note that CD data is actually unreliable when used for audio - I definitely saw the same CD show bitwise differences on successive reads, much to my surprise, so if you want to do this, remember to include error correction :-) The cdrinfo folks really thrash the drives they test, including running through a pile of special disks with artificial errors and other problems. It's a good source of info on which drives handle errors best... of course then you could end up creating CDs that are only readable on one drive type, or even one drive. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: general defensive crypto coding principles
On Thu, Feb 09, 2006 at 05:01:05PM +1300, Peter Gutmann wrote: So you can use encrypt-then-MAC, but you'd better be *very* careful how you apply it, and MAC at least some of the additional non-message- data components as well. Looking at the definitions in the paper, I think it is pretty clear that that was their intent. The scheme definitions in section 4 make no provisions for initialization vectors or any kind of parameterization, so I'm assuming that they assumed the encryption function will include all that as part of the output, meaning it will be included as part of the MAC. -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable dialog.
James A. Donald [EMAIL PROTECTED] writes: 2. Html encourages legitimate businesses to use complicated and obfuscated actual targets for their urls, indistinguishable from those used by phishers. I think a more general extension of this is HTML allows the use of arbitrarily sophisticated presentation attacks. This definitely isn't a capability you want to give to a malicious party, although it's way too late to shut the barn door any more. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
conservative choice: encrypt then MAC (Re: general defensive crypto coding principles)
Don't forget Bleichenbacher's error channel attack on SSL implementations, which focussed on the mac then encrypt design of SSL... web servers gave different error for malformed padding vs plaintext MAC failure. The lesson I drew from that is the conservative choice is encrypt then MAC. I dont think encrypt then MAC presents a timing attack because your chances of getting past the MAC are 1/2^80 in the first place. And obviously you include the whole ciphertext (including the IV!) in the MAC. In fact anything which affects decryption process should be in the mac. Adam On Thu, Feb 09, 2006 at 05:01:05PM +1300, Peter Gutmann wrote: Jack Lloyd [EMAIL PROTECTED] writes: Bellare and Namprempre have a paper on this [worth reading IMO; http://www-cse.ucsd.edu/~mihir/papers/oem.html] which suggests that this method (which they term Encrypt-and-MAC) has problems in terms of information leakage. An obvious example occurs when using a deterministic authentication scheme like HMAC - an attacker can with high probability detect duplicate plaintexts by looking for identical tags. They also show that using a MAC on the ciphertext is a secure construction in a fairly broad set of cases. Here's a trivial way in which it can be weaker: Let's say you MAC the ciphertext and if it checks out OK you decrypt it and use it. If you're using any mode other than ECB (which you'd better be doing) an attacker can arbitrarily modify the start of the message by fiddling with the IV. CBC (by far the most widely-used mode) is particularly nasty because you can make the decrypted data anything you want, as the IV is xored directly into the plaintext. So you can use encrypt-then-MAC, but you'd better be *very* careful how you apply it, and MAC at least some of the additional non-message- data components as well. Another problem with encrypt-then-MAC is that it creates a nice timing channel if you bail out on a MAC failure before doing the decryption step. So while EtM may be theoretically better in some (somewhat artificial) cases, it's much more brittle in terms of implementation problems. Since implementors are rarely expert cryptographers, I'd prefer the safer MtE rather than EtM for protocol designs. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: conservative choice: encrypt then MAC (Re: general defensive crypto coding principles)
Don't forget Bleichenbacher's error channel attack on SSL implementations, which focussed on the mac then encrypt design of SSL... web servers gave different error for malformed padding vs plaintext MAC failure. The lesson I drew from that is the conservative choice is encrypt then MAC. Bleichenbacher's attack focused on RSA PKCS#1 decryption. You're thinking of Vaudenay's, which focused on CBC padding errors. There are other lessons to draw too, most notably: don't ever let the sender know the reason why a decryption-and-authentication failed. William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: FWD: [IP] Encrypting Bittorrent to take out traffic shapers
Alexander Klimov wrote: On Tue, 7 Feb 2006, Adam Fields wrote: Over the past months more Bittorrent users noticed that their ISP is killing all Bittorrent traffic . ISP?s like Rogers are using bit- shaping applications to throttle the traffic that is generated by Bittorrent. A side note is that they're using known insecure encryption methods as a cpu tradeoff because it doesn't matter if the traffic is decrypted eventually, as long as it can't be revealed in realtime. That's possibly shortsighted, but still interesting. Since one can easily encrypt 60 Mb/s with AES on a modern computer it does not matter what algorithm to use (unless, of course, you have a wider than 60 MB/s connection). Ah, but you haven't allowed for the fact that the ISP has to do this for /all/ the traffic from /all/ of their customers if they want to know if it's BT or not. BTW, if ISP really wants to slow down bittorrent it can use some other methods: there is usually constant port (6881, IIRC), and quite specific communication patern. Indeed, they're likely to find a traffic-analysis method of doing this sooner or later, and then they won't have to bother about the encryption. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: FWD: [IP] Encrypting Bittorrent to take out traffic shapers
On 2/9/06, Dave Korn [EMAIL PROTECTED] wrote: Alexander Klimov wrote: On Tue, 7 Feb 2006, Adam Fields wrote: [...] A side note is that they're using known insecure encryption methods as a cpu tradeoff because it doesn't matter if the traffic is decrypted eventually, as long as it can't be revealed in realtime. That's possibly shortsighted, but still interesting. BTW, if ISP really wants to slow down bittorrent it can use some other methods: there is usually constant port (6881, IIRC), and quite specific communication patern. Indeed, they're likely to find a traffic-analysis method of doing this sooner or later, and then they won't have to bother about the encryption. Maybe I've missed a point, but with encryption I thought you can *simulate* every communication pattern. You can send a flow of constant, random data when you're not getting bittorrent data and there you have another kind of connection. A full-duplex flow of data can be a VoIP encrypted stream, a VPN, X session over ssh, whatever. Or am I mistaken? Also, since encryption will be used only to obfuscate the real data, I think that even a simple XOR could suffice. From a provider point of view, a solution could be only allowing http[s], ftp, maybe ssh based on the port number. But if a BT application listens on port 22, you're pretty much screwed up. And also if I subscribe to an ISP that gives me *internet* access via TCP/IP they should specify on the EULA which ports I should use or not. my .2 euros. -- :lorenzo grespan GPG Key fingerprint = 5372 1B49 9E61 747C FB9A 4DAE 5D2A A9A0 74B4 8F1A - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
