5 ms·

The amazing thing about DVI, and by extension HDMI, is that it's just VGA but digital, with all the timing and synchronisation complexity that implies. Recall t

The amazing thing about DVI, and by extension HDMI, is that it's just VGA but digital, with all the timing and synchronisation complexity that implies. Recall that DVI can have both an analog (VGA/DVI-A) and digital (DVI-D) signal in the same cable. They aren't independent; they share some pins and have the same timing. You could have made a CRT monitor that used DVI-D just by adding a DAC, though I'm not sure if anyone ever did. DisplayPort does away with all that legacy. I assume the hardware to implement it is much simpler and more reliable.

pavlov 3y ago
I was guessing that the oddly beautiful 17” Apple CRT Studio Display [1] from 2000 might have been a CRT that used a digital signal cable because it had the short-lived Apple Display Connector, but apparently ADC carried analog too. [1] https://everymac.com/monitors/apple/studio_cinema/specs/apple_studio_display_17_cl.html https://everymac.com/monitors/apple/studio_cinema/specs/appl...
- ShadowBanThis01 3y ago
  The ADC carried power, too, which is why Apple went with it.
MisterTea 3y ago
> You could have made a CRT monitor that used DVI-D just by adding a DAC, though I'm not sure if anyone ever did. From memory IBM offered a crt with DVI.
- thereddaikon 3y ago
  Plenty did but they were usually DVI-A or DVI-I
madars 3y ago
This also has side-channel implications, and is a reason why eDP is recommended in voting applications. https://www.eerstekamer.nl/nonav/overig/20160428/richtlijnen_ter_voorkoming_van/document https://www.eerstekamer.nl/nonav/overig/20160428/richtlijnen... >DisplayPort uses a scrambler as part of its line encoding in order to flatten the Fourier spectrum of its emissions and suppress spectral peaks caused by particular image contents. This reduces the chances of any particular image content causing a problem spectral peak during SDIP-27 and EMI spectrum measurements. According to the standard, the scrambler reduces spectral peaks by about 7 dB. As a side effect, the scrambler also makes it far more difficult, probably even impractical, for an attacker to reconstruct any information about the displayed image from the DisplayPort emissions. [..] DisplayPort uses a small number of fixed bit rates, independent of the video mode used. Unlike with most other digital interfaces, video data is transmitted in data packets with header and padding bytes, and not continuously with a television-like timing. As a result, DisplayPort cables are not a common source of van-Eckstyle video emanations and this again will make it very hard for an eavesdropper to synchronize to the transmitted data. Speaking of which: how does one force HDCP (say, in Linux)? That would transform this technology from a DRM nuisance (strippers easily available on AliExpress) into a Van Eck-countermeasure.
- angry_octet 3y ago
  HDCP can't really be stripped, if it's on then something is an HDCP receiver. For v1.4 signals you can probably get something with the leaked key, but not for v2.2 as yet. HDCP itself needs to be licensed in order to generate it, and that licence is only available to HDMI Adopter companies. However there is code to get some chipsets to turn it on: https://github.com/intel/hdcp https://github.com/intel/hdcp Grab it now before Intel deletes it completely. HDCP is really a very ugly protocol designed just for anti-copying, I wouldn't build anything relying on it, and everything is harder with HDCP from an AV integration perspective. If you have long links that you want to secure, use something like SDVoE with encryption and authentication (bits are easily flipped in HDCP).
  - madars 3y ago
    There are devices that will give you HDCP 2.3->1.4 conversion for compatibility reasons (or maybe wink-wink reasons), and after that you can use a HDCP 1.4 stripper. There are also devices that will strip 2.2 outright (they are marketed as HDMI splitters but, oops, one of the two outputs has unencrypted signal, an honest mistake); not sure about 2.3 though. Completely agree that HDCP makes everything harder, but in this scenario it would also make attacker's job of descrambling the eavesdropped signal harder. And this is after they have overcome packetization and spread spectrum hurdles, which the paper suggests is very challenging to do, so would be a (hacky) defense-in-depth for DisplayPort. Even more important for HDMI/DVI which lacks the aforementioned hurdles.
    - zorgmonkey 3y ago
      My understanding is that the downside of those downgrade devices is HDCP 1.4 will leave you stuck without 4k and HDR for content that uses HDCP.
      - angry_octet 3y ago
        Yes you can extract plaintext 1080p but not 4k HDR.
