2015-06-26 2 views
0

Я получил этот код:же случайная гарантия

BigInteger bigInteger = new BigInteger(64, new Random()); 
Long longValue=-Math.abs(bigInteger.longValue()); 
int desiredLen=384; 
Random random=new Random(longValue); 
byte [] randomString=new byte[desiredLen]; 
for(int i=0;i<desiredLen;i++) 
    randomString[i]=(byte)(Math.abs(random.nextInt())&255); 

Теперь эти значения:

  • longValue - отправляется на другую сторону (сервер), а затем используется для генерации ключа снова на другом сторона
  • randomString - это ключ шифрования генерируется случайным образом на основе longValue

Просто, клиент посылает MESSA ge, содержащий первые 8 байтов longValue и другие вещи, является зашифрованным контентом randomString.

Какова гарантия того, что точно такие же числа будут созданы на всех физических и виртуальных машинах и во всех версиях Java на основе полученных longValue? А как насчет того, написан ли клиент на другом языке, таком как C#?

+1

Вы можете значительно сократить свой код, используя [Random.nextLong] (http://docs.oracle.com/javase/8/docs/api/java/util/Random.html#nextLong--) и [ Random.nextBytes] (http://docs.oracle.com/javase/8/docs/api/java/util/Random.html#nextBytes-byte:A-). – VGR

+0

Вы абсолютно не должны использовать 'Random' для безопасного шифрования. Тривиально отменить. Вы захотите использовать потоковый шифр, например. chacha20 – the8472

ответ

1

В документации API от java.util.Random указан точный алгоритм.

Это не чугунная гарантия того, что все не изменится, а не как сигнатуры методов, но любая информация о реализации, которую вы публикуете в документе API, почти обязательна. Конечно, Oracle вряд ли когда-либо изменит его.

Чувствуете ли вы, что этого достаточно для вас, зависит от вас.

Я лично не буду полагаться на него не потому, что он может измениться, а потому, что он вводит зависимость, которая может быть не сразу очевидной. Решение также должно зависеть от того, насколько важна задача. Если это хобби-проект, все может быть хорошо, если это сообщение от банка к банку, я бы даже не подумал об использовании Random вообще, поскольку он не является криптографически безопасным.

Что касается функциональной совместимости с другими языками, то никакой гарантии нет.

+0

Документация абсолютно чугунная гарантия. Это фундаментальная основа объектно-ориентированного дизайна: документация - это контракт *, а не просто «вот описание того, что я написал». – VGR

+0

@VGR Не гарантируется, что он не изменится в будущем. Я уточнил это. Или, по крайней мере, это не такая сильная гарантия, как совместимость компиляции. – biziclop

+0

На самом деле гарантируется, что в будущем он не изменится. Это тоже фундаментальная концепция ОО: контракт является постоянной гарантией. Если Java когда-либо хочет другого алгоритма генерации случайных чисел, он представит новый класс. Вот почему, например, класс StringBuilder был введен в 1.5, а не изменял существующее поведение StringBuffer. – VGR

Смежные вопросы