P-384 ECDSA 서명을 받아 펌웨어 보안 부팅 이미지를 만드는 서명 절차에서 같은 SHA-384 다이제스트가 서로 다른 길이의 결과를 냈다. 한 응답은 DER 전체 103바이트에 R 48바이트, S 49바이트였다. 다른 응답은 전체 102바이트에 R 49바이트, S 47바이트였다. 두 서명은 같은 공개키로 검증에 성공했다.
길이 차이는 이상 현상처럼 보이지만 DER 정수에서는 정상 범위일 수 있다. DER은 정수를 필요한 만큼만 기록한다. 양수의 맨 앞 비트가 1이면 음수로 해석되지 않도록 00을 붙인다. 이 규칙 때문에 P-384의 R과 S는 값에 따라 흔한 48바이트보다 짧은 47바이트가 되거나 49바이트로 늘어난다.
암호학적 검증을 통과한 서명이 장치에서 거부된다면 따져야 할 것은 소비자 파서의 계약이다. 각 정수를 사실상 고정 길이로 읽는 구현은 정상적인 최소 표현을 받지 못할 수 있다. 전체 서명 길이만 보는 검사도 부족하다. R과 S의 조합이 달라도 전체 길이가 같을 수 있다. 규격에 없는 00을 더해 모양을 맞추면 DER 자체가 잘못된다.
재서명은 제한된 호환성 우회로만 다뤄야 한다. DER 구조와 정수 범위, 암호학적 유효성을 먼저 확인한 뒤 특정 장치 프로필에서만 짧은 정수를 거른다. 다시 요청할 때는 다이제스트, 해시 방식, 키, 인증서 체인을 그대로 유지한다. 이미지 준비와 해시 계산까지 처음부터 반복할 필요는 없다.
시도 횟수도 고정해야 한다. 총 세 번처럼 작은 상한을 두고 각 시도의 R·S 길이와 재요청 이유를 기록한다. 한도를 넘으면 호환성 실패를 명시하고 끝낸다. 잘못된 DER, 서명 불일치, 인증 실패, 전송 오류는 길이 문제와 따로 처리한다. 결정적 서명이나 동일 응답 캐시를 쓰는 환경에서는 반복해도 길이가 바뀌지 않을 수 있다.
현재 증거는 우회 구현을 검토할 근거이지 장치 결함의 판정문은 아니다. 실제 재구성된 이미지에는 47바이트 정수가 없었고, 가까운 시각의 다른 응답에서만 발견됐다. 장치가 R과 S 중 무엇을 어떤 조건으로 거부하는지, 그 제약이 실제 로딩 실패를 만들었는지도 확인되지 않았다. 재서명 코드를 넣기 전에 장치의 입력 규칙과 실패 재현부터 고정해야 한다.