- 3y ago
rasz 3y ago
>DisplayPort does away with all that legacy. You wish. DP sends exactly same bytes DVI does (blanking and all), just broken up into packets.
- fanf2 3y ago
  The important difference is that (like VGA) DVI and HDMI still dedicate particular physical wires to separate red, green, and blue channels. Display port does not shard individual pixels across multiple channels: all bits (all colours) of a pixel are sent on the same diffpair. If a DP link has multiple lanes then the bits of different successive pixels are sent on each lane.
  - rasz 3y ago
    This is great, but then they drop the ball by forcing garbage (“interspersed stuffing symbols”) between the packets instead of letting you use that BW.
    - nyanpasu64 3y ago
      I think that you can actually transmit audio, or other displays' signals (DisplayPort Multi-Stream Transport), in place of stuffing symbols.
      - rasz 3y ago
        Afaik its a no-no zone. You can only use blanking periods.
        nyanpasu64 3y ago
        You may be correct (and I was mistaken in my previous post) for audio. The leaked (DP isn't really an open standard) DP-1.2.pdf on glenwing's site says that "The dummy stuffing data symbols during the video blanking periods (both vertical and horizontal) may be substituted either with main stream attributes data or a secondary-data packet", and the public 1.1a PDF indicates similarly. MST is quite complicated and appears to interleave bytes from different video streams within 64-byte packets (rather than solely during blanking): > The MTP (Multi-stream Transport Packet) is 64 link-symbol (1 byte of video data or special symbols) cycles (that is, 64 time slots) long, starting with MTP Header in the first time slot (or Time Slot 0), and is constantly transported regardless of the presence/absence of streams. > The Payload Bandwidth Manager of each uPacket TX in the path from a DP Source to a target Sink device allocates time slots within the MTP to a VC (Virtual Channel) Payload to establish the virtual channel for transporting a stream.
nyanpasu64 3y ago
One (extreeeemely pedantic) difference is that (I think) HDMI begins and ends its vsync pulses when the preceding hblank begins, whereas VGA begins and ends them slightly later when the preceding hsync pulse begins (I documented this at https://nyanpasu64.gitlab.io/blog/crt-modeline-cvt-interlacing/#vsync-pulse-timing-within-a-scanline https://nyanpasu64.gitlab.io/blog/crt-modeline-cvt-interlaci...). I also think that DP rouuuughly reflects CRT timings complete with active vs. blanking intervals, but doesn't actually have a fixed pixel clock (perhaps it does? I didn't quite figure out synchronous/asynchronous pixel transmission when reading the spec) and doesn't transmit hsync pulses once per scanline.

pavlov 3y ago

I was guessing that the oddly beautiful 17” Apple CRT Studio Display [1] from 2000 might have been a CRT that used a digital signal cable because it had the short-lived Apple Display Connector, but apparently ADC carried analog too. [1] https://everymac.com/monitors/apple/studio_cinema/specs/apple_studio_display_17_cl.html https://everymac.com/monitors/apple/studio_cinema/specs/appl...

ShadowBanThis01 3y ago
The ADC carried power, too, which is why Apple went with it.

MisterTea 3y ago

> You could have made a CRT monitor that used DVI-D just by adding a DAC, though I'm not sure if anyone ever did. From memory IBM offered a crt with DVI.

thereddaikon 3y ago
Plenty did but they were usually DVI-A or DVI-I

madars 3y ago

This also has side-channel implications, and is a reason why eDP is recommended in voting applications. https://www.eerstekamer.nl/nonav/overig/20160428/richtlijnen_ter_voorkoming_van/document https://www.eerstekamer.nl/nonav/overig/20160428/richtlijnen... >DisplayPort uses a scrambler as part of its line encoding in order to flatten the Fourier spectrum of its emissions and suppress spectral peaks caused by particular image contents. This reduces the chances of any particular image content causing a problem spectral peak during SDIP-27 and EMI spectrum measurements. According to the standard, the scrambler reduces spectral peaks by about 7 dB. As a side effect, the scrambler also makes it far more difficult, probably even impractical, for an attacker to reconstruct any information about the displayed image from the DisplayPort emissions. [..] DisplayPort uses a small number of fixed bit rates, independent of the video mode used. Unlike with most other digital interfaces, video data is transmitted in data packets with header and padding bytes, and not continuously with a television-like timing. As a result, DisplayPort cables are not a common source of van-Eckstyle video emanations and this again will make it very hard for an eavesdropper to synchronize to the transmitted data. Speaking of which: how does one force HDCP (say, in Linux)? That would transform this technology from a DRM nuisance (strippers easily available on AliExpress) into a Van Eck-countermeasure.

angry_octet 3y ago
HDCP can't really be stripped, if it's on then something is an HDCP receiver. For v1.4 signals you can probably get something with the leaked key, but not for v2.2 as yet. HDCP itself needs to be licensed in order to generate it, and that licence is only available to HDMI Adopter companies. However there is code to get some chipsets to turn it on: https://github.com/intel/hdcp https://github.com/intel/hdcp Grab it now before Intel deletes it completely. HDCP is really a very ugly protocol designed just for anti-copying, I wouldn't build anything relying on it, and everything is harder with HDCP from an AV integration perspective. If you have long links that you want to secure, use something like SDVoE with encryption and authentication (bits are easily flipped in HDCP).
- madars 3y ago
  There are devices that will give you HDCP 2.3->1.4 conversion for compatibility reasons (or maybe wink-wink reasons), and after that you can use a HDCP 1.4 stripper. There are also devices that will strip 2.2 outright (they are marketed as HDMI splitters but, oops, one of the two outputs has unencrypted signal, an honest mistake); not sure about 2.3 though. Completely agree that HDCP makes everything harder, but in this scenario it would also make attacker's job of descrambling the eavesdropped signal harder. And this is after they have overcome packetization and spread spectrum hurdles, which the paper suggests is very challenging to do, so would be a (hacky) defense-in-depth for DisplayPort. Even more important for HDMI/DVI which lacks the aforementioned hurdles.
  - zorgmonkey 3y ago
    My understanding is that the downside of those downgrade devices is HDCP 1.4 will leave you stuck without 4k and HDR for content that uses HDCP.
    - angry_octet 3y ago
      Yes you can extract plaintext 1080p but not 4k HDR.
3y ago

rasz 3y ago

>DisplayPort does away with all that legacy. You wish. DP sends exactly same bytes DVI does (blanking and all), just broken up into packets.

fanf2 3y ago
The important difference is that (like VGA) DVI and HDMI still dedicate particular physical wires to separate red, green, and blue channels. Display port does not shard individual pixels across multiple channels: all bits (all colours) of a pixel are sent on the same diffpair. If a DP link has multiple lanes then the bits of different successive pixels are sent on each lane.
- rasz 3y ago
  This is great, but then they drop the ball by forcing garbage (“interspersed stuffing symbols”) between the packets instead of letting you use that BW.
  - nyanpasu64 3y ago
    I think that you can actually transmit audio, or other displays' signals (DisplayPort Multi-Stream Transport), in place of stuffing symbols.
    - rasz 3y ago
      Afaik its a no-no zone. You can only use blanking periods.
      - nyanpasu64 3y ago
        You may be correct (and I was mistaken in my previous post) for audio. The leaked (DP isn't really an open standard) DP-1.2.pdf on glenwing's site says that "The dummy stuffing data symbols during the video blanking periods (both vertical and horizontal) may be substituted either with main stream attributes data or a secondary-data packet", and the public 1.1a PDF indicates similarly. MST is quite complicated and appears to interleave bytes from different video streams within 64-byte packets (rather than solely during blanking): > The MTP (Multi-stream Transport Packet) is 64 link-symbol (1 byte of video data or special symbols) cycles (that is, 64 time slots) long, starting with MTP Header in the first time slot (or Time Slot 0), and is constantly transported regardless of the presence/absence of streams. > The Payload Bandwidth Manager of each uPacket TX in the path from a DP Source to a target Sink device allocates time slots within the MTP to a VC (Virtual Channel) Payload to establish the virtual channel for transporting a stream.

nyanpasu64 3y ago

One (extreeeemely pedantic) difference is that (I think) HDMI begins and ends its vsync pulses when the preceding hblank begins, whereas VGA begins and ends them slightly later when the preceding hsync pulse begins (I documented this at https://nyanpasu64.gitlab.io/blog/crt-modeline-cvt-interlacing/#vsync-pulse-timing-within-a-scanline https://nyanpasu64.gitlab.io/blog/crt-modeline-cvt-interlaci...). I also think that DP rouuuughly reflects CRT timings complete with active vs. blanking intervals, but doesn't actually have a fixed pixel clock (perhaps it does? I didn't quite figure out synchronous/asynchronous pixel transmission when reading the spec) and doesn't transmit hsync pulses once per scanline.