5_04

1. Выберите и переведите на русский язык фрагмент около 1000 знаков из "Security in Computing 2.8" Каждый переводит свой кусочек. 2. Выполните интерактивные упражнения на ссылках и напишите на сайте (можно сделать отдельную страничку) результаты своей работы - количество ошибок, вопросы - если будут. a) [] b) [] c) [] ответы к упр.(с): 1)must/had to 2)have to 3)have to 4)have to/had to 5)have to 6)mustn't 7)must/mustn't 8)mustn't 9)not have to 10)have to

Encryption algorithms alone are not the __answer__ to everyone's encryption needs. Although encryption implements protected communications channels, it can also be used for other duties. In fact, combining symmetric and asymmetric encryption often capitalizes on the best features of each. Public key algorithms are useful only for specialized tasks because they are very slow. A public key encryption can take 10,000 times as long to perform as a symmetric encryption because the underlying modular exponentiation depends on multiplication and division, which are inherently slower than the bit operations (addition, exclusive OR, substitution, and shifting) on which symmetric algorithms are based. For this reason, symmetric encryption is the cryptographers' "workhorse," and public key encryption is reserved for specialized, infrequent uses, where slow operation is not a continuing problem. Let us look more closely at four applications of encryption: cryptographic hash functions, key exchange , __digital signatures__ , and certificates.

Cryptographic Hash Functions
Encryption is most commonly used for secrecy; we usually encrypt something so that its contentsor even its existenceare unknown to all but a privileged audience.

Одни только алгоритмы шифрования не являются ответом на __нужды каждого в шифровании__. Стиль Хотя шифрование осуществляет защиту каналов связи, оно так же может быть использовано в других целях. Фактически, объединение симметричного и ассиметричного шифрования часто __извлекает выгоду из лучших свойств каждого__. тоже неудачный стиль

Алгоритмы открытого ключа __полезны__ это как?как витамины? только для специализированных задач, потому что они очень медленны. Шифрование с открытым ключом может занять времени в 10000 раз больше чем симметричное шифрование, потому что лежащее в основе модульное возведение в степень зависит от умножения и деления, которые по сути медленнее, чем битовые операции (сложение, исключающее ИЛИ, подстановка, и перестановка) на которых основаны алгоритмы симметричного шифрования. Поэтому симметричное шифрование – “рабочая лошадь” шифровальщиков, и а шифрование открытым ключом зарезервировано для специализированного, нечастого использования, где медленная операция не является постоянной проблемой.

Давайте более тщательно рассмотрим четыре применения шифрования: криптографические хэш-функции, обмен ключами, цифровые подписи и сертификаты.

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

