아직 모르는게 너무 많아!

//#region RSA 키쌍의 유효성 판별

// NIST SP 800-56B r2
// (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf)
// - 6.4.1.2.2 rsakpv1-prime-factor
public void verifyRsaKey(int bitLen, BigInteger e, BigInteger p, BigInteger q, BigInteger n, BigInteger d) {
    if (!n.equals(p.multiply(q))) {
        throw new InvalidArgumentException("n != p * q");
    }
    if (n.bitLength() != bitLen) {
        throw new InvalidArgumentException("n 의 키 길이 != " + n.bitLength());
    }
    checkPrimeFactors(bitLen, e, p, q);
    checkPrivateExponent(bitLen, e, p, q, d);
}

private void checkPrimeFactors(int bitLen, BigInteger e, BigInteger p, BigInteger q) {
    // a. If (p < (root(2) * (2^(bitLen/2−1))) or (p > 2^(bitLen/2) – 1)
    if (!checkPrimeRange(bitLen, p)) {
        throw new InvalidArgumentException("p(p1) 가 유효한 범위 내에 있지 않습니다");
    }
    // b. If (q < (root(2) * (2^(bitLen/2−1))) or (q > 2^(bitLen/2) – 1)
    if (!checkPrimeRange(bitLen, q)) {
        throw new InvalidArgumentException("q(p2) 가 유효한 범위 내에 있지 않습니다");
    }
    // [문제1] : 주석을 잘못 달아서 잘못된 주석 그대로 구현됨 : 2^(nBits/2-100)
    // c. If |p – q| <= 2(nBits/2−100)
    BigInteger difference = BigInteger.valueOf(2L * (bitLen / 2 - 100));
    if (p.subtract(q).abs().compareTo(difference) <= 0) {
        throw new InvalidArgumentException("|p - q| 가 너무 작습니다");
    }
    // d. If GCD (p – 1, epub) != 1
    if (!p.subtract(BigInteger.ONE).gcd(e).equals(BigInteger.ONE)) {
        throw new InvalidArgumentException("GCD(p-1, e) != 1");
    }
    // e. If GCD (q – 1, epub) != 1
    if (!q.subtract(BigInteger.ONE).gcd(e).equals(BigInteger.ONE)) {
        throw new InvalidArgumentException("GCD(q-1, e) != 1");
    }
    // [문제2] : NIST 에서 RSA2048 이상의 경우 certainty 값이 44가 아니라 100을 권장함
    // FIPS 186-5 (https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf)
    // - Appendix B.3 Probabilistic Primality Tests
    if (!p.isProbablePrime(44)) {
        throw new InvalidArgumentException("p(p1) 가 소수가 아닙니다 (확률적 소수 판별법)");
    }
    if (!q.isProbablePrime(44)) {
        throw new InvalidArgumentException("q(p2) 가 소수가 아닙니다 (확률적 소수 판별법)");
    }
}

private void checkPrivateExponent(int bitLen, BigInteger e, BigInteger p, BigInteger q, BigInteger d) {
    if (d.compareTo(BigInteger.valueOf(2).pow(bitLen / 2)) <= 0) {
        throw new InvalidArgumentException(String.format("d(s) 가 2 ^ (%d / 2) 보다 작습니다", bitLen));
    }
    BigInteger pSub1 = p.subtract(BigInteger.ONE);
    BigInteger qSub1 = q.subtract(BigInteger.ONE);
    BigInteger gcdSub1 = pSub1.gcd(qSub1);
    BigInteger lcmSub1 = pSub1.multiply(qSub1).divide(gcdSub1);
    if (d.compareTo(lcmSub1) >= 0) {
        // NOTE(jyha) : d 가 작을수록 공격자가 비밀키를 계산하는데 어려워지기 때문에 d < LCM(p-1, q-1) 를 유지하는 것이 좋긴 하지만,
        //              일반적으로 키쌍을 생성할 때 d 의 크기까지 확인하지는 않음.
    }
    if (!d.multiply(e).mod(lcmSub1).equals(BigInteger.ONE)) {
        throw new InvalidArgumentException("(d * e) mod LCM (p-1, q-1) != 1");
    }
}

// [문제3] : 계산의 정밀도 문제
private boolean checkPrimeRange(int bitLen, BigInteger prime) {
    double doubleNum = 2 ^ (bitLen / 2 - 1);
    // (p < (root(2) * (2^(bitLen/2−1))) => false
    if (prime.compareTo(BigInteger.valueOf((long)(Math.sqrt(2) * doubleNum))) < 0) {
        return false;
    }
    // p > 2^(bitLen/2) – 1 => false
    return prime.compareTo(BigInteger.valueOf(2).pow(bitLen / 2).subtract(BigInteger.ONE)) <= 0;
}

//#endregion

최선을 다하겠습니다!

최선을 다해서 뭘 할건데? 어떻게 할건데?
다른 직업도 그럴 수 있겠지만 개발자인 나로서는 ‘최선을 다한다’는 말이 그닥 와닿지 않는다.

개발자가 최선을 다한다는 것은 뭘 어떻게 하겠다는 것일까? 열심히 검색하기? 열심히 생각하기? 열심히 야근하기? 뭔가를 열심히 한다고 해서 그렇게 효율이 좋을 것 같진 않다.

내가 생각하는 “개발자가 최선을 다한다는 것”은 적당한 선에서 만족하지 않는 것이다. 적당한 선에서 타협은 할 수 있겠지. 원래 생각하고 있던 건 아니고 오늘 “최선을 다하겠습니다”란 말에 대해 비판적인 생각을 하다가 그렇게 결정했다.

개발자들 중에는 원하는 아웃풋을 만들어 낸 시점이 바로 끝인 사람도 있고, 그 시점에서 한번 더 생각해보는 사람도 있다. “이 변수가 마음에 안들어” “이 루틴은 따로 뺄 수 있을 것 같아” “이 부분은 구조를 바꾸면 더 사용하기 쉽겠어” “이건 내가 사용자라면 불편할 것 같아 등. (여러 의미에서. 가독성이 될 수도 있고, 재활용성, 최적화, 아니면 그 언어의 철학에 맞게 코딩했는지 등) 당연한 말이지만 후자가 더 개발자에 어울리는 사람이다.

더 길게 생각해보면 다른 답이 나올 수도 있겠는데 여기서 끊어야겠다. 사실 얼마전에 Java로 작성된 코드를 구조변경 없이 Swift로 구현해달라고 해서 개발해준 적이 있었다. 그 때 너무 짜증나서 어쩔 수 없는 부분을 제외하고는 클래스명, 함수명까지 그대로 만들어주고 탈출한 적이 있었다. 물론 전~혀 Swifty하지 않게! 그런데 이런 환경에서도 짜증내지 않고 묵묵히 개발하면서 수정할 수 있는 부분이라도 수정하며 개발하는 것이 “최선을 다한다”는 말에 어울리는 것 같기도 하다. 아마 관리자들도 이런 개발자들을 더욱 좋아할 듯 하고.

하지만 나의 최선은 그렇게 참아내는 것이 아니라 즐기는 것이었으면 한다.