Чому люди використовують bouncycastle замість вбудованого провайдера JCE Java? Яка різниця?

79

Чому люди використовують bouncycastle замість Java Cryptography Extension? Яка різниця?

java cryptography

— clyfe
джерело

7

JCE - це стандартний API, який може реалізувати будь-який крипто алгоритм, щоб забезпечити доступ до нього без кодування залежностей від провайдера. Іншими словами, використовуючи API JCE, ви можете змінювати шифри та постачальника шифрів, не змінюючи свій код (у багатьох випадках). BC є постачальником, що означає, що вони реалізують шифри, до яких можна отримати доступ через API JCE. Якщо підходить інший постачальник, який реалізує бажаний вами алгоритм краще, ніж BC, або новий, сильніший алгоритм, ви можете переключитися, не змінюючи свій код (можливо).

— nicerobot

81

BouncyCastle має набагато більше наборів шифрів та алгоритмів, ніж JCE за замовчуванням, наданий Sun.

На додаток до цього, BouncyCastle має безліч утиліт для читання загадкових форматів, таких як PEM та ASN.1, які жодна розумна людина не захоче переписувати.

— Кевін
джерело

9

Sun ніколи не збирався бути вичерпним постачальником шифрів. Тому JCE використовує фреймворк провайдера, який BC підтримує bouncycastle.org/specifications.html#install . Будь-який користувач BC буде розумно використовувати його за допомогою API JCE, коли це можливо.

— nicerobot

26

Баусі-замок є австралійським походженням, і тому не підлягає вивезенню криптографії із США .

Це корисно, якщо ви перебуваєте за межами США, і вам потрібно керувати розмірами ключів, набагато більшими, ніж дозволено таким, що обмеження. У цьому випадку вам не дозволяється використовувати для цього програмне забезпечення США.

— Лоуренс Р. Угальде
джерело

5

Цікаво, скільки обмежень, які насправді залишаються, до 2016 року? Наскільки я розумію, більше немає обмежень на розмір ключів, поки ви реєструєтесь у Бюро промисловості та безпеки Міністерства торгівлі США (BIS), що, мабуть, Oracle вже робить. Але правила загадкові (каламбур).

— Петер

1

Тьфу, якщо я перебуваю за межами США, мені нічого не потрібно дозволяти. Можливо, потрібно буде дозволити проекту щось транспортувати.

— Петро Дончев

Більшість обмежень у західному світі засновані на тому, куди він експортується, а не на ключовий розмір сьогодні. Обмеження розміру ключа було однією з речей, що розслабилися наприкінці 90-х. Що стосується діючих австралійських норм, то це не настільки в'яло, як випливає з цієї відповіді, але це не так погано, як те, що стосувалося страхування кількох років тому (якщо ви не винайдете нового алгоритму та ще одну чи дві речі. Загалом на це поширюється домовленість Вассенара та правила ITAR (через AU DoD)

— Бен,

Додаток до вищезазначеного коментаря, який може вказати, що можна зробити з Австралії; Я пройшов перевірки DoD ITAR, не відключивши жодної точки (всі вони в будь-якому випадку були просто відповідями типу "зателефонуйте нам для уточнення"), і тому для моєї крипто-роботи FOSS немає жодних перешкод, хоча жодної з них немає на Java. Це пов’язано з тим, що стурбованість АС пов’язана з новими та інноваційними розробками криптографії, а не з речами, які так чи інакше добре відомі скрізь (також визначення Американського державного управління поняттям «загальнодоступне» не є звичайним визначенням авторських прав, вони використовують це, щоб означати, що воно не класифікується або обмежений).

— Бен

8

На сервері чи робочому столі я не бачу жодної причини використовувати BC, якщо вам не доводиться мати справу з якимись застарілими шифрами або форматами, не підтримуваними Sun JCE.

Однак багато JRE не постачаються з постачальником JCE, як у мобільному або вбудованому середовищі. До нашої ери стане в нагоді в таких випадках.

— ZZ Кодер
джерело

2

На сервері точно є причина, якщо ваш сервер використовує TLS, і ви дбаєте про безпеку (якщо ні, чому ви взагалі використовуєте TLS?). Набори шифрів, що входять до складу JCE, включають лише AES у режимі CBC, що має кілька відомих проблем: googleonlinesecurity.blogspot.dk/2013/11/… .

— Søren Boisen

1

FYI Це неправда Java8 (від Oracle), принаймні.

— Усман Ісмаїл