тесты: 1) 2 ошибки 2) 85% 3) у меня не работает кнопка проверки. при нажатии ничего не происходит 1333449476  5  как-то у меня противно шрифт отредактировался :(

Cryptographic Hash Functions
Encryption is most commonly used for secrecy; we usually encrypt something so that its contents or even its existence are unknown to all but a privileged audience. In some cases, however, integrity is a more important concern than secrecy. For example, in a document retrieval system containing legal records, it may be important to know that the copy retrieved is exactly what was stored. Likewise, in a secure communications system, the need for the correct transmission of messages may override [|secrecy] concerns. Let us look at how encryption provides integrity.

In most files, the elements or components of the file are not bound together in any way. That is, each byte or bit or character is independent of every other one in the file. This lack of binding means that changing one value affects the integrity of the file, but that one change can easily go undetected.

 What we would like to do is somehow put a seal or shield around the file so that we can detect when the seal has been broken and thus know that something has been changed. This notion is similar to the use of wax seals on letters in medieval days; if the wax was broken, the recipient would know that someone had broken the seal and read the message inside. In the same way, cryptography can be used to seal a file, encasing it so that any change becomes apparent. One technique for providing the seal is to compute a cryptographic function, sometimes called a **hash** or **checksum** or **message digest** of the file.

Криптографические хэш-функции

Шифрование используется для __ защиты __ неточно чаще всего; мы обычно зашифровываем сообщение так, что его содержание или даже само его существование остается загадкой для всех, кроме узкого круга лиц. Однако, в некоторых случаях, целостность сообщения является более важной составляющей, чем секретность. Например, в системе поиска документов содержащих юридические записи, может быть очень важно знать, что __ копия __ документ содержит именно то, что было сохранено. Кроме того, Аналогично <span style="font-family: Verdana,Geneva,sans-serif; font-size: 8pt;">, в безопасной системе связи, необходимость корректной передачи сообщений может превышать необходимость сохранения тайны. Давайте посмотрим, как шифрование обеспечивает целостность.

<span style="font-family: Verdana,Geneva,sans-serif; font-size: 8pt;">В большинстве файлов, элементы или компоненты файла не связаны друг с другом никакими способами. То есть, каждый байт или бит или символ не зависит от любого другого в этом файле. Это отсутствие взаимосвязи означает, что изменение одного значения конечно же влияет на целостность файла, но это изменение может легко остаться незамеченными.

__ Мы можем __ неточно <span style="font-family: Verdana,Geneva,sans-serif; font-size: 8pt;"> определенным образом поставить «щит» вокруг файл, так что мы сможем определить, когда «щит» был сломан и, таким образом понять, что что-то изменилось. Этот способ аналогичен использованию восковых печатей на письмах в средние века: если воск был поврежден, получатель будет знать, что кто-то повредил печать и прочитал сообщение внутри. Таким же образом, криптография может быть использована для «запечатывания» файла так, что любое изменение станет очевидным. Один из методов для обеспечения «запечатывания» файла - это создание криптографических функций, которые иногда называют «хеш» или «контрольная сумма» или «дайджест сообщения»(не знаю как еще это можно перевести) файла. Варианты из словаря мультитран; [|сжатая дайджест сообщения] [|сжатая форма сообщения] [|сообщение, преобразованное в краткую информацию] [|часть сообщения, удостоверяемая электронно-цифровой подписью] <span style="font-family: Verdana,Geneva,sans-serif; font-size: 8pt;">Aleksey Tsykarev 5 -

<span style="color: #800000; font-family: 'Comic Sans MS',cursive;">For each of these interactions, we have what we might call a "trust threshold," a degree to which we are willing to believe an unidentified individual. This threshold exists in commercial interactions, too. When Acorn Manufacturing Company sends Big Steel Company an order for 10,000 sheets of steel, to be shipped within a week and paid for within ten days, trust abounds. The order is printed on an Acorn form, signed by someone identified as Helene Smudge, Purchasing Agent. Big Steel may begin preparing the steel even before receiving money from Acorn. Big Steel may check Acorn's credit rating to decide whether to ship the order without payment first. If suspicious, Big Steel might telephone Acorn and ask to speak to Ms. Smudge in the purchasing department. But more likely Big Steel will actually ship the goods without knowing who Ms. Smudge is, whether she is actually the purchasing agent, whether she is authorized to commit to an order of that size, or even whether the signature is actually hers. Sometimes a transaction like this occurs by fax, so that Big Steel does not even have an original signature on file. In cases like this one, which occur daily, trust is based on appearance of authenticity (such as a printed, signed form), outside information (such as a credit report), and urgency (Acorn's request that the steel be shipped quickly).

<span style="color: #800000; font-family: 'Comic Sans MS',cursive;">Для каждого из этих взаимодействий у нас есть так называемый "порог доверия", то есть степень доверия неизвестным лицам. Этот порог также присутствует в коммерческих __взаимодействиях__ сделках, транзакциях <span style="color: #800000; font-family: 'Comic Sans MS',cursive;">. Когда производственная компания Acorn отправляет компании Big Steel заказ на 10 000 листов железа, доставка которых должна быть произведена в течение недели и оплачена в течении 10 дней, оказывается большое доверие. Заказ напечатан на бланке компании Acorn и подписан кем-то, назвавшимся Хелен Смудж, менеджер по снабжению. Big Steel могут начать подготовку стали еще до получения денег от Acorn. Big Steel может проверить платежеспособность Acorn чтобы решить, стоит ли отправлять заказ без предоплаты. Если есть подозрения,представитель Big Steel может позвонить в Acorn и спросить г-жу Смудж из отдела снабжения. Но ,скорее всего, Big Steel отправят товар не зная, кто такая г-жа Смудж, является ли она на самом деле менеджером по снабжению, имеет ли она право заключить такой договор на поставку или даже ее ли подпись стоит в договоре. Иногда такие сделки заключаются по факсу, так что у Big Steel может и не быть оригинальной подписи. В таких случаях, которые происходят ежедневно, доверие базируется на знаках подлинности ( печать, подпись), внешней информации (например, отчет о кредитных операциях) и срочности ( просьба компании Acorn о кратчайших сроках доставки стали). <span style="color: #800000; font-family: 'Comic Sans MS',cursive;">1) 2 ошибки <span style="color: #800000; font-family: 'Comic Sans MS',cursive;">2) 85% <span style="color: #800000; font-family: 'Comic Sans MS',cursive;">3) не работает кнопка проверки. user:Kurorisu 5 неинтересно даже ))

<span style="color: #0000ff; font-family: 'Trebuchet MS',sans-serif; font-size: 10pt;">In this chapter, we introduced several approaches to key distribution, ranging from direct exchange to distribution through a central distribution facility to certified advance distribution. We explore the notions of certificates and certificate authorities in more depth in Chapter 7, in which we discuss Public Key Infrastructures. But no matter what approach is taken to key distribution, each has its advantages and disadvantages. Points to keep in mind about any key distribution protocol include the following: <span style="color: #0000ff; font-family: 'Trebuchet MS',sans-serif; font-size: 10pt;">The descriptions of the protocols have raised some of these issues; others are brought out in the exercises at the end of this chapter. В этой главе, мы представили несколько подходов (способов) к улучшению «распространения ключей» (РК), есть ещё такой вариант « [|доведение ключей шифра до сведения абонентов] » начиная с прямого обмена (путь к распределению, передача ключей) через центральные распределяющие отделения и заканчивая распространением через сертифированные отделы __(то есть в этих организациях выдается сертификат/аттестат на использование ключей__ это точно? ). Мы исследовали категории просто изучали их (аттестаты) аттестатов (документы, протоколы, открывающие доступ) и доверенности (T_T) более подробно в 7 главе, где вели разговор о __ структуре __ какая «структура ключа»? там написано «инфраструктура» Это одно и то же? «общего ключа». Но не важно, что за подход взят для «РК», ведь всё имеет свои преимущества и недостатки. Необходимо запомнить, что при использовании любого протокола «РК» нужно обращать внимание на следующее:
 * **<span style="font-family: 'Trebuchet MS',sans-serif; font-size: 10pt;">• ** || <span style="color: #0000ff; font-family: 'Trebuchet MS',sans-serif; font-size: 10pt;">What operational restrictions are there? For example, does the protocol require a continuously available facility, such as the key distribution center? ||
 * **<span style="font-family: 'Trebuchet MS',sans-serif; font-size: 10pt;">• ** || <span style="color: #0000ff; font-family: 'Trebuchet MS',sans-serif; font-size: 10pt;">What trust requirements are there? Who and what entities must be trusted to act properly? ||
 * **<span style="font-family: 'Trebuchet MS',sans-serif; font-size: 10pt;">• ** || <span style="color: #0000ff; font-family: 'Trebuchet MS',sans-serif; font-size: 10pt;">What is the protection against failure? Can an outsider impersonate any of the entities in the protocol and subvert security? Can any party of the protocol cheat without detection? ||
 * **<span style="font-family: 'Trebuchet MS',sans-serif; font-size: 10pt;">• ** || <span style="color: #0000ff; font-family: 'Trebuchet MS',sans-serif; font-size: 10pt;">How efficient is the protocol? A protocol requiring several steps to establish an encryption key that will be used many times is one thing; it is quite another to go through several [|time-consuming] steps for a one-time use. ||
 * **<span style="font-family: 'Trebuchet MS',sans-serif; font-size: 10pt;">• ** || <span style="color: #0000ff; font-family: 'Trebuchet MS',sans-serif; font-size: 10pt;">How easy is the protocol to implement ? Notice that complexity in computer implementation may be different from manual use. ||

- Какие рабочие (т.е. диктуемые данным контекстом применения РК) ограничения наложены? Например, требует ли протокол непрерывного «присутствия» (работы) различных средств, таких как РК центр?

- Какие __требования можно назвать надежными__ в данной ситуации? Здесь про «доверие», почитайте у Тёмы__.__ __ Какие и что за субъекты обязаны быть основательно проверенны перед их активностью __ ? Очень не по-русски.

- Как защититься от __противных случайностей__ ))) ? Может ли __неподготовленный__ почему же именно такой вариант ? человек играть роль одного из этих субъектов (см выше)в протоколе и разрушить защиту? Может ли какая-то часть протокола быть взломана без засвидетельствования.

- Какова продуктивность (полезность) протокола? Протокол, требующий нескольких шагов для создания ключа шифрования, который может быть использован не единожды, это одно; совсем другое пройти через несколько продолжительных по времени шагов за для однократное обращение.

- Как проще Насколько просто внедрить, претворить в жизнь протокол? Отметим, что сложность в системной реализации может отличаться от таковой при ручном управлении.

Н.А.! <span style="color: #0000ff; font-family: 'Trebuchet MS',sans-serif;">Оч трудно дался этот кусочек. Но решил не бросать и потратил уйму времени на него. Завтра не будет меня на паре, я поеду в больницу к 13,00 (там прием с 13,00 до 15,00). Если успею на вторую половинку, пустите? ^_^ <span style="color: #0000ff; font-family: 'Trebuchet MS',sans-serif;">Smirnov <span style="color: #ff0000; font-family: 'Trebuchet MS',sans-serif;">придётся пустить :) <span style="color: #0000ff; font-family: 'Trebuchet MS',sans-serif;"> 4+  я бы тоже долго билась ((

Key Exchange

Suppose you need to send a protected message to someone you do not know and who does not know you. This situation is more common than you may think. For instance, you may want to send your <span class="IL_AD" style="background-color: transparent; color: #006600;">__income tax return__ to the government. You want the information to be protected, but you do not necessarily know the person who is receiving the information. Similarly, you may want to use your web <span class="IL_AD" style="background-color: transparent; color: #006600;">__browser__ to connect with a shopping web site, exchange private (encrypted) e-mail, or arrange for two [|hosts] to establish a protected channel. Each of these situations depends on being able to exchange an encryption key in such a way that nobody else can intercept it. The problem of two previously unknown parties exchanging cryptographic keys is both hard and important. Indeed, the problem is almost circular: To establish an encrypted session, you need an encrypted means to exchange keys.

Public key cryptography can help. Since asymmetric keys come in pairs, one half of the pair can be exposed without compromising the other half. To see how, suppose S and R (our well-known sender and receiver) want to derive a <span class="IL_AD" style="background-color: transparent; color: #006600;">__shared__ symmetric key. Suppose also that S and R both have public keys for a common encryption algorithm; call these k PRIV- S, k PUB- S , k PRIV- R , and k PUB- R , for the private and public keys for S and R , respectively. The simplest solution is for S to choose any symmetric key K, and send E ( k PRIV- S , K ) to R. Then, R takes S 's public key, removes the encryption, and obtains K. Alas, any eavesdropper who can get S 's public key can also obtain K.

Обмен ключами

Предположим, вам нужно отправить защищенное сообщение кому-то, кого вы не знаете и кто не знает вас. Такая ситуация встречается чаще, чем вы думаете. Например, вы можете отправить налоговую декларацию о доходах в правительство. Вы хотите, чтобы информация была защищена, но вам не обязательно знать человека, который получает информацию. Кроме того, Аналогично,, вы можете использовать свой веб-браузер, чтобы соединиться с веб-сайтом магазина, обмениваться частными (зашифрованными) сообщениями по электронной почте или организовывать защищенный канал двумя хостами. Каждая из этих ситуаций зависит от того, способны ли вы обмениваться ключом шифрования так, что никто не сможет перехватить его. __ Задача о двух ранее неизвестных сторон ах __, ошибки в русском обменивающихся криптографическими ключами, и трудна и важна. В действительности, чтобы установить__ зашифрованную сессию __, а по-другому не сказать? тогда может __защищенный сеанс__ ? наверно, это понятнее. , вы нуждаетесь в зашифрованном способе обменять ключи, то есть получается некий замкнутый круг. Открытый ключ шифрования может помочь в решении этой проблемы. Так как асимметричные ключи идут в парах, то одна половина пары может подвергаться воздействию со стороны, без последствия для другой половины. Чтобы увидеть, как, предположим, что О и П (наши известные отправитель и получатель) хотят получить общий симметричный ключ. Предположим также, что у О и П оба имеют открытые ключи для общего алгоритма шифрования, которые называются: k PRIV- S (ключ приватный личный/закрытый у О), k PUB- S (ключ публичный у О), k PRIV- R (ключ приватный у П), и k PUB- R (ключ публичный у П). Самое простое решение для О выбрать любой симметричный ключ K, и отправить сообщение с ключами (к PRIV- S, K) Получателю. Тогда П принимает открытый ключ от О, снимает шифрование и получает ключ К. Увы, любой злоумышленник, который может получить открытый ключ Отправителя может получить доступ к ключу K.

Олег. 5 -

Даниил, увы, на сегодня всё.
 * Если работа готова, можно её выложить на проверку, - если хотите, конечно, - я могу проверить, но оценку ставить не буду. 6.04. 23.36 **

**Certificates to Authenticate an Identity** This protocol is represented more easily electronically than on paper. With paper, it is necessary to guard against forgeries, to prevent part of one chain from being replaced and to ensure that the public key at the bottom is bound to the chain. Electronically the whole thing can be done with digital signatures and hash functions. Kohnfelder [KOH78] seems to be the originator of the concept of using an electronic certificate with a chain of authenticators, which is expanded in Merkle's paper [MER80]. A public key and user's identity are bound together in a **certificate**, which is then signed by someone called a **certificate authority**, certifying the accuracy of the binding. In our example, the company might set up a certificate scheme in the following way. First, Edward selects a public key pair, posts the public part where everyone in the company can retrieve it, and retains the private part. Then, each division manager, such as Diana, creates her public key pair, puts the public key in a message together with her identity, and passes the message securely to Edward. Edward signs it by creating a hash value of the message and then encrypting the message and the hash with his private key. By signing the message, Edward affirms that the public key (Diana's) and the identity (also Diana's) in the message are for the same person. This message is called Diana's certificate. ага, чистенько теперь. :) ** Свидетельство для подтверждения личности. **

Этот документ легче __составить__ представить? в электронном виде, чем на бумаге. С бумагой необходимо принять меры против подделок, не дать заменить части одной цепи и гарантировать, что открытый ключ в основании связан с цепью. В электронном виде все это может быть сделано с помощью цифровых подписей и хэш-функций. Кохнфелдер - создатель концепции использования электронного свидетельства с цепью удостоверений, которая расширена в статье Меркла. Открытый ключ и личность пользователя связаны в свидетельстве, которое, __когда оно подписано, называется сертификатом полномочий__, тут Вы наврали, попробуйте сами исправить (я потом помогу, если понадобится): "called" относится к "someone", а не к документу. которое потом подписывается человеком, __называемым свидетельем полномочий__,  точнее, просто "уполномоченным выдавать сертификаты" или просто "подписывает специально уполномоченный человек" - "called" здесь совершенно лишнее - удостоверяющим правильность связывания(может как-то так? =) ). В нашем примере компания могла бы настроить схему свидетельства следующим образом. Во-первых, Эдвард выбирает пару открытых ключей, отправляет публичную часть туда, где все в компании могут __восстановить__ найти ее, и сохраняет личную часть. Тогда, каждый менеджер отдела, такой как Диана, создает свою пару открытых ключей, помещает открытый ключ в сообщение вместе со своей идентификацией и передает его Эдварду по защищенным каналам. //Эдвард подписывает его, с помощью создания значения хеш-функции сообщения и затем шифрует сообщение и хэш __с его__ с воим личным ключом.(мучилась с этим предложением, не получается его хорошо перевести =(//. Тут нужно было вообще "по-русски переписать", типа "Эдвард подписывает сообщение. Для этого он создаёт для него значение ... и т.д." хотя тоже не блеск. И вообще, оно того не стОит! )) Подписывая сообщение, Эдвард подтверждает, что открытый ключ (Дианы) и личность (также Дианы) соответствуют. Это сообщение называют свидетельством Дианы. a)1 ошибка b)85% c) все верно =) молодец! user:LenaBerezkina

5

Лена, если здоровье позволяет, начинайте потихоньку писать черновик текста презентации. Да, мне Тёма сказал, что надо начинать готовиться, но я немного затрудняюсь с выбором темы.. посмотрите, пожалуйста, я нашла сайт неплохой на мой взгляд, оттуда можно что-то использовать? http://asher.ru/security/book/its/05 или лучше про что-то более конкретное? например, про вирус какой-нибудь =) сайт хороший, почему нет?  нужно только рассказать что-нибудь  - интересное,  - не то, что всем и так известно,  - не такое общее: по-моему, там много теории и мало примеров.  Если выбрать слишком общую тему (мы с вчера на занятии об этом говорили), то за положенное время не успеете её рассказать, и рассказ может получиться слишком общим и не интересным.  Про вирус, конечно, тоже можно. Не забудьте у остальных темы посмотреть, чтобы узнать, нет ли совпадений.  спасибо, все поняла =) и последний впрос: какой объем сообщения? сколько времени должна занять презентация? =) готовьтесь минут на 5-7, со слайдами и вопросами получится дольше.Но если очень нужно, чтобы раскрыть тему, можно продлить до 10 минут.